RGB to HDMI using a Pi Zero and a small CPLD

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
Post Reply
User avatar
tricky
Posts: 3503
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Sun Jul 15, 2018 3:21 pm

I'm not near a beeb, but I would expect making the pulse wider would delay the effective timing and move the visible pixels to the left.

I believe rally-x works in the same way as 3d pool's scrolls, although i do tidy the sides.

User avatar
hoglet
Posts: 8277
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 Jul 15, 2018 3:49 pm

tricky wrote:
Sun Jul 15, 2018 3:21 pm
I'm not near a beeb, but I would expect making the pulse wider would delay the effective timing and move the visible pixels to the left.
OK, that's what my current implementation does.

Is the idea behind this that a CRT would actually be using the centre of the pulse?
tricky wrote:
Sun Jul 15, 2018 3:21 pm
I believe rally-x works in the same way as 3d pool's scrolls, although i do tidy the sides.
There is at least one difference....
- RallyX uses R3 values 8 (4us) and 9 (4.5us).
- 3D Pool uses R3 values 7 (3.5us) and 8 (4.0us).

So I don't think a single threshold implementation is going to work with both of these.

Are you aware of any other implementations of this?

I did find a test program:
viewtopic.php?p=38681#p38681

But it doesn't work for me, it just hangs.

I'm also interested in testing smooth vertical scrolling. What would you recommend I try?

Dave
Last edited by hoglet on Sun Jul 15, 2018 3:50 pm, edited 2 times in total.

User avatar
hoglet
Posts: 8277
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 Jul 15, 2018 3:50 pm

(Edited above post slightly)

User avatar
tricky
Posts: 3503
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Sun Jul 15, 2018 4:02 pm

I've always thought that the TV uses the centre of the pulse.
If it is easier to only support 7 or 8, rather than start + 1/2 width, I can change the rally-x default.
I thought one of the scramble clones might have and maybe JCB digger. I have some old code and I suspect richtw might.
Astro blaster uses vertical scrolling for the aliens and phoenix, but not smoothly. Somewhere I have a vertical scrolling demo posted.
White light and fire track also scroll, but with slightly different methods.
EDIT: added Vscroll framework http://www.retrosoftware.co.uk/forum/vi ... work#p7933
Last edited by tricky on Sun Jul 15, 2018 4:10 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8277
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 Jul 15, 2018 5:43 pm

tricky wrote:
Sun Jul 15, 2018 4:02 pm
I've always thought that the TV uses the centre of the pulse.
That does seem to be the case.
tricky wrote:
Sun Jul 15, 2018 4:02 pm
If it is easier to only support 7 or 8, rather than start + 1/2 width, I can change the rally-x default.
I've update the Pi code to support two thesholds, so it does the right thing now with R3=7,8 and 9:
https://github.com/hoglet67/RGBtoHDMI/c ... 40da6b66f8
tricky wrote:
Sun Jul 15, 2018 4:02 pm
I thought one of the scramble clones might have and maybe JCB digger. I have some old code and I suspect richtw might.
Astro blaster uses vertical scrolling for the aliens and phoenix, but not smoothly. Somewhere I have a vertical scrolling demo posted.
White light and fire track also scroll, but with slightly different methods.
EDIT: added Vscroll framework http://www.retrosoftware.co.uk/forum/vi ... work#p7933
Thanks for these - they all seem to work reasonable well.

So the remaining issue is that 3D Pool "1000 Scrolls" still looks rubbish, specifically quite a lot of judder.

Looking on the scope, it's using non-interlaced video with 320 lines per field (and 64us per line), so a field rate of 48.8Hz.

One of the current "known issues" with RGBtoHDMI is the 50Hz HDMI clock is free-running, i.e. it's not "genlocked" to the Beebs clock. This might be possible in the future, but the documentation for how to adjust the HDMI PLL (PLL H I think) is not clear.

In Modes 0..6 RGB-to-HDMI uses double buffering to avoid tearing. Normally a Beeb is 50Hz +/- 500ppm, which corresponds to ~1 skipped or dropped frame every 2000. i.e. One every 40 seconds. You can spot this if you really look hard, but it's not too bad.

Anyway, at 48.8Hz we are skipping one frame every 42, i.e. about one every 1.2 seconds. This makes it look rubbish!

Not sure there's much I can do about this, until we find a way to control PLL H.

Dave
Last edited by hoglet on Sun Jul 15, 2018 5:45 pm, edited 4 times in total.

User avatar
tricky
Posts: 3503
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Sun Jul 15, 2018 6:10 pm

Does PLLH allow the 50hz to be adjusted?
Might it be possible to remove the frame delay in the future?

User avatar
hoglet
Posts: 8277
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 Jul 15, 2018 6:37 pm

tricky wrote:
Sun Jul 15, 2018 6:10 pm
Does PLLH allow the 50hz to be adjusted?
Might it be possible to remove the frame delay in the future?
It does allow the HDMI Pixel clock to be adjusted, and all other timings derive from this.

You can statically create a custom HDMI mode with an arbitrary pixel clock using the hdmi_timings statement in config.txt.

What I'm less sure about is whether it can by adjusted on the fly without stopping the PLL, which would cause the display to loose sync. There is a mail box command to adjust it, I didn't have much success when I tried it a while ago.

Dave

User avatar
hoglet
Posts: 8277
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 Jul 16, 2018 8:12 pm

tricky wrote:
Sun Jul 15, 2018 6:10 pm
Does PLLH allow the 50hz to be adjusted?
Might it be possible to remove the frame delay in the future?
Whilst waiting for the correct Molex pins to come from RS (which they just have!), I've been experimenting with the HDMI Pixel Clock.

The first thing I wanted to explore is whether it's possible create a variation of a standard HDMI mode with a slightly tweaked clock for a specific Beeb. So I started with a definition for a standard 1920x1080 50Hz Mode, and tested this worked.

Code: Select all

hdmi_timings=1920 1 528 44 148 1080 1 5 5 35 0 0 0 50 0 148500000 3
The big number at the end is the standard HDMI Pixel Clock: 148.5MHz.

With this "default" speed and Tricky's RallyX, I see a frame dropped approx every 20 seconds.

To try to correct this, we need to slow down the pixel clock a bit.

There are actually two things to compensate for:
1. RallyX is using non-interlaced mode, which is means the vsync rate is actually 50 * (625/624) = 50.080Hz
2. The Beeb and Pi's clock disagree by 780ppm (the Pi being faster in this instance)

The 780ppm comes from the RGBtoHDMI log, where it accurately measures the Beeb's VSync time:

Code: Select all

INFO:  Nominal frame time = 39936000 ns (non-interlaced)
INFO:   Actual frame time = 39967157 ns
INFO:    Frame time error = 780 PPM
We can calculate the corrected pixel clock as:
- 148.5MHz * (625/624) * (39936000/39967157)
- 148.622030

So what goes in config.txt looks like:

Code: Select all

hdmi_timings=1920 1 528 44 148 1080 1 5 5 35 0 0 0 50 0 148622030 3
(i.e. just the clock rate changes)

With this in place, I have yet to see a dropped or repeated frame.

Dave
Last edited by hoglet on Mon Jul 16, 2018 8:22 pm, edited 1 time in total.


User avatar
hoglet
Posts: 8277
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 » Tue Jul 17, 2018 4:12 pm

Hi Guys,

All the DIN to Molex cables now finished and everything is packaged and ready to go.

Everyone on the list should have just received a PM with payment details, and a request for your postal address.

Hopefully everything will get posted tomorrow.

regards

Dave

User avatar
hoglet
Posts: 8277
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 » Tue Jul 17, 2018 8:53 pm

I've started work on a User Guide here:
https://github.com/hoglet67/RGBtoHDMI/w ... User-Guide

Any questions, corrections or things that aren't clear please let me know.

User avatar
Elminster
Posts: 3547
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 » Tue Jul 17, 2018 9:05 pm

Looking good. Was there anything particular you want people to try or test? A script if you will. Or just let us loose?

User avatar
hoglet
Posts: 8277
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 » Tue Jul 17, 2018 9:22 pm

Elminster wrote:
Tue Jul 17, 2018 9:05 pm
Looking good. Was there anything particular you want people to try or test? A script if you will. Or just let us loose?
Here's a few thoughts....

Testing on many machines would be useful. Each system will be a bit different timings wise. If I get time, I'll extend the info screen tomorrow to display the clock error (in ppm) which is a useful number to see. Currently you have to have the serial able attached to see this in the log. It would be interesting to see this if this changes much over time, as that would suggest periodic recalibration might be beneficial.

Mode 7 on Model B is the most challenging to deal with. When you run the Auto Calibration, is the result error free in any positions? If not, does reducing C48 to 100pF help?

Try games that do funny things with the 6845, like most of Tricky's. RallyX using the smooth horizontal scrolling (by varying sync width) for example.

If you spot any weird artefacts that are repeatable, or anything else that is generally annoying, let me know.

I guess there is also monitor specific stuff. It took me a while to find the right aspect ratio setting on my Monitor, so it do any further (unwanted) scaling. I'll post some test programs that put up simple grids that let you see if the monitor is set correctly.

Dave

User avatar
trixster
Posts: 865
Joined: Wed May 06, 2015 11:45 am
Location: York
Contact:

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

Post by trixster » Wed Jul 18, 2018 9:03 am

The instructions look great! Looking forward to the delivery :)
A3020 | A3000 | A420/1 | BBC B | Master Turbo | ZX48K | NeoGeo
Atom | Amiga A4000 | A3000 | A1200 | A500 | PC Engine | Enterprise
Falcon | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar | X68000 | CD32

User avatar
hoglet
Posts: 8277
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 » Wed Jul 18, 2018 9:52 am

trixster wrote:
Wed Jul 18, 2018 9:03 am
The instructions look great! Looking forward to the delivery :)
All units (except for z0m8ied0g) have now been posted.

The UK ones should arrive tomorrow (Royal Mail 1st Class Signed For).

The USA one for Myelin should take about a week.

On a different note, is anyone intending to use a Pi Zero W? (The original Pi Zero seems very hard to buy now).

I bought a Pi Zero W to test with and that arrived yesterday. When I first tried it, 50% of the time it worked and 50% of the time it wouldn't boot. But after updating RGBtoHDMI to use newer firmware, that seems to have resolved the issue. So I've pushed that change back to github.

Dave

User avatar
hoglet
Posts: 8277
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 » Wed Jul 18, 2018 9:58 am

One other thing I should stress....

Please do fit the two PCB standoffs (between the Pi and the Hat) to the edge of the Pi with the switches.

I didn't do this with my original test board (#01) and after a couple of weeks of heavy usage, the connector seems to have become a bit unreliable with all the flexing. I'll need to try to desolder it and fit a new connector. #-o

Dave

User avatar
Elminster
Posts: 3547
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 » Wed Jul 18, 2018 10:53 am

Will watch out for it. I will use a pi zero (dont hav any W's) have around 6 or so I can borrow, and some point will by a dedicated one.

Would using a 3b+ provide any advantage, ignoring the larger form factor etc. I wounder if would be possible to do a zero, version for internal fitting, and a £b+ external version (but would only be worth doing if it provide any advantage over a zero).

User avatar
hoglet
Posts: 8277
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 » Wed Jul 18, 2018 11:04 am

Elminster wrote:
Wed Jul 18, 2018 10:53 am
Would using a 3b+ provide any advantage, ignoring the larger form factor etc. I wounder if would be possible to do a zero, version for internal fitting, and a £b+ external version (but would only be worth doing if it provide any advantage over a zero).
I don't think a Pi 3 B+ version would even work.

A while back I've tried to get a Pi 3 working, and even overclocked it can't sample Modes 0..6 reliably. It seems the cache miss latency is longer on the BCM2836/BCM2837 than with the BCM2835. I gave up in the end as what's the point when the Pi Zero does everything we need of it?

Also, software development/testing is so much easier when everyone uses the same hardware.

Oh, and the bigger Pi's draw far more current, so powering down the RGB cable starts to get a bit dodgy.
https://raspi.tv/2018/how-much-power-do ... asurements

Dave
Last edited by hoglet on Wed Jul 18, 2018 11:05 am, edited 2 times in total.

User avatar
trixster
Posts: 865
Joined: Wed May 06, 2015 11:45 am
Location: York
Contact:

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

Post by trixster » Wed Jul 18, 2018 11:44 am

I will test with a Pi0W and old Pi0
A3020 | A3000 | A420/1 | BBC B | Master Turbo | ZX48K | NeoGeo
Atom | Amiga A4000 | A3000 | A1200 | A500 | PC Engine | Enterprise
Falcon | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar | X68000 | CD32

User avatar
hoglet
Posts: 8277
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 » Wed Jul 18, 2018 12:29 pm

The User Guide is pretty much finished now. I've added a few more photos, and finished the section about Calibration.

I've also pushed a release to github that includes:
- the zip file for the SD Card
- a .ssd with a few simple test programs

Dave
Last edited by hoglet on Wed Jul 18, 2018 1:11 pm, edited 3 times in total.

User avatar
tricky
Posts: 3503
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Wed Jul 18, 2018 1:05 pm

I was thinking of getting a zero W, but I would want to swap it for a PiTubeDirect CoPro as that seems like a place where the W might be useful.

User avatar
Elminster
Posts: 3547
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 » Wed Jul 18, 2018 1:37 pm

tricky wrote:
Wed Jul 18, 2018 1:05 pm
I was thinking of getting a zero W, but I would want to swap it for a PiTubeDirect CoPro as that seems like a place where the W might be useful.
I am not sure the 'W' is useful anywhere at present.

User avatar
Elminster
Posts: 3547
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 » Wed Jul 18, 2018 1:40 pm

hoglet wrote:
Wed Jul 18, 2018 11:04 am
Elminster wrote:
Wed Jul 18, 2018 10:53 am
Would using a 3b+ provide any advantage, ignoring the larger form factor etc. I wounder if would be possible to do a zero, version for internal fitting, and a £b+ external version (but would only be worth doing if it provide any advantage over a zero).
I gave up in the end as what's the point when the Pi Zero does everything we need of it?
No particular features in mind, just wondered if extra cores, clock speed or mem was of any use.

Budgie
Posts: 87
Joined: Mon Nov 02, 2015 9:14 pm
Location: Manchester, UK
Contact:

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

Post by Budgie » Wed Jul 18, 2018 10:13 pm

Looking forward to the delivery. You are a one man industry Dave. Hardware, software and documentation to a very high standard. Great product to boot !!

User avatar
Elk Towers
Posts: 501
Joined: Sun Apr 23, 2006 2:10 am
Location: Kettering, Northants
Contact:

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

Post by Elk Towers » Thu Jul 19, 2018 11:19 am

Mine has arrived = thank you Dave
Nick

User avatar
Elminster
Posts: 3547
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 » Thu Jul 19, 2018 12:14 pm

Mine arrived as well.

Edit: But mini HDMI arrives tomorrow.
Last edited by Elminster on Thu Jul 19, 2018 12:58 pm, edited 1 time in total.

Budgie
Posts: 87
Joined: Mon Nov 02, 2015 9:14 pm
Location: Manchester, UK
Contact:

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

Post by Budgie » Thu Jul 19, 2018 12:31 pm

Missed mine. Stuck at the post office, will grab it tomorrow. Thanks Dave

User avatar
trixster
Posts: 865
Joined: Wed May 06, 2015 11:45 am
Location: York
Contact:

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

Post by trixster » Thu Jul 19, 2018 5:31 pm

Likewise. Will try and grab tomorrow.
A3020 | A3000 | A420/1 | BBC B | Master Turbo | ZX48K | NeoGeo
Atom | Amiga A4000 | A3000 | A1200 | A500 | PC Engine | Enterprise
Falcon | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar | X68000 | CD32

User avatar
1024MAK
Posts: 8878
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

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

Post by 1024MAK » Thu Jul 19, 2018 7:06 pm

tricky wrote:
Sun Jul 15, 2018 4:02 pm
I've always thought that the TV uses the centre of the pulse.
No. In most analogue CRT TVs, the synchronisation pulses are used to synchronise two free running 'oscillators', one for the horizontal defection system and one for the vertical defection. Note that each 'oscillator' is actually a current ramp (or sawtooth) generator (or it's output is converted to a current ramp/sawtooth waveform). Also the time period for each 'oscillator' is slightly longer than the TV standard specifications so allowing a correctly received signal to stay 'locked'.

So in an analogue CRT television, the line/horizontal synchronation pulses take effect a little while after the first edge (the falling edge, the drop from black/blanking level to the lower sync. level). The exact time delay depending on the delays and filtering in the circuit. Not the centre of the pulse, or the end.

As more complex chips became available, so improved circuitry was developed, this more complex circuitry uses phase detectors to compare the TVs own oscillator with the detected incoming sync pulses. The resulting error signal then either speeds up or slows down the oscillator. In other words, a phase-locked-loop. The time constant being chosen to be long compared to the period of one line. This reduces disruption due to interference or noise. Note that there is a second mode where the time constant is reduced, it is used to enable quick rapid lock to a new channel (when changing channels) or in some TVs, when using a composite, S-Video (and maybe RGB) inputs (to cope with VCRs etc).

Of course, in an LCD TV, it's just another input to the control system electronics.

But any description or diagram of an analogue TV signal always uses the first edge (the falling edge) of the line/horizontal synchronisation pulse as the time reference for all the timings of the features of the video line signals. It is also important that a black/blanking level is present before the sync pulses (known as front porch) so that the leading edge of the line sync pulse can be cleanly detected by the television circuitry. Line sync pulses should be 4.7 +/-0.1us.

Mark
Last edited by 1024MAK on Thu Jul 19, 2018 7:34 pm, edited 3 times in total.

User avatar
tricky
Posts: 3503
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Thu Jul 19, 2018 9:56 pm

Why does changing the sync pulse width on a crt but not it's start move the image by exactly (as far as I can tell) half the change in width.
Last edited by tricky on Thu Jul 19, 2018 9:57 pm, edited 1 time in total.

Post Reply