RGB to HDMI using a Pi Zero and a small CPLD

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
hoglet
Posts: 7694
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 Dec 03, 2018 5:49 pm

IanB wrote:
Mon Dec 03, 2018 4:16 pm
Looks good, I had to do a manual merge as I made some conflicting changes which I have just pushed.
Ah sorry about that.

I've merged that pull request and pushed again.

Actually, I ended up having to do a "force" push, because I think you added to the pull request, and I got a bit confused. Hopefully that won't cause you any problems.

I though you normally worked the night shift :D
IanB wrote:
Mon Dec 03, 2018 4:16 pm
There is one new issue I just noticed: Labyrinth now has problems with the pixel clock. This is probably due to the wrong field length resulting in a calculation error. A fix might be to time a known number of video lines such as the active 270 line video block rather than a whole field assuming the line length is unchanged or maybe fall back to known pixel clock values if an out of spec signal is detected. Also it won't genlock but it may never genlock if there is insufficient adjustment range of the HDMI PLL.
I agree with this analysis.

For whatever reason, Labyrinth uses 634 lines per frame, which gives it a vsync rate of 49.288 Hz.

I think we need to do two things:

1. For the sampling clock calculation, measure over a fixed number of lines. If we do this we can drop N_LINES from the geometry. We might also be able to drop CLOCK_FREQ, as it would then just be used I think for the PPM error.

2. For the HDMI clock calculation, we still need to measure the source vsync time, as measure_vsync currently does.

I would suggest leaving measure_vsync as is, and add a new method that measures the duration of N lines.

Code: Select all

int measure_n_lines(int n_lines);
Then calibrate_sampling_clock() would just use measure_n_lines()

And measure_vsync() would only really be needed if the HDMI clock control was enabled.

I'm happy to have a go at this now if you like?

Dave

P.S. I just spotted an amusing bug: genlock only works if the vsync indicator is visible. As soon as you turn this off you get:

Code: Select all

INFO: Lock lost probably due to mode change - resetting ReSync counter
That's now fixed:
https://github.com/hoglet67/RGBtoHDMI/c ... ef7296?w=1

User avatar
hoglet
Posts: 7694
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 Dec 03, 2018 6:38 pm

Ian,

After a bit more investigation, in seems the problem with Labyrinth is that the line time is 65us not 64us.
(i.e. Line length = 65 * 96 = 6240)

So counting over a fixed number of lines is not going to work.

I only know this because I tried! I also verified this with a scope.

I'm not really sure how best to deal with this now. I'll wait for your input before I push anything further. I'm going to finish for tonight and pick this up again tomorrow morning. I'll look at extending the range of the PLLH setting code.

Dave

P.S. My measure_n_lines ended up as:

Code: Select all

// ======================================================================
// MEASURE_N_LINES
// ======================================================================

// TODO: We might want to mitigate the effects of any I-Cache misses

measure_n_lines:
        push   {r4-r12, lr}

        // Setup R4 as a constant
        ldr    r4, =GPLEV0

        // wait for vsync
        bl     wait_for_vsync

        // skip 10 lines so we are well away from any double vsync pulses
        mov    r1, #10
measure_n_loop1:
        WAIT_FOR_CSYNC_1
        WAIT_FOR_CSYNC_0
        subs   r1, r1, #1
        bne    measure_n_loop1

        READ_CYCLE_COUNTER r7

        // now do the actual counting
measure_n_loop2:
        WAIT_FOR_CSYNC_1
        WAIT_FOR_CSYNC_0
        subs   r0, r0, #1
        bne    measure_n_loop2

        READ_CYCLE_COUNTER r6

        sub    r0, r6, r7
        pop    {r4-r12, pc}
Last edited by hoglet on Mon Dec 03, 2018 6:45 pm, edited 3 times in total.

User avatar
IanB
Posts: 307
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 » Tue Dec 04, 2018 12:39 am

hoglet wrote:
Mon Dec 03, 2018 6:38 pm
I'm not really sure how best to deal with this now. I'll wait for your input before I push anything further. I'm going to finish for tonight and pick this up again tomorrow morning. I'll look at extending the range of the PLLH setting code.
I've pushed the follow changes to get labyrinth working:
If sample clock error >5000ppm then use the previous sample clock and disable genlock. This works as long as a standard mode has been used prior to launching the game which will always be the case as it starts up in mode 7.
The time taken to capture all active lines is continuously measured now and if it varies from field to field by a large amount (>50000) like switching from labyrinth mode back to a standard mode then re-enable genlock.
The above values are somewhat arbitrary and may need to be optimised but they work with labyrinth.
I think this is the only practical solution for labyrinth and any other software that produces out of spec timings as we have no way of automatically determining the number of samples per line.
hoglet wrote:
Mon Dec 03, 2018 6:38 pm
P.S. My measure_n_lines ended up as:
...code
Even though it doesn't help with labyrinth, I think it is worthwhile adding this code or using the new continuous measurement code above to determine the sample clock as it removes the total line count variable. We will have to keep the pixel clock though as that is used to determine the sample clock PPM error and we need that in the above code.

The current code is unable to determine a valid setting for the HDMI clock for labyrinth so that's why genlock is disabled but if you can increase the range of adjustment for that then genlocking could be re-enabled.

EDIT: Maybe you could reallocate one of the LEDs to indicate when the Pi was genlocked as that might help in tracking down any problem software.
Last edited by IanB on Tue Dec 04, 2018 3:19 am, edited 1 time in total.

User avatar
IanB
Posts: 307
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 » Tue Dec 04, 2018 12:12 pm

There seems to be a problem with Acornsoft Monsters which ends up with the red bar at the top of the screen.
Acornsoft defender also exhibits this behaviour. It looks like they are switching to mode 2 with the default interlace type (in my case interlace on) then accessing the 6845 directly to invert the interlace setting and the new interlace detection code doesn't pick that up.
If I start with TV 0,0 the game screen gets detected as interlaced but if I hit the middle button to recalibrate it gets detected as non-interlaced
If I start with TV 0,1 the game screen gets detected as non-interlaced but if I hit the middle button to recalibrate it gets detected as interlaced
Last edited by IanB on Tue Dec 04, 2018 12:29 pm, edited 3 times in total.

User avatar
hoglet
Posts: 7694
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 Dec 04, 2018 12:40 pm

Hi Ian,

Just a quick heads-up.

I had a play with your overnight change, and I have mixed feeling about it.

The bit I liked is the general idea of limiting the maximum PPM error allowed for the sampling clock, and if this is exceeded falling back to the previously used value, or a default if there hasn't been a successful calibration. That will cope with the Labyrinth issue.

The bit I didn't like was inhibiting genlock when the sampling clock exceeded the maximum PPM error. Here's my rational:
1. The sampling clock and the HDMI clock are actually unrelated
2. Even with a known bad sampling clock, the estimate of the source vsync rate used to set the HDMI clock will be accurate, because it's measured
3. The inhibit genlock logic adds complexity to the system, which I believe is unwarranted (at least in this case)
4. Inhibiting genlock is confusing to the user, as there is no indication this is happening in the UI
5. The only reason genlock can fail to lock is insufficient range on the HDMI clock, which I have just fixed

So given all this, what I'm in the process of doing is taking a sub-set of changes from your commit that are unrelated to inhibit_genlock, and merging them with the work I've been doing on:
- extending the range of the HDMI Clock PLL
- getting rid of n_lines

This should take a couple of hours to finish, then I'll push everything.

Dave
Last edited by hoglet on Tue Dec 04, 2018 12:43 pm, edited 4 times in total.

User avatar
IanB
Posts: 307
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 » Tue Dec 04, 2018 1:04 pm

hoglet wrote:
Tue Dec 04, 2018 12:40 pm
The bit I didn't like was inhibiting genlock when the sampling clock exceeded the maximum PPM error. Here's my rational:
5. The only reason genlock can fail to lock is insufficient range on the HDMI clock, which I have just fixed
No problem, it was only included as a fallback if the HDMI lock range couldn't be increased as I mentioned above but it sounds like you've fixed that anyway so now there is no reason for it.

The only remaining issue I'm aware of is the interlace change in monsters etc mentioned above. I suspect the issue is that it changes too fast after the mode change for the new detection code to work so perhaps the initial old state used for comparison should come from the state determined by calibrate_sampling_clock().

User avatar
hoglet
Posts: 7694
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 Dec 04, 2018 1:35 pm

Ian,

I've just pushed all those changes:

Code: Select all

01aacf80 Pi Firmware: Correct trailing white space
2f5435a8 Pi Firmware: Allow wider adjustment of PLLH
8272d83c Pi Firmware: Limit max sampling clock deviation to 5000 PPM
5f4baf0d Pi Firmware: Correct indentation whitespace
6443ec39 Pi Firmware: Merge other changes from Ian on genlock
94865387 Pi Firmware: Remove need to specify n_lines (lines / frame)
10bc03c0 Pi Firmware: Rework measure_n_lines so it's less impacted by I-Cache misses
The PLLH setting code seems to cope with quite large variations. I accidentally used my 60Hz Atom HDMI mode on the Beeb, and genlock managed to lock it perfectly!

I then tried the other way (using a Beeb 50Hz mode with the 60Hz Atom) and that failed, but only because it bumped the clock from 148.5MHz to 177.5MHz, which I think exceeds the maximum for HDMI 1.0 which is 165MHz.

Let me know if you have any problems re-syncing your dev branch, or indeed if you spot anything I missed, or any new bugs.

By the way, in case it's needed in the future, I did save your overnight pull request to a branch:
https://github.com/hoglet67/RGBtoHDMI/tree/ian_pull_21

I'll have a look at the Monsters issue after lunch.

Dave

User avatar
IanB
Posts: 307
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 » Tue Dec 04, 2018 1:48 pm

hoglet wrote:
Tue Dec 04, 2018 1:35 pm
I'll have a look at the Monsters issue after lunch.
OK
I'm pretty certain the problem is this:
monsters changes from mode 7 to mode 2 triggering a recalibration
calibrate_sampling_clock() determines interlace/non interlace and vsync length
monsters changes interlace
new interlace code waits to determine initial previous value of interlace then loops around comparing previous with new but by then it's too late as it has missed the change. The new interlace code should use the interlace setting determined by calibrate_sampling_clock() as it's initial previous value so it catches the change.
Last edited by IanB on Tue Dec 04, 2018 1:49 pm, edited 1 time in total.

User avatar
hoglet
Posts: 7694
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 Dec 04, 2018 2:09 pm

IanB wrote:
Tue Dec 04, 2018 1:48 pm
I'm pretty certain the problem is this:
monsters changes from mode 7 to mode 2 triggering a recalibration
calibrate_sampling_clock() determines interlace/non interlace and vsync length
monsters changes interlace
new interlace code waits to determine initial previous value of interlace then loops around comparing previous with new but by then it's too late as it has missed the change. The new interlace code should use the interlace setting determined by calibrate_sampling_clock() as it's initial previous value so it catches the change.
Let me give that a try...

User avatar
hoglet
Posts: 7694
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 Dec 04, 2018 3:22 pm

I've changed to that approach, which I think will ultimately be better.
https://github.com/hoglet67/RGBtoHDMI/c ... 407b6e?w=1

But it seems that with Monsters, measure_vsync occasionally incorrectly determines the interlace.

Here's an example:

Code: Select all

INFO: Framebuf struct address: 0x8010000
INFO: Initialised Framebuffer: 672x540 
INFO: Pitch: 336 bytes
INFO: Framebuffer address: DF94A000
INFO:   clkinfo.clock    = 96000000 Hz
INFO:   clkinfo.line_len = 6144
INFO:      GPCLK Divisor = 12
INFO: Nominal core clock = 384000000 Hz
INFO:  Nominal 100 lines = 6400000 ns
INFO:   Actual 100 lines = 6402839 ns
INFO:        Clock error = 443 PPM
INFO:  Target core clock = 383829735 Hz
INFO:   Final core clock = 383829735 Hz
INFO:  Actual frame time = 39953667 ns (interlaced)
INFO: Lock lost probably due to mode change - resetting ReSync counter

You can tell from the number of lines (39953667 / 64028.39) = 623.999 that the frame was non-interlaced. But it is incorrectly detected as interlaced based on the field pattern.

I've currently no idea why this is happening, but I suspect a race condition, i.e. the change from interlaced to non-interlaced happens while measure_vsync is running. I can't replicate this with my simple test program.

As a work around, I've quickly switched to determining interlace based on whether the number of lines is odd or even:
https://github.com/hoglet67/RGBtoHDMI/c ... dc6cbc54d1

Dave
Last edited by hoglet on Tue Dec 04, 2018 3:23 pm, edited 2 times in total.

User avatar
IanB
Posts: 307
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 » Tue Dec 04, 2018 5:39 pm

hoglet wrote:
Tue Dec 04, 2018 3:22 pm
I've currently no idea why this is happening, but I suspect a race condition, i.e. the change from interlaced to non-interlaced happens while measure_vsync is running.
That seems likely
hoglet wrote:
Tue Dec 04, 2018 3:22 pm
As a work around, I've quickly switched to determining interlace based on whether the number of lines is odd or even:
https://github.com/hoglet67/RGBtoHDMI/c ... dc6cbc54d1
That works OK, no problems found so far.
I think pretty much all of the outstanding issues have been addressed.

User avatar
hoglet
Posts: 7694
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 » Thu Dec 06, 2018 1:41 pm

Hello all,

Just a quick note to say the next software release is imminent (probably tomorrow).

In the mean time, I've spent some time updating the User Guide to cover the new features:
https://github.com/hoglet67/RGBtoHDMI/w ... -interface

This is the second revision of the manual and covers additional features in the forthcoming December 2018 release:
- A redesigned (multi-line) menu system that is easier to navigate
- Deinterlacing (of Mode 7, multiple algorithms)
- Genlocking (and a VSync indicator)
- Support for a wider range of systems (e.g. Atom, UK101) with widely varying video timings

Dave
Last edited by hoglet on Thu Dec 06, 2018 1:54 pm, edited 1 time in total.

User avatar
IanB
Posts: 307
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 » Thu Dec 06, 2018 7:10 pm

hoglet wrote:
Thu Dec 06, 2018 1:41 pm
Just a quick note to say the next software release is imminent (probably tomorrow).
I just found a problem with the labyrinth fix:
As the ZX80 uses a ceramic resonator it can have very large ppm errors, mine is currently over 8000ppm so it fails the >5000ppm test and uses the default clock which is completely wrong.
There are two possible fixes for this:
1. Increase the ppm value
2. Inhibit the >5000ppm test if m7disable is set (really the m7disable is a BBC / !BBC switch so maybe it would be better to rename it as such)
I patched the code using the latter setting as it is a bit more determinate that varying the ppm level but I'll leave it up to you to select the option you prefer.

User avatar
hoglet
Posts: 7694
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 » Thu Dec 06, 2018 7:17 pm

Ian,

That's a good spot.
IanB wrote:
Thu Dec 06, 2018 7:10 pm
There are two possible fixes for this:
1. Increase the ppm value
2. Inhibit the >5000ppm test if m7disable is set (really the m7disable is a BBC / !BBC switch so maybe it would be better to rename it as such)
What do you think about:
3. Make the max clock error (ppm) configurable, with a default of 10,000ppm.

Labyrinth uses 65us lines, so the error there is 65/64 = ~15,625ppm.

I don't know of any other games that use out-of-spec lines, do you?

Dave
Last edited by hoglet on Thu Dec 06, 2018 7:21 pm, edited 1 time in total.

User avatar
IanB
Posts: 307
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 » Thu Dec 06, 2018 7:32 pm

hoglet wrote:
Thu Dec 06, 2018 7:17 pm
3. Make the max clock error (ppm) configurable, with a default of 10,000ppm.
Sure, if you want to do it that way. I was just trying to avoid adding another tweak but I suppose these arbitrary values should be tweakable.
I suggest that setting a value of 0 switches it off.
Last edited by IanB on Thu Dec 06, 2018 7:33 pm, edited 1 time in total.

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

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

Post by tricky » Fri Dec 07, 2018 10:39 am

I was looking at bbc2dvi this morning as I wanted to check whether it supported hsync pulse width alignment; the manual didn't say.
While I was in the manual I noticed that he has a set config/palette from displayed pixels and was thinking that it might be nice to be compatible (for comon functionality) as auto detect isn't possible.

User avatar
hoglet
Posts: 7694
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 » Fri Dec 07, 2018 12:25 pm

tricky wrote:
Fri Dec 07, 2018 10:39 am
While I was in the manual I noticed that he has a set config/palette from displayed pixels and was thinking that it might be nice to be compatible (for comon functionality) as auto detect isn't possible.
That's a timely post! I was just thinking of the options for how we do this.

I'm going to publish a long overdue beta release very shortly, but between that and the final release I would like to add a couple more things:
- control of the palette from the Beeb
- auto-calibration on power up

I'm not keen on trying to be compatible with John's approach. His works is all closed source, the palette protocol is not documented, and I don't particularly want to go down the path of reverse engineering it from his BASIC program.

Dave

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

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

Post by tricky » Fri Dec 07, 2018 3:06 pm

Sorry, I hadn't looked at the details, but it looks like he included the dither pattern that I (I think it was me) suggested in RobC's video NULA thread.
The next best thing would be make sure that if pixel patterns are used that they cannot generate his magic numbers, even something simple like using MODE 1/4/6? which would then also work on a model A.
I still like the idea of using the hsync pulse, but for higher BW, the display makes sense.
If this went as far as sprites, or sound!, then a combination enabled by the first few hsyncs after a vsync and data hidden (blanked by PI) in the first n lines of the display would be the ultimate.

User avatar
hoglet
Posts: 7694
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 » Fri Dec 07, 2018 3:42 pm

Hi Guys,

A new binary release is finally available:
https://github.com/hoglet67/RGBtoHDMI/releases

And updated documentation can be found here:
https://github.com/hoglet67/RGBtoHDMI/w ... Guide-(v2)

Many thanks to Ian (IanB) and Dominic (dp11) for their help over the last couple of months. Ian did all of the work on Mode 7 Deinterlacing and Genlock. Dominic did lots of performance improvements to ARM assembler code.

Here's a summary of the changes:

Pi Firmware:
- A redesigned (multi-line) menu system that is easier to navigate
- Faster/better auto calibration algorithm in mode 7
- Added "Bob" Deinterlacing algorithm for mode 7
- Added "Advanced Motion Adaptive" Deinterlacing algorithm for mode 7 (CPLDv2 only)
- New delay parameter in sampling menu to fine tune horizontal position (CPLDv2 only)
- HDMI clock calibration (including full Genlock capability to lock source and HDMI Vsync)
- Re-purpose LED1 as a three-state Genlock indicator (off, flash, on)
- Support a wider range of HDMI clock adjustment (within the HDMI 1.0 limits)
- Added a VSync indicator
- Auto Calibration now works with non-standard video timings (e.g. 3D Pool, Labyrinth, Monsters)
- Change of interlace now treated as a mode change
- Configurable key-map to redefine button use
- Buttons now auto repeat (makes changing values easier)
- Improved user feedback during HDMI Clock Calibration
- Improved user feedback during Auto Calibration
- Many assembler code performance optimizations
- Configurable geometries and sampling clocks through geometry menu (*)
- Support for 8-bits/pixel frame buffer (*)
- Added more HDMI modes to config.txt (*)
- Added examples of non-Acorn/BBC systems to cmdline.txt (*)

(*) Features to support non-Acorn/BBC systems

CPLD:
- Add 4-bit delay parameter (that allows fine tuning of horizontal position)
- Start sampling line 8us earlier (to support non-Acorn/BBC systems)
- Version updated to 2.1

Certain new features (marked above) are dependent on an updated version of the CPLD. But the system detects what you have, and (hopefully) degrades gracefully.

Consider this a beta release - there will be bugs to fix and there are some other things I'd like to add over the next couple of weeks.

Feedback, as always, is most welcome.

Dave

User avatar
trixster
Posts: 693
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 » Fri Dec 07, 2018 4:48 pm

Is this binary good to go with an Atom? Or does that require a different binary?
A3020 | A3000 | A420/1 | BBC B + 128K RAM/ROM + 20K Shadow + Pi0 + VideoNuLA
Master Turbo + DC + BeebSID | Atom | A4000 060 | A3000 060 | A1200 060 | A500
Atari Falcon 060 | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar

User avatar
hoglet
Posts: 7694
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 » Fri Dec 07, 2018 4:58 pm

trixster wrote:
Fri Dec 07, 2018 4:48 pm
Is this binary good to go with an Atom? Or does that require a different binary?
It should work with Phill's V5 colour board - I've not been able to test that yet (my V5 PCB is in the post).

You just need to make two config changes:
- in config.txt, switch to an appropriate 60Hz screen mode
- in cmdline.txt, switch to one of the Atom specific config lines

Also, ignore the "Atom" palettes, the are for my prototype atom hardware that supports orange.

Dave
Last edited by hoglet on Fri Dec 07, 2018 4:59 pm, edited 1 time in total.

User avatar
trixster
Posts: 693
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 » Fri Dec 07, 2018 6:50 pm

What settings best replicate the 5x mode from earlier in the thread?
A3020 | A3000 | A420/1 | BBC B + 128K RAM/ROM + 20K Shadow + Pi0 + VideoNuLA
Master Turbo + DC + BeebSID | Atom | A4000 060 | A3000 060 | A1200 060 | A500
Atari Falcon 060 | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar

User avatar
hoglet
Posts: 7694
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 » Fri Dec 07, 2018 7:52 pm

trixster wrote:
Fri Dec 07, 2018 6:50 pm
What settings best replicate the 5x mode from earlier in the thread?
Try uncommenting these sections (and make sure the the default are commented)

config.txt:

Code: Select all

## Example Atom Setting (scaling by 2.5)
##
## 1600x1200 @ 60Hz
##
## Scale by 1:3 - 552x424 => 1380x1060
##   l/r overscan = (1600-1380)/2 = 110
##   t/b overscan = (1200-1060)/2 = 70
##
hdmi_group=2
hdmi_mode=51
overscan_left=110
overscan_right=110
overscan_top=70
overscan_bottom=70
cmdline.txt:

Code: Select all

# Here's an example that might work with an Atom (CPLDv1) (wider border)
sampling=0,5,5,5,5,5,5,0 geometry=0,31,69,212,552,424,4,85909091,5472 nbuffers=2 m7disable=1
Dave

noggin
Posts: 21
Joined: Mon Jul 17, 2017 3:06 pm
Contact:

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

Post by noggin » Fri Dec 07, 2018 8:31 pm

I notice quite a lot of references to HDMI 1.0 limits.

Is this for a specific reason? AIUI the Pi can go quite a lot further than HDMI 1.0 pixel clock limits should you need it to.

I don't know about Zeroes but my Pi 3B+ happily does a 297MHz Pixel Clock to deliver an HDMI 1.4 3840x2160/30Hz RGB 8-bit output (and can also do a non-standard 275MHz 3840x2160/25Hz RGB 8-bit output that my Sony UHD TV and HD Fury Vertex both seem OK with) and the VPU/GPU is common to both? I've had a Pi Zero running at quite high pixel clock rates too.

I don't know if this is relevant - but thought I'd mention it.
Last edited by noggin on Fri Dec 07, 2018 8:32 pm, edited 2 times in total.

User avatar
hoglet
Posts: 7694
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 » Fri Dec 07, 2018 9:05 pm

noggin wrote:
Fri Dec 07, 2018 8:31 pm
I notice quite a lot of references to HDMI 1.0 limits.

Is this for a specific reason? AIUI the Pi can go quite a lot further than HDMI 1.0 pixel clock limits should you need it to.

I don't know about Zeroes but my Pi 3B+ happily does a 297MHz Pixel Clock to deliver an HDMI 1.4 3840x2160/30Hz RGB 8-bit output (and can also do a non-standard 275MHz 3840x2160/25Hz RGB 8-bit output that my Sony UHD TV and HD Fury Vertex both seem OK with) and the VPU/GPU is common to both? I've had a Pi Zero running at quite high pixel clock rates too.

I don't know if this is relevant - but thought I'd mention it.
Thanks for that. I wasn't aware the Pi Zero could go that high.

These current limits (25MHz - 165MHz) are a crude attempt to stop the HDMI clock going way out of range if the genlock code needs to change the clock by a massive amount due mis-configuration (e.g. trying to genlock a 60Hz source to a 50Hz HDMI mode).

What I should really be doing is reading the EDID and respecting the monitor's maximum pixel clock. That's on the TODO list.

Dave

User avatar
trixster
Posts: 693
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 » Fri Dec 07, 2018 11:12 pm

hoglet wrote:
Fri Dec 07, 2018 7:52 pm
trixster wrote:
Fri Dec 07, 2018 6:50 pm
What settings best replicate the 5x mode from earlier in the thread?
Try uncommenting these sections (and make sure the the default are commented)

config.txt:

Code: Select all

## Example Atom Setting (scaling by 2.5)
##
## 1600x1200 @ 60Hz
##
## Scale by 1:3 - 552x424 => 1380x1060
##   l/r overscan = (1600-1380)/2 = 110
##   t/b overscan = (1200-1060)/2 = 70
##
hdmi_group=2
hdmi_mode=51
overscan_left=110
overscan_right=110
overscan_top=70
overscan_bottom=70
cmdline.txt:

Code: Select all

# Here's an example that might work with an Atom (CPLDv1) (wider border)
sampling=0,5,5,5,5,5,5,0 geometry=0,31,69,212,552,424,4,85909091,5472 nbuffers=2 m7disable=1
Dave
I’ll give it a try! I had literally 5 mins to test the binary and chose the thin border and immediately noticed that the banner text looked really quite different to the old binary. I’ll spend more time tomorrow and stop asking bone questions! :D
A3020 | A3000 | A420/1 | BBC B + 128K RAM/ROM + 20K Shadow + Pi0 + VideoNuLA
Master Turbo + DC + BeebSID | Atom | A4000 060 | A3000 060 | A1200 060 | A500
Atari Falcon 060 | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar

Post Reply