RGB to HDMI using a Pi Zero and a small CPLD
Re: RGB to HDMI using a Pi Zero and a small CPLD
Okay so here's mine. Works flawlessly so far.
The first 4 images are from the BBC micro. The last 2 are from an issue 6 Electron. The TV resolution is 1920 x 1080 50Hz
Just realised I didn't set Elk=1 in cmdline but it seems to be fine ?
The first 4 images are from the BBC micro. The last 2 are from an issue 6 Electron. The TV resolution is 1920 x 1080 50Hz
Just realised I didn't set Elk=1 in cmdline but it seems to be fine ?
Last edited by Budgie on Sat Jul 21, 2018 9:55 pm, edited 1 time in total.
Andy
Re: RGB to HDMI using a Pi Zero and a small CPLD
Okay not played Firetrack before but the graphics are stunning.
As Iused to use an Electron on a 10inch manual tune black and white TV. And I have been using it modern day on composite (i.e. black and white) I cant ever recall having a better picture on an Electron I own.
So for Electron Issue 4 on an unbranded 12inch ebay HDMI monitor, it does the business.
Last edited by Elminster on Sat Jul 21, 2018 9:55 pm, edited 1 time in total.
Re: RGB to HDMI using a Pi Zero and a small CPLD
Having 50hz is brilliant. Coming from my gbs8200 which only outputs 60hz, the smooth 50hz scrolling on my dell 2001fp is fantastic 

Re: RGB to HDMI using a Pi Zero and a small CPLD
The third image, M0TEST, looks like the monitor is also doing some scaling, as the vertical lines are uneven.
What's the TV/Monitor model?
Might be worth seeing if there are settings like:
a) Overscan: off, or
b) Aspect ratio: "1:1" or "Original" or "Just Scan"
Dave
Re: RGB to HDMI using a Pi Zero and a small CPLD
Here is a link to the video of what the fuel bar corruption looks like on the NuLA beeb with mux off.
https://www.dropbox.com/s/66v26f14tinrg ... n.avi?dl=0
With the mode 0 test screen, in the left hand edge line, the corruption can be seen moving down the screen several times a second.
It looks to me like two clocks slightly out of sync, but as I say, there are no issues with mux on, other than might be fixed by a cap swap.
As I say though, I'm not planning on using it/them on a NuLA'd beeb, so I will swap to another beeb today.
PS Just tried another beeb, works fine, mux seems to make no difference and today the Panasonic isn't stretching the picture!
It has a TWO MEG card in it which seems to conflict with the user port, so I might need to set up the GOTEK too.
https://www.dropbox.com/s/66v26f14tinrg ... n.avi?dl=0
With the mode 0 test screen, in the left hand edge line, the corruption can be seen moving down the screen several times a second.
It looks to me like two clocks slightly out of sync, but as I say, there are no issues with mux on, other than might be fixed by a cap swap.
As I say though, I'm not planning on using it/them on a NuLA'd beeb, so I will swap to another beeb today.
PS Just tried another beeb, works fine, mux seems to make no difference and today the Panasonic isn't stretching the picture!
It has a TWO MEG card in it which seems to conflict with the user port, so I might need to set up the GOTEK too.
Last edited by tricky on Sun Jul 22, 2018 9:10 am, edited 1 time in total.
Re: RGB to HDMI using a Pi Zero and a small CPLD
That does just look like the video level being a bit low. The Mux=On setting does is to take the RGB signals after they have been fed through the 74LS08, which has a slightly lower switching threshold than the CPLD. It's also useful to do this on older Elks.tricky wrote: ↑Sun Jul 22, 2018 8:28 amHere is a link to the video of what the fuel bar corruption looks like on the NuLA beeb with mux off.
https://www.dropbox.com/s/66v26f14tinrg ... n.avi?dl=0
With the mode 0 test screen, in the left hand edge line, the corruption can be seen moving down the screen several times a second.
It looks to me like two clocks slightly out of sync, but as I say, there are no issues with mux on, other than might be fixed by a cap swap.
Dave
Re: RGB to HDMI using a Pi Zero and a small CPLD
I had some thoughts about in-band signalling:
- put data in the last line of the frame
- add a checksum at the end (perhaps very simple XOR)
- the Pi should do nothing special if the last line has a bad checksum
- the Pi should rewrite a line with a good checksum as all-black for display purposes
- just possibly the CPLD could compute and validate the checksum, if there's room for one more bit from the CPLD to the Pi?
- and finally, of course, if the checksum is good the Pi should decode the line as a command
Re: RGB to HDMI using a Pi Zero and a small CPLD
Lots of good ideas there Ed - I do particularly like the idea of in-band signalling in the video data.
A couple of minor complexities:
1. Depending on the screen mode, Beeb pixels will map to 1, 2, or 4 pixels. So probably we should design the encoding around Mode 2/5 pixels, which gives us 160 bits.
2. We can't guarantee the Beeb pixels ends up at an exact offset in the 672 pixel frame buffer - it varies depending on screen mode, and also on the sampling offset. So we probably need some kind of start bit, or sync byte.
All quite doable though.
If we restrict the colour palette to 4096 colours, then the full palette is 8 x 12 = 96 bits, so that fits nicely.
Dave
I don't think this will be possible, as it would require several additional registers.
A couple of minor complexities:
1. Depending on the screen mode, Beeb pixels will map to 1, 2, or 4 pixels. So probably we should design the encoding around Mode 2/5 pixels, which gives us 160 bits.
2. We can't guarantee the Beeb pixels ends up at an exact offset in the 672 pixel frame buffer - it varies depending on screen mode, and also on the sampling offset. So we probably need some kind of start bit, or sync byte.
All quite doable though.
If we restrict the colour palette to 4096 colours, then the full palette is 8 x 12 = 96 bits, so that fits nicely.
Dave
Re: RGB to HDMI using a Pi Zero and a small CPLD
In other news, I've finally managed to adjust the frequency of the PLLH (which us user for the HDMI clock) by writing to the clock manager registers:
https://github.com/hoglet67/RGBtoHDMI/b ... dmi.c#L319
I can also put a marker on the screen at the point that the HDMI VSync is detected, which allows you to observe the phase of the HDMI VSync wrt the Beeb's VSync. After calculating for the clock error and updaing PLLH, this marker is very stable.
It's interesting to deliberately introduce a known clock error, so the VSync phase shifts continuously. This has demonstrated the the double buffering scheme I have currently implemented is not sufficient to avoid tearing. So I need to upgrade this to triple buffering. Done correctly, it seems that triple buffering not only eliminates tearing, it actually reduces lag (compared to double buffering). At least, according to this article.
So I'm going to have a stab at that tomorrow.
Dave
https://github.com/hoglet67/RGBtoHDMI/b ... dmi.c#L319
I can also put a marker on the screen at the point that the HDMI VSync is detected, which allows you to observe the phase of the HDMI VSync wrt the Beeb's VSync. After calculating for the clock error and updaing PLLH, this marker is very stable.
It's interesting to deliberately introduce a known clock error, so the VSync phase shifts continuously. This has demonstrated the the double buffering scheme I have currently implemented is not sufficient to avoid tearing. So I need to upgrade this to triple buffering. Done correctly, it seems that triple buffering not only eliminates tearing, it actually reduces lag (compared to double buffering). At least, according to this article.
So I'm going to have a stab at that tomorrow.
Dave
Last edited by hoglet on Sun Jul 22, 2018 10:13 pm, edited 1 time in total.
Re: RGB to HDMI using a Pi Zero and a small CPLD
I've been working on the dev branch today and have added three new items to the feature menu:
1. An "HDMI Clock" setting to compensate for the clock offset between the Beeb and the Pi, and also compensate for games that run with interlace off (i.e. 50.08Hz rather than 50Hz).
2. A "VSync" setting that is a debugging aid to let you see the position of the Pi's HDMI VSync compared to the Beeb's VSync. Useful to check the previous setting is correct. Currently this is only visible in Modes 0..6.
3. A "Num Buffers" setting that changes the buffering strategy used in Modes 0..6:
- single buffering (minimal latency, but lots of potential for tearing and currently messes up the OSD)
- double buffering (typically an extra 20ms latency, but greatly reduces tearing)
- triple buffering (eliminates all tearing)
- quadruple buffering (overkill, never really needed)
More buffers doesn't necessarily mean more latency, it just means those buffers are available if needed. In all cases the Pi should flip to the most recently written buffer on HDMI VSync. So in practice there is little difference in latency between 2, 3 and 4 buffers.
This is quite a big change, so I need to do more testing tomorrow before I merge back to master.
But if anyone is dead keen to try this, there is a test build available here:
https://github.com/hoglet67/RGBtoHDMI/r ... 23_156dec8
I've been using Tricky's scramble as a test program, and then deliberately setting "HDMI Clock" to 623 or 625 to induce VSync slip. The correct behaviour is to drop or replicate a frame as needed, rather than tear. When "HDMI Clock" is set to 624 the sync rates match very closely indeed.
Dave
1. An "HDMI Clock" setting to compensate for the clock offset between the Beeb and the Pi, and also compensate for games that run with interlace off (i.e. 50.08Hz rather than 50Hz).
2. A "VSync" setting that is a debugging aid to let you see the position of the Pi's HDMI VSync compared to the Beeb's VSync. Useful to check the previous setting is correct. Currently this is only visible in Modes 0..6.
3. A "Num Buffers" setting that changes the buffering strategy used in Modes 0..6:
- single buffering (minimal latency, but lots of potential for tearing and currently messes up the OSD)
- double buffering (typically an extra 20ms latency, but greatly reduces tearing)
- triple buffering (eliminates all tearing)
- quadruple buffering (overkill, never really needed)
More buffers doesn't necessarily mean more latency, it just means those buffers are available if needed. In all cases the Pi should flip to the most recently written buffer on HDMI VSync. So in practice there is little difference in latency between 2, 3 and 4 buffers.
This is quite a big change, so I need to do more testing tomorrow before I merge back to master.
But if anyone is dead keen to try this, there is a test build available here:
https://github.com/hoglet67/RGBtoHDMI/r ... 23_156dec8
I've been using Tricky's scramble as a test program, and then deliberately setting "HDMI Clock" to 623 or 625 to induce VSync slip. The correct behaviour is to drop or replicate a frame as needed, rather than tear. When "HDMI Clock" is set to 624 the sync rates match very closely indeed.
Dave
Last edited by hoglet on Mon Jul 23, 2018 6:34 pm, edited 3 times in total.
Re: RGB to HDMI using a Pi Zero and a small CPLD
i am away from my machine at the moment, but my conclusion was the Electron was perfect. Will see what it does on the Nula’s Master next, then swap to a Nula’s free Beeb b issue 7 or a b+
Edit: is the videonula the only addon expected to break things? I might have asked this already.
Edit: is the videonula the only addon expected to break things? I might have asked this already.
Last edited by Elminster on Mon Jul 23, 2018 7:12 pm, edited 1 time in total.
Re: RGB to HDMI using a Pi Zero and a small CPLD
Yup, definitely not designed to deal with the "non-digital" RGB values you get using the palette.
It should work if you don't use the palette, and set Mux=On in the OSD (or mux=1 in cmdline.txt)
Dave
Re: RGB to HDMI using a Pi Zero and a small CPLD
Finally set mine up, and it works very nicely with my Master 128. Thanks Dave! Now I can run three computers at VCF West rather than two 

SW/EE from New Zealand, now in Mountain View, CA, making BBC/Electron hardware projects for fun.
Most interesting: Arcflash, FX2+PiTubeDirect Tube/Cartridge adapter, USB cart interface.
Most interesting: Arcflash, FX2+PiTubeDirect Tube/Cartridge adapter, USB cart interface.
Re: RGB to HDMI using a Pi Zero and a small CPLD
I was late to see this topic. If another batch would be made - would definitely be interested in getting one or two.
- marcusjambler
- Posts: 850
- Joined: Mon May 22, 2017 12:20 pm
- Location: Bradford
- Contact:
Re: RGB to HDMI using a Pi Zero and a small CPLD
Also registering interest in one built up board
Marcus
Marcus
Re: RGB to HDMI using a Pi Zero and a small CPLD
Hi Guys,
Thanks for the interest, but I just want to make it clear that I'm not planning to produce any more built-up boards, at least not in the near future. It took me the best part of a week, working 8-10 hours a day, to produce the previous 10, when you include all the time for component ordering, building, cleaning, programming, testing, packaging, shipping, etc. The final accounts say I made a profit of £13.61.
All the design files are on github (including the gerber files for the PCB) and the design is open source so you (or anyone else) are welcome to order the parts and make these up yourself. If you are reasonable at through-hole soldering, but have yet to do any surface mount assembly, this is a good board to start on.
regards
Dave
Thanks for the interest, but I just want to make it clear that I'm not planning to produce any more built-up boards, at least not in the near future. It took me the best part of a week, working 8-10 hours a day, to produce the previous 10, when you include all the time for component ordering, building, cleaning, programming, testing, packaging, shipping, etc. The final accounts say I made a profit of £13.61.
All the design files are on github (including the gerber files for the PCB) and the design is open source so you (or anyone else) are welcome to order the parts and make these up yourself. If you are reasonable at through-hole soldering, but have yet to do any surface mount assembly, this is a good board to start on.
regards
Dave
- daveejhitchins
- Posts: 6231
- Joined: Wed Jun 13, 2012 6:23 pm
- Location: Newton Aycliffe, County Durham
- Contact:
Re: RGB to HDMI using a Pi Zero and a small CPLD
Wow! . . . That's £1.36/unit - I've just got to get a viewing of your business plan, Dave - it seems to be far better than mine

Dave H

Last edited by daveejhitchins on Fri Aug 10, 2018 8:19 am, edited 1 time in total.
Re: RGB to HDMI using a Pi Zero and a small CPLD
Swapped the pi zero W out for a normal v1.3 pi zero, still works great!
Re: RGB to HDMI using a Pi Zero and a small CPLD
Random people thought, could he debug output from hdmi board give any useful information for debugging video issues? Not specifically my issue but in general,or perhaps I should say what sort of video issues could you debut with this?
Re: RGB to HDMI using a Pi Zero and a small CPLD
About all it could tell you is exactly what the VSync period is, and whether the video is interlaced or not.
I think you can tell that easily with a scope as well.
Dave
Re: RGB to HDMI using a Pi Zero and a small CPLD
Re: RGB to HDMI using a Pi Zero and a small CPLD
If you have a scope capable of capturing and syncing to the signal!
I couldn't capture my vsync issue on my cheap USB scope if you remember.
Sometimes, it would be helpful to get a log of scan line counts between vsyncs, especially if it isn't 312/313.
I couldn't capture my vsync issue on my cheap USB scope if you remember.
Sometimes, it would be helpful to get a log of scan line counts between vsyncs, especially if it isn't 312/313.
Re: RGB to HDMI using a Pi Zero and a small CPLD
As part of my testing the fixed video on my Beeb issu4 I have tested the following.
- Kix
- Frenzy
- Tricky Space Invaders
- Tricky Frogger
- Tricky AstroBlast
- Bad Apple (Mode 7)
Only thing I have noticed is on space invaders the backgroud shakes a little. I guess everything is shifting 1 pixel back and forth. Not qite sure how to describe it. Not sure a video would pick it up.
- Kix
- Frenzy
- Tricky Space Invaders
- Tricky Frogger
- Tricky AstroBlast
- Bad Apple (Mode 7)
Only thing I have noticed is on space invaders the backgroud shakes a little. I guess everything is shifting 1 pixel back and forth. Not qite sure how to describe it. Not sure a video would pick it up.
Last edited by Elminster on Wed Aug 29, 2018 5:18 pm, edited 1 time in total.
Re: RGB to HDMI using a Pi Zero and a small CPLD
Do you have a link to the .ssd file? I'll give it a try as well.
Re: RGB to HDMI using a Pi Zero and a small CPLD
viewtopic.php?f=57&t=12474&p=167377&hil ... rs#p167377
Re: RGB to HDMI using a Pi Zero and a small CPLD
Re: RGB to HDMI using a Pi Zero and a small CPLD
i like frogger, it was really clean and crisp on HDMI, could not spot any artifacts. And plays well to boot.
-
- Posts: 55
- Joined: Sat Aug 26, 2017 9:30 am
- Contact:
Re: RGB to HDMI using a Pi Zero and a small CPLD
are you able to give me some advice to those less fortunate to have a complete one and a bit unsure how to proceed with putting these together ?
what do we do with the files for this, what do i we load gerber files into ?
what programmers do we need if any ?
thanks
dave
what do we do with the files for this, what do i we load gerber files into ?
what programmers do we need if any ?
thanks
dave
Re: RGB to HDMI using a Pi Zero and a small CPLD
Maybe a weird/dumb question but can this also be used to create an Atom "color board" ?
Kind regards, Bram
Kind regards, Bram
Last edited by bprosman on Fri Sep 14, 2018 11:43 pm, edited 1 time in total.
Re: RGB to HDMI using a Pi Zero and a small CPLD
Similar question asked/answer here, does that answer your question?
viewtopic.php?f=3&t=14430&p=209125&hilit=Atom#p209125