RGB to HDMI using a Pi Zero and a small CPLD

[danielj]

[-B-]

Have you tried the QL yet, with its famous overscan in monitor mode?

[IanB]

Have you tried the QL yet, with its famous overscan in monitor mode?

Unfortunately I don't have a QL but it looks like it has a standard RGB TTL output so it should work, it's just a matter of creating a profile.
Does anyone here have a QL?

[-B-]

I have a couple but I’m not in the UK.
I will be for Christmas though, so if you’d like me to lend you one....

Neil.

[IanB]

I have a couple but I’m not in the UK.
I will be for Christmas though, so if you’d like me to lend you one....

That might be useful. I can probably create a profile with just some tech info although it would have to be connected to a real machine for the final tweaks.

Do you know what pixel clock frequency the QL uses? (It seems to be 10Mhz from online info)
Also how many clock cycles are there in a video line? (This should be around 640 but may vary 1 or 2 either way)

[-B-]

Do you know what pixel clock frequency the QL uses? (It seems to be 10Mhz from online info)
Also how many clock cycles are there in a video line? (This should be around 640 but may vary 1 or 2 either way)

This might help...

ZX8301.pdf

(376.68 KiB) Downloaded 42 times

Neil.

[IanB]

This might help...
ZX8301.pdf

Thanks, it was 10Mhz & 640 clock cycles so I created a new profile based on that, you can try it when the new software is released.

[IanB]

Got my new issue 2 combined RGB and YUV boards back from JLC so I can now use it for analog RGB sources, 6847 YUV type sources and monochrome sources.

Here it is working with the Amstrad CPC:

And an Atom:

It even works with the beeb / electron:

(It isn't require of course as they will work on the raw TTL inputs but it does mean you can swap between supported machines without having to remove the analog interface)

Here's a closeup of the new board:

(It's connected via a test harness so I can do signal measurements)

There are still a few issues to sort out as the software really doesn't like noise in the sync input and that can happen when setting up the sync levels but once the profiles is setup it seems to work very smoothly.

[-B-]

Excellent stuff!

[IanB]

I've added support for a few more machines:

Camputers Lynx:

This one has a 3 bit TTL output like the beeb.

Colour Genie:

This one uses TTL connections picked up internally.

Tandy Micro Color Computer: (MC-10)

This one uses the new RGB/YUV interface with YUV signals picked up internally and that should also work with the Tandy color computers 1 & 2.
Interestingly this has quite different settings to the Dragon 32 as the PAL Tandy color computers use a slightly different clock frequency for the 6847.

The Dragon 32 also works with the RGB/YUV interface (previously mentioned in the Aom thread).
As it has a composite output I was able to do a side by side comparison with the RGBtoHD output: (composite on the left, RGBtoHD on the right)

Composite doesn't actually look that bad in the photo but here are a couple of closeups:

This is composite using a Retrotink 2X converter:

This is RGBtoHD using the RGB/YUV addon interface:

[aotta]

excellent!
but when the new ttl version will be published? on github rgbtohdmi i found nothing about...

[hoglet]

excellent!
but when the new ttl version will be published? on github rgbtohdmi i found nothing about...

All the work in the last 12 months has been happening in the dev branch:
https://github.com/hoglet67/RGBtoHDMI/tree/dev

[aotta]

thank you hoglet, i missed the dev branch! i'll order a pcb asap!

[TheArduinoGuy]

Are these devices going to go back on sale at any time soon? If so what price please? Thanks.

[hoglet]

Are these devices going to go back on sale at any time soon? If so what price please? Thanks.

As far as I'm aware, no one is planning a production run.

But the PCBs are available if you want to build your own.

Which version are you interested in? And if you are not sure, then what machine(s) do you want to use it with?

Dave

[maniacminer]

I would like to get a PCB too. Do I need to supply the CPLD and program it? PM me please. The machines I am using are all Acorn, BBC Micro, Master, Atom and Archimedes A540.

I have been looking for a good RGB -> HDMI solution that would work with the VideoNuLA. I built a 16/6 MHz clock board, so I have solved the MODE7 problem so I am going to try a VideoNuLA again

[TheArduinoGuy]

Dave it is for a BBC Master 128.

However, I also own: Dragon 32, ZX81, Spectrum +3.

Thanks,

Mike

[hoglet]

I have been looking for a good RGB -> HDMI solution that would work with the VideoNuLA. I built a 16/6 MHz clock board, so I have solved the MODE7 problem so I am going to try a VideoNuLA again

Sorry, but the Pi based RGBtoHDMI is not compatible with VideoNuLA. There's not sufficient memory bandwidth for the Pi to handle 4 bits (each) of RGB. It's doing all the pixel copying and processing in software.

Dave

[TheArduinoGuy]

Would love to get hold of a PCB please Dave.

Questions:

Can the IC be soldered onto the board using a hot air reflow gun? That's all I have that might be able to solder a PCB like this.

Is the programmer necessary? I read somewhere else about the CPLD being programmed from the Pi itself. Is that possible? I do have a programmer for use with Atmel style IC's. I don't know if it would work with this kit.

Thanks,

Mike

[hoglet]

Can the IC be soldered onto the board using a hot air reflow gun? That's all I have that might be able to solder a PCB like this.

I assume you have a normal soldering iron?

The CPLD can be soldered with a normal soldering iron, using a large bit and a technique called drag soldering.

It's not that difficult with a bit of practice, but if you have never done any surface mount solding before, you might want to buy some cheap practice boards.

Is the programmer necessary? I read somewhere else about the CPLD being programmed from the Pi itself. Is that possible? I do have a programmer for use with Atmel style IC's. I don't know if it would work with this kit.

With the original version of the board, a Xilinx CPLD programmer was required.

With the latest version of the board (that IanB revised), the CPLD is programmed by the Pi. So no programmer is needed

The other change IanB made was to replace the Molex connector with a 2x5 pin right-angle header, so a normal IDC connector can be used. This is more compact, and makes cable assembly quicker.

Would love to get hold of a PCB please Dave.

I don't have any of the latest boards in stock at the moment. IanB may have some, I'm not sure.

However, the project is open source, and all the the designs are in github. The gerber files for the latest version are here:
https://github.com/hoglet67/RGBtoHDMI/t ... ufacturing

So if you are in a hurry, you (or anyone else) can order some boards directly from JLCPCB. Just upload the .zip file and select the default oprions.

I'm don't think there is sufficient demand for another "production" build of 10 boards. Robert (JudgeBeeb) made up 5 boards prior to ABUG to practice SMT soldering. At ABUG he was trying hard to give them away, and there was only one taker.

I don't currently have the time (or energy) to do another production run of these. The last 10 boards I built took the best part of a week to make up (doing the cables is very time consuming). I ended up spending ~£350 on PCBs, parts, sundries, tooling, postage and packaging. I think when I did the final accounts, I actually made a small loss! So next time I would need to charge a bit more.

Honestly I would prefer people to have a go a building this themselves. It's a great first project for SMT assembly.

Dave

[TheArduinoGuy]

OK thanks. I might get a few PCBs ordered from somewhere then.

[TheArduinoGuy]

FYI I've ordered 10 PCBs. I shall let you know how I get on. Thanks again.

[maniacminer]

I have been looking for a good RGB -> HDMI solution that would work with the VideoNuLA. I built a 16/6 MHz clock board, so I have solved the MODE7 problem so I am going to try a VideoNuLA again

Sorry, but the Pi based RGBtoHDMI is not compatible with VideoNuLA. There's not sufficient memory bandwidth for the Pi to handle 4 bits (each) of RGB. It's doing all the pixel copying and processing in software.

Dave

Ah, my mistake, I thought 6 bit meant 6 bits of RGB (18 bits) but it means digital RGBrgb, (2 bit RGB). I'm still interested in a board, I don't really want to make ten boards though

[maniacminer]

FYI I've ordered 10 PCBs. I shall let you know how I get on. Thanks again.

If you're interested in selling a board, I would be interested in buying one.

[TheArduinoGuy]

Sure I ordered extra in case other people wanted one too.

[marcusjambler]

Sure I ordered extra in case other people wanted one too.

I'll take one board please.

[TheArduinoGuy]

OK I shall set 2 aside when they get here

[TheArduinoGuy]

Does anyone know if this will work with a Sega Dreamcast ?

[hoglet]

Does anyone know if this will work with a Sega Dreamcast ?

Sorry, no it won't - the Dreamcast has too many colours.

A bit of history....RGBtoHDMI started out as a Beeb only project, which meant it only need to deal with 1-bit RGB. IanB has done some excellent work to generalize this, so it now supports 2-bit RGB. He's also designed an additional analog front-end with programmable DACs, to support a wider range of sources. So we do now support a wider range of machines, and support YUV as well as RGB.

But overall the limiting factor is the 2-bit RGB interface through the CPLD and into the Pi, which really limits it to 64-colours maximum. And even if the hardware supported a wider interface, it's doubtful that the Pi would have the memory bandwidth to support this.

It's for this reason that we don't support things like:
- Acorn Archimedes (4-bit RGB, giving 4096 colours)
- Video NuLA (4-bit RGB, giving 4096 colours)
- Dreamcast (8-bit RGB, giving 16 million colours)

Even the Spectrum has proved somewhat of a struggle, and it's not current possible to differentiate all the bright/normal colours.

As a rule of thumb, if the system produces less than 64 different colours and has an RGB output, then we can probably create a profile for it. If it's a YUV output, then we'd need to consider that on a case-by-case basis.

Dave

[TheArduinoGuy]

Thanks for the very comprehensive reply.