RGB to HDMI using a Pi Zero and a small CPLD

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
Elminster
Posts: 3929
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by Elminster » Sun Oct 14, 2018 4:56 pm

I just follow instruction for Hoglet’s ice-t whenever I build anything with a Xilinx. So far that has always worked. :)

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Sun Oct 14, 2018 5:08 pm

IanB wrote:
Sun Oct 14, 2018 4:39 pm
No, I'm not sure what version to download
You are in for a treat then..... the Xilinx tools, especially on Windows, are a complete nightmare.

Some basics:
- you need ISE 14.7, not Vivado (which is for more recent devices)
- the recent ISE 14.7 Windows 10 release only supports Spartan 6 devices, not older devices like CPLD
- the complete ISE 14.7 package (which allows you to compile the VHDL files) is 8GB of download.
- the ISE 14.7 lab tools package (which will let you program devices) is only 1GB.

So for programming, your best bet is Windows 7 and install the Lab Tools package. Here's the link:
https://www.xilinx.com/member/forms/dow ... 1015_1.tar
(although it's a tar file, it is multi-platform)

Once you have this installed and can run the programmer software (impact) give me a shout.

Dave
Last edited by hoglet on Sun Oct 14, 2018 5:09 pm, edited 2 times in total.

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Sun Oct 14, 2018 6:34 pm

hoglet wrote:
Sun Oct 14, 2018 5:08 pm
So for programming, your best bet is Windows 7 and install the Lab Tools package. Here's the link:
https://www.xilinx.com/member/forms/dow ... 1015_1.tar
(although it's a tar file, it is multi-platform)
Once you have this installed and can run the programmer software (impact) give me a shout.
Ok I've installed that
hoglet wrote:
Sun Oct 14, 2018 5:08 pm
- you need ISE 14.7, not Vivado (which is for more recent devices)
- the recent ISE 14.7 Windows 10 release only supports Spartan 6 devices, not older devices like CPLD
I'm also downloading the full non-windows10 version but that will take a while...

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Sun Oct 14, 2018 6:53 pm

IanB wrote:
Sun Oct 14, 2018 6:34 pm
Ok I've installed that
Can you find/launch a program called "impact" without it crashing?

Do you actually have the programming cable now?

In the next post, I'll write down the steps you need to follow. It will take me a few minutes to do this...

Dave

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Sun Oct 14, 2018 7:06 pm

hoglet wrote:
Sun Oct 14, 2018 6:53 pm
Can you find/launch a program called "impact" without it crashing?
Do you actually have the programming cable now?
In the next post, I'll write down the steps you need to follow. It will take me a few minutes to do this...
Yes I found my old cable and I've already programmed the CPLD, finding the right software to install was my main problem but I suggest you post your steps anyway for the others that are building one.

Testing shortly once I've finished building the RGB cable...

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Sun Oct 14, 2018 7:27 pm

Programming the RGBtoHDMI CPLD

Content moved to the wiki:
https://github.com/hoglet67/RGBtoHDMI/w ... rogramming
Last edited by hoglet on Sun Oct 14, 2018 8:04 pm, edited 2 times in total.

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Sun Oct 14, 2018 8:11 pm

hoglet wrote:
Sun Oct 14, 2018 7:27 pm
Programming the RGBtoHDMI CPLD
Content moved to the wiki:
https://github.com/hoglet67/RGBtoHDMI/w ... rogramming
Thanks, that's basically what I did.

Well... It mostly works but I'm getting tearing which looks like horizontal sync detection issues
tearing.jpg
This is on a Master 128.
Last edited by IanB on Sun Oct 14, 2018 8:13 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Sun Oct 14, 2018 8:18 pm

IanB wrote:
Sun Oct 14, 2018 8:11 pm
This is on a Master 128.
Hmmm, not seen this before. A few questions...

Do you see this in all screen modes?

Is this using a Pi Zero or a Pi Zero W?

Is this with your own kernel, or with the standard distribution?

How long is your cable?

Do you have a different machine you could try it on?

I assume you are powering this from the Master via the RGB cable, and that there is no other power supply involved.

Dave
Last edited by hoglet on Sun Oct 14, 2018 8:20 pm, edited 1 time in total.

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Sun Oct 14, 2018 9:00 pm

hoglet wrote:
Sun Oct 14, 2018 8:18 pm
Do you see this in all screen modes?
Yes, but it's not so noticeable in Modes 2 & 5 and gets a lot worse when using inverted video (col.129,col.0)
Also very noticeable when moving the mouse or holding a key down.
My gut feeling is noise on the +5v supply. I tried removing some internal expansions and that varied but didn't eliminate the problem
hoglet wrote:
Sun Oct 14, 2018 8:18 pm
Is this using a Pi Zero or a Pi Zero W?
It's a Pi Zero but I have some Zero W's as well and another hat so plenty of combinations to try
I tried adjusting the Mux setting but it didn't make any difference
hoglet wrote:
Sun Oct 14, 2018 8:18 pm
Is this with your own kernel, or with the standard distribution?
Standard file:
RGBtoHDMI_20180723_156dec8.zip
hoglet wrote:
Sun Oct 14, 2018 8:18 pm
How long is your cable?
30cm
hoglet wrote:
Sun Oct 14, 2018 8:18 pm
Do you have a different machine you could try it on?
Yes I just tried it on a standard BBC and it was OK
hoglet wrote:
Sun Oct 14, 2018 8:18 pm
I assume you are powering this from the Master via the RGB cable, and that there is no other power supply involved
Yes via the RGB cable
Is it OK to disconnect the +5v and power it from a standard PI supply?

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Sun Oct 14, 2018 9:31 pm

IanB wrote:
Sun Oct 14, 2018 9:00 pm
Is it OK to disconnect the +5v and power it from a standard PI supply?
I don't see why not, but it's not something I've tried myself. The reason being you would then need to be very careful about power supply sequencing, i.e. don't ever have the Beeb on and the Pi off, otherwise you risk damaging the CPLD.

Anyway, I don't think this a +5V power supply issue, as both the Pi and CPLD run of 3.3V, so there is a regulator in the way.

I think it's a problem with noise on the CSYNC signal. This signal goes directly into the CPLD so it's quite sensitive to noise. There is some digital de-glitching in the CPLD to suppress noise, but it sounds like this is not sufficient in your case.

I've seen significant CSYNC glitches on one other Master (BigEd's). The effect was similar. It causes the pixel counter in the CPLD to be spuriously reset, which shifts the position of the current line over to the left. This looks like what you are seeing. On BigEd's system the deglitching we added to the CPLD resolved the issue completely.

If you have a scope, connect it up to CSYNC and set it to trigger on low-going pulses shorter than say 1us, with trigger level of about 2.0V. This should catch any glitches.

The source of this noise seems to be data bus contention when the data bus is switched between processor data and video data. In some Masters it seems the timing is off slightly, and bus contention can exist for a short period each clock cycle. The severity of this depends on the screen memory contents - filling with 0xFF makes things significantly worse.

It's possible some RC filtering on CSYNC would help here. But a digital solution might be better. Trouble is, there's pretty much no space left in the CPLD.

Anyway, have a play with the scope, and see if you can catch any glitches. Depending how long they are, we can decide what to do next.

Dave
Last edited by hoglet on Sun Oct 14, 2018 9:32 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Sun Oct 14, 2018 9:34 pm

There are some pictures of the CSYNC noise we captured on BigEd's Master in this post:
viewtopic.php?f=3&t=13973&p=207057&hili ... se#p207057

The glitches were ~10ns wide, so you might struggle to see them depending on your scope bandwidth.

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Sun Oct 14, 2018 9:36 pm

hoglet wrote:
Sun Oct 14, 2018 9:31 pm
Anyway, I don't think this a +5V power supply issue, as both the Pi and CPLD run of 3.3V, so there is a regulator in the way.
Yes, I tried putting a 100uF low esr capacitor across the +5v supply on the hat and that made it worse so definitely not the supply.
hoglet wrote:
Sun Oct 14, 2018 9:31 pm
I think it's a problem with noise on the CSYNC signal. This signal goes directly into the CPLD so it's quite sensitive to noise. There is some digital de-glitching in the CPLD to suppress noise, but it sounds like this is not sufficient in your case.
I agree, I put a 1nF capacitor from the sync line to ground and that got rid of it so it's likely HF noise on the sync line.
It doesn't seem to affect the picture when connected via a scart cable to a standard TV but then TVs usually filter the sync signal to get rid of any noise.

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Sun Oct 14, 2018 9:47 pm

IanB wrote:
Sun Oct 14, 2018 9:36 pm
I agree, I put a 1nF capacitor from the sync line to ground and that got rid of it so it's likely HF noise on the sync line.
Do you have a scope? If so, what model is it?

It would be great if you could capture a trace of the glitch (without the 1nF capacitor).

This is the current VHDL for glitch suppression:
https://github.com/hoglet67/RGBtoHDMI/b ... .vhdl#L187

It will reject a pulses shorter than 3 samples (i.e. ~20ns or less) which twice what we observed on BigEd's master. Your's must be worse than this.

There are ~6 free macrocells, so I might be able to beef this up a bit.

Dave

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Sun Oct 14, 2018 10:18 pm

hoglet wrote:
Sun Oct 14, 2018 9:47 pm
It would be great if you could capture a trace of the glitch (without the 1nF capacitor).
They were very obvious and frequent on my M128:

glitches.jpg
Spot the sync pulse!

glitchzoom.jpg
Looks to be around 15ns normally so your filter mostly works but that blip at the end might indicate a second glitch so maybe it's occasionally around 30ns which would cause the problems I'm seeing

Edit: replaced images with better captures
Last edited by IanB on Mon Oct 15, 2018 4:46 am, edited 5 times in total.

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Mon Oct 15, 2018 12:59 am

Now I've got it more or less running with the capacitor workaround I noticed that the image was still a bit soft on my 1600*1200 monitor so I experimented with the GPU scaling kernel and got it using nearest neighbour instead which results in really sharp edged pixels.

Edit the Config.txt file and add the following line:

scaling_kernel = 8

This setting should be OK on 1920x1080, 1920x1200, 1600x1200 & 720x576 resolutions but will look terrible on other resolutions that force non-integer scaling.

The available options are 1 to 8 with 6 being the default.

The values are:
SCALERLIB_KERNELS_TYPES_SINC=1,
SCALERLIB_KERNELS_TYPES_SINC_BLACKMAN=2,
SCALERLIB_KERNELS_TYPES_SINC_NO_SIDE_LOBES=3,
SCALERLIB_KERNELS_TYPES_SINC_HALF_FIRST_SIDE_LOBE=4,
SCALERLIB_KERNELS_TYPES_SINC_HAMMING=5,
SCALERLIB_KERNELS_TYPES_SINC_HAMMING_3PI=6,
SCALERLIB_KERNELS_TYPES_SINC_HAMMING_2_5PI=7,
SCALERLIB_KERNELS_TYPES_NEAREST_NEIGHBOUR=8,

The other values give varying compromises between sharpness and unevenness when non integer scaling.

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Mon Oct 15, 2018 8:03 am

Ian,

Those glitches are similar to what we saw on BigEd's Master - only a bit more aggressive!

What I will do this morning is see if I can squeeze a few more registers into the CPLD to make the glitch detection more robust. If this works, it may be better then the capacitor, as you really want a well defined edge for CSYNC, otherwise it adds jitter to the sampling points.

Can you do a quick test for me (with the capacitor). Put up a fairy busy MODE 7 screen (e.g. the STH archive Menu screen), or failing that just a load of text. Hit auto calibrate. Once done, clear the screen (Ctrl-L) and bring up the error statistics (which I think is left button then right button). I'd like to compare them with what I get.

I'll also try your scaling_kernel setting, I haven't experimented with that before.

I also have a 1600x1200 monitor (a HP2065). Are you using the standard setting for 1600x1200 in the config file:

Code: Select all

## 1600x1200 @ 50Hz
##
## Scale by 1:2 - 672x540 => 1344x1080
##   l/r overscan = (1600-1344)/2 = 128
##   t/b overscan = (1200-1080)/2 =  60
##
hdmi_group=2
hdmi_mode=87
hdmi_cvt=1600 1200 50 1 0 0 0
overscan_left=128
overscan_right=128
overscan_top=60
overscan_bottom=60
But it's great to see an independently build unit up and working so quickly.

Dave

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Mon Oct 15, 2018 10:26 am

IanB wrote:
Mon Oct 15, 2018 12:59 am
scaling_kernel = 8
Gosh, that certainly makes an improvement in Modes 0..6.

In Mode 7 I think it's subjective whether it's better or not.

Anyway, onto the subject of de-glitching CSYNC.

I've re-worked the de-glitching logic to use a 4-bit counter, so it should suppress CSYNC glitches of up to ~150ns.

As I don't have a Master with this behaviour myself, would you mind giving this CPLD a try?
RGBtoHDMI.zip
(8.06 KiB) Downloaded 8 times
You'll need to remove the 1nF capacitor of course.

Dave
Last edited by hoglet on Mon Oct 15, 2018 10:30 am, edited 3 times in total.

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Mon Oct 15, 2018 11:08 am

hoglet wrote:
Mon Oct 15, 2018 8:03 am
Can you do a quick test for me (with the capacitor). Put up a fairy busy MODE 7 screen (e.g. the STH archive Menu screen), or failing that just a load of text. Hit auto calibrate. Once done, clear the screen (Ctrl-L) and bring up the error statistics (which I think is left button then right button). I'd like to compare them with what I get.
errors.jpg
hoglet wrote:
Mon Oct 15, 2018 8:03 am
I also have a 1600x1200 monitor (a HP2065). Are you using the standard setting for 1600x1200 in the config file:
Yes I am using that mode, the default scaling kernel produces very soft results even on a 2:1 scale.
Note this setting will produce some horizontal unevenness in mode 7 as that isn't scaled 2:1 but it doesn't seeem to be that noticeable.
If you need some interpolation, I found that a setting of 2 provided a good compromise for Mode 7 so if you can switch this setting on the fly, perhaps use 8 for modes 0-6 and 2 for mode 7

I can't get the above mode to lock using the hdmi clock adjustment, the red bar always moves down the screen even at the lowest 623 setting (although it is very slow on that value)
hoglet wrote:
Mon Oct 15, 2018 10:26 am
As I don't have a Master with this behaviour myself, would you mind giving this CPLD a try?
moreglitches.jpg
Seems to have made it worse
I noticed there were inverted glitches in the sync signal itself, are you filtering those?
Thats two vertical lines BTW with 4 ghosts each.
Last edited by IanB on Mon Oct 15, 2018 11:14 am, edited 1 time in total.

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Mon Oct 15, 2018 2:22 pm

IanB wrote:
Mon Oct 15, 2018 11:08 am
I noticed there were inverted glitches in the sync signal itself, are you filtering those?
Ah no, those won't currently be filtered. I don't think we saw those on Ed's Master.

Let me have another think, but we are very short of registers so this may not be possible.

It does seem strange how this issue affects some Master but not others. On the other thread, Dominic said he had a similar issue, which turned out to be cracking / a dry joint on one of the power connections into the main board. It might be worth checking your connections are sound.

Dave

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Mon Oct 15, 2018 4:03 pm

Ian,

Here's another version to try....
RGBtoHDMI.zip
(7.61 KiB) Downloaded 7 times
It may not be the final version, and indeed it may not even work!

I have tested it on my Master, but as it doesn't have any glitches that's not very conclusive.

In this version, de-glitching is applied to both csync=0 and csync=1 states. A change in csync will only be registered if it remains in the new state for N consecutive samples. At the moment, N is set to 15 samples, which is 156ns. This may in fact be way too long.

You can see the VHDL here:
https://github.com/hoglet67/RGBtoHDMI/b ... .vhdl#L184

Now, the ideal value for N is slightly more than the longest glitch you want to swallow. Any longer than this may be counter productive. In particular, if a glitch happens with N samples of the true edge, then it's effect will be to delay recognition of that edge. That would introduce one or two pixels worth of jitter on that line.

It would be very useful if you could use your scope in persistence mode (with minimum hold-off) and try to better characterise the maximum duration of both positive going and negative going glitches. In my experience they are worse on a mostly white screen than a mostly black screen (i.e. when screen memory is full of 0xFF)

Anyway, see if this is any better.

Dave

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Mon Oct 15, 2018 4:39 pm

hoglet wrote:
Mon Oct 15, 2018 4:03 pm
In this version, de-glitching is applied to both csync=0 and csync=1 states. A change in csync will only be registered if it remains in the new state for N consecutive samples. At the moment, N is set to 15 samples, which is 156ns. This may in fact be way too long.
That worked, so it looks like maybe filtering the +ve going pulses in the h-sync was the solution, maybe it would now work with just a 20nS filter.
hoglet wrote:
Mon Oct 15, 2018 4:03 pm
Now, the ideal value for N is slightly more than the longest glitch you want to swallow. Any longer than this may be counter productive. In particular, if a glitch happens with N samples of the true edge, then it's effect will be to delay recognition of that edge. That would introduce one or two pixels worth of jitter on that line.
Looking at the above screen cap with the 'ghosts', they are separated from the actual sync edge by something of the order of multiples of 1uS and in fact that block seems to be about 4uS wide which is about the width of a sync pulse. This means that a glitch may not happen close to the leading or trailing edge of the actual H-sync pulse.
Are you triggering off the falling or rising edge of the sync pulse?

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Mon Oct 15, 2018 4:51 pm

Good to hear that helped.
IanB wrote:
Mon Oct 15, 2018 4:39 pm
Are you triggering off the falling or rising edge of the sync pulse?
Initially I was triggering on the rising edge. But then switched to the falling edge, based on advice from others that:
a) It was the correct thing to do
b) It's needed to support Tricky's smooth horizontal scrolling, which varies the sync pulse width (in the same way a CRT would)

Would you like to try builds with smaller values of N, say N=7 and N=3?

Dave
Last edited by hoglet on Mon Oct 15, 2018 4:53 pm, edited 2 times in total.

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Mon Oct 15, 2018 4:55 pm

hoglet wrote:
Mon Oct 15, 2018 4:51 pm
Would you like to try builds with smaller value of N, say N=7 and N=3?
Yes.
hoglet wrote:
Mon Oct 15, 2018 4:51 pm
b) It's needed to support Tricky's smooth horizontal scrolling, which varies the sync pulse width (in the same way a CRT would)
Probably best to get the detect period as short as possible as a variable sync width might get close to one of the glitch periods.
Last edited by IanB on Mon Oct 15, 2018 4:58 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Mon Oct 15, 2018 5:13 pm

IanB wrote:
Mon Oct 15, 2018 4:55 pm
hoglet wrote:
Mon Oct 15, 2018 4:51 pm
Would you like to try builds with smaller value of N, say N=7 and N=3?
Yes.
Here you go: N=15, N=7 and N=3 to try:
RGBtoHDMI.zip
(22.75 KiB) Downloaded 7 times
Other intermediate values would be possible.
IanB wrote:
Mon Oct 15, 2018 4:55 pm
hoglet wrote:
Mon Oct 15, 2018 4:51 pm
b) It's needed to support Tricky's smooth horizontal scrolling, which varies the sync pulse width (in the same way a CRT would)
Probably best to get the detect period as short as possible as a variable sync width might get close to one of the glitch periods.
I think the nominal sync pulse width is 4us. A shorter pulse was 3us or 3.5us. A longer pulse was 4.5us or 5.0us.

So we are a long way from considering that a glitch (<150ns at N=15)

Dave
Last edited by hoglet on Mon Oct 15, 2018 5:15 pm, edited 4 times in total.

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Mon Oct 15, 2018 6:47 pm

hoglet wrote:
Mon Oct 15, 2018 5:13 pm
Here you go: N=15, N=7 and N=3 to try:
N=3 works fine so I haven't bothered with the N=7 as that is bound to work too.
It seems my problem was likely the inverted glitches in the h sync rather than the length of the glitches.

Do you want me to try N=1 & 2 to determine the safety margin?
Last edited by IanB on Mon Oct 15, 2018 6:58 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Mon Oct 15, 2018 7:43 pm

IanB wrote:
Mon Oct 15, 2018 6:47 pm
Do you want me to try N=1 & 2 to determine the safety margin?
Why not....
RGBtoHDMI.zip
(37.85 KiB) Downloaded 7 times
I wonder if it's worth making this software configurable from the Pi. There might just be the space to do that for up to n=7. This would cost 3 extra registers in the CPLD.

Edit: Yup, just.....

Code: Select all

Function    Mcells      FB Inps     Pterms      IO
Block       Used/Tot    Used/Tot    Used/Tot    Used/Tot
FB1          18/18*      31/54       45/90       6/ 9
FB2          18/18*      27/54       38/90       8/ 9
FB3          18/18*      29/54       79/90       9/ 9*
FB4          18/18*      49/54       75/90       5/ 7
             -----       -----       -----      -----
             72/72      136/216     237/360     28/34
Dave
Last edited by hoglet on Mon Oct 15, 2018 7:49 pm, edited 1 time in total.

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Mon Oct 15, 2018 8:30 pm

hoglet wrote:
Mon Oct 15, 2018 7:43 pm
Why not....
Both 1 & 2 work OK so they are very short glitches

I would say that 2 or 3 would be optimum values
hoglet wrote:
Mon Oct 15, 2018 7:43 pm
I wonder if it's worth making this software configurable from the Pi. There might just be the space to do that for up to n=7. This would cost 3 extra registers in the CPLD.
Doesn't seem that necessary, you had the right solution and timing but just missed the inverted glitches.

I had another play around with scaling_kernel and I think you should add that to config.txt, perhaps with different values for each mode so that the integer modes had a sharp scaler and the non-integer ones had a soft one.
I wonder if it's possible to change this setting on the fly as you could then have different settings for modes0-6 and mode 7 (modes 0-6 look great with a setting of 8 and mode 7 looks good with a setting of 2)

I would suggest a default of 2 or 8 for integer modes and 6 for non-integer ones.

There also appears to be a scaling_sharpness setting but I couldn't find any info about it.

Also as mentioned above, the vsync / hdmi freq. optimisation doesn't seem to be working for me as the red bar is always moving.
The error is shown as 301ppm beeb slower than pi.

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Mon Oct 15, 2018 9:01 pm

IanB wrote:
Mon Oct 15, 2018 8:30 pm
Doesn't seem that necessary, you had the right solution and timing but just missed the inverted glitches.
OK, lets go with a fixed value of 3, to give a small amount of extra margin.

I'll test this with BigEd's Master (hopefully Wednesday) and then merge this into Master.

On the other point, I don't think it's documented how to change scaling_kernel dynamically from bare metal code.

I will add it to the config files, and people can include it or not as they see fit.

Dave
Last edited by hoglet on Mon Oct 15, 2018 9:02 pm, edited 1 time in total.

User avatar
IanB
Posts: 390
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Mon Oct 15, 2018 9:22 pm

hoglet wrote:
Mon Oct 15, 2018 9:01 pm
I will add it to the config files, and people can include it or not as they see fit.
OK
If you're tweaking the config file, perhaps you could add another couple of default resolutions:
800x600 50Hz and 1024x600 50Hz
There are various 4:3 12" monitors with a resolution of 800x600 and many HDMI LCD panels of 1024x600 available on amazon and ebay and they would work with no scaling so good quality images (as long as they work at 50Hz). I intend to use one of the latter panels to replace a 6" CRT in one of the old prisma 2 based graphics systems I have and it looks like the 4:3 area of the lcd will just fill the 4:3 opening in the case.

Any thoughts on the vsync issue I mentioned above?

User avatar
hoglet
Posts: 8552
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Mon Oct 15, 2018 9:24 pm

IanB wrote:
Mon Oct 15, 2018 8:30 pm
Also as mentioned above, the vsync / hdmi freq. optimisation doesn't seem to be working for me as the red bar is always moving.
The error is shown as 301ppm beeb slower than pi.
It was quite experimental, and I didn't get much feedback. It's quite possible there are bugs.

On my system I get 439ppm (Beeb slower than Pi)

I'll need to refresh my memory of how this was meant to work. But I think the calibration is currently done just once, immediately after the Pi boots. So if you want to re-calibrate then you need to press the reset button. It does drift after a while.

Does changing the HDMI clock setting affect the rate that the red line is moving?
- For interlaced modes 624 should be the best setting
- For non-interlaced modes 623 should be the best setting

The default is HDMI Original, which puts the HDMI clock back to the standard for the Pi Mode.

On the best setting, how long does it take to cover the complete screen?

The aim was not that this be perfect. Rather that when used with double/triple buffering the rate of buffer skipping would be once every few minutes or better.

Dave

Post Reply