RGB to HDMI using a Pi Zero and a small CPLD

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
BigEd
Posts: 2139
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

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

Post by BigEd » Tue Nov 06, 2018 11:06 am

Quick question Dave: does a reverse-video K have very much the same sort of problem, or something different?

User avatar
hoglet
Posts: 7596
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 Nov 06, 2018 11:19 am

BigEd wrote:
Tue Nov 06, 2018 11:06 am
Quick question Dave: does a reverse-video K have very much the same sort of problem, or something different?
The nearest you can do to reverse-video is blue characters with a white background.

If anything, I think the problem is worse, because that single pixel in the corner of the K is always filled in.

Dave

User avatar
BigEd
Posts: 2139
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

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

Post by BigEd » Tue Nov 06, 2018 12:15 pm

Thanks! I was thinking of the earlier discussion where there were suggestions for moving the threshold - there's the 010 case and the 101 case.

User avatar
hoglet
Posts: 7596
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 Nov 06, 2018 1:18 pm

BigEd wrote:
Tue Nov 06, 2018 12:15 pm
Thanks! I was thinking of the earlier discussion where there were suggestions for moving the threshold - there's the 010 case and the 101 case.
Yes, so I guess that wouldn't work then!

I've just rewritten the calibration optimiation pass to make used of the data data gathered during the initial pass.

It seems to be working well on my system:

Code: Select all

INFO: Calibrating mode 7
INFO:                           A     B     C     D     E     F   total
INFO: value = 0: metrics =  17060     0  1615     0  5478     0   24153
INFO: value = 1: metrics =    258     0  5092     0 11401     0   16751
INFO: value = 2: metrics =      0     0     0     0 10639     0   10639
INFO: value = 3: metrics =      0     0  1209     0   793     0    2002
INFO: value = 4: metrics =      0     0  5214     0   498     0    5712
INFO: value = 5: metrics =    902     0   994     0  4544     0    6440
INFO: value = 6: metrics =    230 15058    11     0   366  5278   20943
INFO: value = 7: metrics =    745   244 12204     0  7736     0   20929
INFO: sp_offset = 3 3 3 3 3 3; half = 0; delay = 0
INFO: Optimizing calibration
INFO: sp_offset = 3 3 2 3 4 3; half = 0; delay = 0
INFO: Optimization complete, errors = 570
INFO: counter  0 = 3124
INFO: counter  1 = 3758
INFO: counter  2 = 3785
INFO: counter  3 = 3297
INFO: counter  4 = 3666
INFO: counter  5 = 4706
INFO: counter  6 = 4196
INFO: counter  7 = 1560
INFO: counter  8 = 1560
INFO: counter  9 = 5296
INFO: counter 10 = 5553
INFO: counter 11 = 3377
INFO: minima at index: 7
INFO: sp_offset = 3 3 2 3 4 3; half = 0; delay = 5
INFO: Calibration complete, errors = 505
That's now pushed as well.

Dave

User avatar
IanB
Posts: 268
Joined: Sun Sep 04, 2011 7:28 pm
Contact:

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

Post by IanB » Tue Nov 06, 2018 7:46 pm

hoglet wrote:
Sun Nov 04, 2018 7:34 pm
In the mean time, it would be good to see if you can do a manual calibration that gets rid of the flickering pixels.
I've not been able to get rid of the flickering pixels with a manual calibration. If I adjust the F offset with a setting of 4 I get flicker in some text and a setting of 5 I get flicker in different text. (Those two are the minimum, everything else is worse)

It looks like the clock on that M128 is simply too asymmetric for a 96Mhz sample rate to cope with. The narrowest high on the clock in my photo is around 30ns and the 96 Mhz clock is around 10ns per cycle but if it isn't phase locked it will have at least 10ns jitter so I suppose it's not surprising that it can't get a reliable sample at that point.

I'll look at changing the capacitor in the clock circuit to improve things.
Last edited by IanB on Wed Nov 07, 2018 4:24 am, edited 1 time in total.

User avatar
IanB
Posts: 268
Joined: Sun Sep 04, 2011 7:28 pm
Contact:

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

Post by IanB » Wed Nov 07, 2018 4:07 am

hoglet wrote:
Tue Nov 06, 2018 10:41 am
Ian, do you have a serial cable for your Pi?
It would be great if you could try the latest dev code and upload the metrics section of the log.
Here are the results from my problem Master 128:

Code: Select all

INFO: Calibrating mode 7
INFO:                            A      B      C      D      E      F   total
INFO: value = 0: metrics =     838   8513     28     40    879   5190   15488
INFO: value = 1: metrics =     117    433    225   4077    231    344    5427
INFO: value = 2: metrics =       0  16023      6     25     79   5005   21138
INFO: value = 3: metrics =       0    619      2      0      6   5033    5660
INFO: value = 4: metrics =       0     96      0      0      0    444     540
INFO: value = 5: metrics =       0      0      0      0      0    108     108
INFO: value = 6: metrics =     393      0  27455      0      0    553   28401
INFO: value = 7: metrics =     607    312    762   3629    584      0    5894
INFO: sp_offset = 5 5 5 5 5 5; half = 0; delay = 0
INFO: Optimizing calibration
INFO: sp_offset = 5 5 5 5 5 5; half = 0; delay = 0
INFO: Optimization complete, errors = 194
INFO: Aligning characters to word boundaries
INFO: counter  0 = 4678
INFO: counter  1 = 4604
INFO: counter  2 = 4996
INFO: counter  3 = 4997
INFO: counter  4 = 4581
INFO: counter  5 = 4665
INFO: counter  6 = 4813
INFO: counter  7 = 4656
INFO: counter  8 = 1680
INFO: counter  9 = 1680
INFO: counter 10 = 4716
INFO: counter 11 = 4858
INFO: minima at index: 8
INFO: Performing final test
INFO: sp_offset = 5 5 5 5 5 5; half = 0; delay = 4
INFO: Calibration complete, errors = 218
Although it can't calibrate this machine, the calibration results are faster and appear to be more repeatable than previously and it does find the single digit change required to correctly sample the Quest Paint full height cursor on another M128 that I mentioned a while ago.
Last edited by IanB on Wed Nov 07, 2018 4:23 am, edited 1 time in total.

User avatar
hoglet
Posts: 7596
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 Nov 07, 2018 8:17 am

IanB wrote:
Wed Nov 07, 2018 4:07 am
Here are the results from my problem Master 128:
Interesting. What does the picture look like if you try:
- A=5 B=5 C=5 D=5 E=5 F=7, or
- A=4 B=5 C=4 D=5 E=5 F=7

It looks like nudging F to 7 would give a stable picture but it may end up on the wrong pixel so look jagged/distorted.

I would suggest reducing the value of C30 (currently 100pF), maybe even remove it. If you loose the picture completely, you've reduced it too far.

Dave

User avatar
IanB
Posts: 268
Joined: Sun Sep 04, 2011 7:28 pm
Contact:

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

Post by IanB » Wed Nov 07, 2018 1:44 pm

hoglet wrote:
Wed Nov 07, 2018 8:17 am
Interesting. What does the picture look like if you try:
- A=5 B=5 C=5 D=5 E=5 F=7, or
- A=4 B=5 C=4 D=5 E=5 F=7
It looks like nudging F to 7 would give a stable picture but it may end up on the wrong pixel so look jagged/distorted.
I've already tried that but it sampled on the wrong pixel.
Last edited by IanB on Wed Nov 07, 2018 1:44 pm, edited 1 time in total.

User avatar
hoglet
Posts: 7596
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 Nov 07, 2018 1:56 pm

IanB wrote:
Wed Nov 07, 2018 1:44 pm
I've already tried that but it sampled on the wrong pixel.
OK, thanks.

I just checked my Master and the F offset is the one that controls the single pixel in the corner of the K, which is the worst case.

Dave

User avatar
hoglet
Posts: 7596
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 » Sat Nov 10, 2018 4:35 pm

IanB wrote:
Tue Nov 06, 2018 7:46 pm
I'll look at changing the capacitor in the clock circuit to improve things.
Any luck with capacitor tweaking?

I'd like to do a proper release shortly that includes all of the work in the dev branch.

You said earlier that the odd-even deinterlacing algorithm needs word-aligned mode 7 characters, which is only possible with the variable delay in CPLD v2.x. So, we need to fall back to the old de-interlacing algorithm for CPLD v1.x.

The way I'd like to do this is to have the assembly code support both algorithms, and then have the C code worry about the CPLD version detection, and removing incompatible items from the menus. i.e. we would need to add another R3 bit to select between the OLD_DEINT and NEW_DEINT.

I've had a stab at this, and the changes to the assembly code ended up pretty minor:
https://github.com/hoglet67/RGBtoHDMI/c ... 86467fe2b9

If you have a moment Ian, could you check that what I've done makes sense?

Also, I think we are pretty close to the point of pipeline stalls causing visible jitter. So it might also be worth pausing and seeing of collectively we can shave any cycles off the the code. Dominic's quite good at this!

Dave
Last edited by hoglet on Sat Nov 10, 2018 4:37 pm, edited 1 time in total.

User avatar
IanB
Posts: 268
Joined: Sun Sep 04, 2011 7:28 pm
Contact:

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

Post by IanB » Sun Nov 11, 2018 6:25 am

hoglet wrote:
Sat Nov 10, 2018 4:35 pm
Any luck with capacitor tweaking?
Yes I reduced C30 from 100pF it to 33pF and it looks a lot better:

newclock.jpg
I suspect that C23, C24 and C30 would all have to be tweaked to get it fully symmetrical

hoglet wrote:
Sat Nov 10, 2018 4:35 pm
You said earlier that the odd-even deinterlacing algorithm needs word-aligned mode 7 characters, which is only possible with the variable delay in CPLD v2.x. So, we need to fall back to the old de-interlacing algorithm for CPLD v1.x.
If you have a moment Ian, could you check that what I've done makes sense?
I'll take a look at it. I'd already implemented something similar myself but hadn't tested it.
hoglet wrote:
Sat Nov 10, 2018 4:35 pm
I'd like to do a proper release shortly that includes all of the work in the dev branch.
Have you considered my suggestion of moving the start point of PSYNC to much earlier and ignoring the first samples to allow for a common CPLD with other machines. As there are other changes in this CPLD, you could use the same bit in R3 which changes the deinterlace algorithm to enable the sample ignore code.

I've done a test with my UK101 to see how viable using it would be and it looks good so far, I only had to disable mode 7 detection as it was mistaking the UK101 sync pattern for mode 7:

uk101.jpg
The only other change needed is to increase the width of the frame buffer to 800 pixels so it doesn't crop characters and after that it looks like it will just work right away although it might have to be a custom build rather than incorporated into the main release. I'm going to try it with my Nascom 2 as well at some point.
In theory it could be adapted to a lot of other early monochrome computers like the TRS80 and Apple ][ and maybe IBM CGA.

The minimum required would be to move the start of PSYNC for modes0-6 as early as possible after HSYNC (maybe even before the start of active video so it could cope with slower clock speeds). For maximum flexibility, both mode 7 and mode0-6 start points could be moved and maybe add the pixel offset adjustment to modes 0-6 although that might not fit in the CPLD.

The CPLD needs some tweaking anyway as modes 0 -6 don't appear to be centred properly
hoglet wrote:
Sat Nov 10, 2018 4:35 pm
Also, I think we are pretty close to the point of pipeline stalls causing visible jitter. So it might also be worth pausing and seeing of collectively we can shave any cycles off the the code. Dominic's quite good at this!
I'm currently looking at another change to the algorithm that might yield better results with the text but it requires some radical changes to the code so you might want to wait until I've investigated that.
Last edited by IanB on Sun Nov 11, 2018 6:39 am, edited 3 times in total.

User avatar
hoglet
Posts: 7596
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 Nov 11, 2018 10:14 am

IanB wrote:
Sun Nov 11, 2018 6:25 am
Have you considered my suggestion of moving the start point of PSYNC to much earlier and ignoring the first samples to allow for a common CPLD with other machines. As there are other changes in this CPLD, you could use the same bit in R3 which changes the deinterlace algorithm to enable the sample ignore code.
I haven't really applied myself to this yet, but it should be do-able. I'll have a fiddle over the next few days.
IanB wrote:
Sun Nov 11, 2018 6:25 am
I've done a test with my UK101 to see how viable using it would be and it looks good so far, I only had to disable mode 7 detection as it was mistaking the UK101 sync pattern for mode 7.
This is great. Really great!

It makes me want to have a try with my Atom, and also maybe my Superboard II.
IanB wrote:
Sun Nov 11, 2018 6:25 am
The only other change needed is to increase the width of the frame buffer to 800 pixels so it doesn't crop characters and after that it looks like it will just work right away although it might have to be a custom build rather than incorporated into the main release.
My understanding of the UK101 is the pixel clock is 8MHz, and the display is 48x16 characters, which is 384x128 pixels.

So I see why you needed a wider frame buffer.

Again, it should be possible to make that a configurable parameter.
IanB wrote:
Sun Nov 11, 2018 6:25 am
The minimum required would be to move the start of PSYNC for modes0-6 as early as possible after HSYNC (maybe even before the start of active video so it could cope with slower clock speeds). For maximum flexibility, both mode 7 and mode0-6 start points could be moved and maybe add the pixel offset adjustment to modes 0-6 although that might not fit in the CPLD.
There need to be some small amount of delay between the end of HSYNC and the start of the PSYNC clock, otherwise the software risks missing PSYNC edges. At the moment the CPLD is waiting ~15us from the start of HSYNC, which is nominally 11us from the end of HSYNC. This could probably be reduced by 10us (which might actually save a register or two in the CPLD).

Rather than hard coding the number of PSYNC clocks to skip, I'll try to bring it out as a configurable parameter with sensible Beeb specific defaults for CPLDv1 and CPLDv2.

It should be possible to make the delay adjustment apply to modes 0-6 as well.
IanB wrote:
Sun Nov 11, 2018 6:25 am
The CPLD needs some tweaking anyway as modes 0 -6 don't appear to be centred properly
OK, I'll look into that.
IanB wrote:
Sun Nov 11, 2018 6:25 am
I'm currently looking at another change to the algorithm that might yield better results with the text but it requires some radical changes to the code so you might want to wait until I've investigated that.
That's fine, I'll hold off.

The one thing I was going to do was to make use of the link register (lr/r13) which is currently unused so that the 0x77777777 constant doesn't need to keep being reloaded. The following sequence I think actually takes 5 clock cycles, because of stalls when the shifter is used.

Code: Select all

        mov    r8, #0x77            // mask to extract OSD
        orr    r8, r8, r8, lsl#8
        orr    r8, r8, r8, lsl#16
You can save a clock cycle with:

Code: Select all

        mov    r8, #0x77            // mask to extract OSD
        orr    r8, r8, #0x7700
                                            // free instruction slot due to pipeline stall
        orr    r8, r8, r8, lsl#16
But do bear in mind as you re-work things that lr is spare.

Dave

dp11
Posts: 841
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

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

Post by dp11 » Sun Nov 11, 2018 10:57 am

The one thing I was going to do was to make use of the link register (lr/r13) which is currently unused so that the 0x77777777 constant doesn't need to keep being reloaded. The following sequence I think actually takes 5 clock cycles, because of stalls when the shifter is used.
CODE: SELECT ALL

mov r8, #0x77 // mask to extract OSD
orr r8, r8, r8, lsl#8
orr r8, r8, r8, lsl#16
You can save a clock cycle with:
CODE: SELECT ALL

mov r8, #0x77 // mask to extract OSD
orr r8, r8, #0x7700
// free instruction slot due to pipeline stall
orr r8, r8, r8, lsl#16
Yep 5 cycles on ARM v6 on the first example and four on the second

Below is even better at 3 cycles and a two free instruction slots available if required.

Code: Select all

	LDR r8=0x77777777
	// free instruction slot due to pipeline stall
	// free instruction slot due to pipeline stall

User avatar
IanB
Posts: 268
Joined: Sun Sep 04, 2011 7:28 pm
Contact:

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

Post by IanB » Sun Nov 11, 2018 3:20 pm

hoglet wrote:
Sun Nov 11, 2018 10:14 am
It makes me want to have a try with my Atom, and also maybe my Superboard II.
I have an Atom too. The main issue with the Atom is that the video signals are not digital so there would have to be some signal conversion first like the Acorn MKII colour card. It looks like you've already done some work on this years ago:
viewtopic.php?t=5994
At the moment I'm taking the TTL sync and video directly out of the UK101 but it should be possible to implement similar signal conditioning on a monochrome composite video signal using simpler circuitry to generate equivalent TTL level sync and video signals.
hoglet wrote:
Sun Nov 11, 2018 10:14 am
My understanding of the UK101 is the pixel clock is 8MHz, and the display is 48x16 characters, which is 384x128 pixels.
So I see why you needed a wider frame buffer.
It's even worse than that as the display is actually 64x16 and the video system outputs characters for the entire line including sync and blanking periods presumably to keep the design simple, so it relies on the software not writing anything other than a space to those areas. Different system monitors (MONUK02, CEGMON, WEMON) also start the displayed line on a different character position so that the display is effectively shifted left or right by a character which is why I think 800 samples is needed to capture all cases. This also still fits nicely into 1920x1080, 1920x1200, 1600x1200 1024x600 & 800x600. In fact the only resolutions it would really cause an issue with are 720p and 720i.
hoglet wrote:
Sun Nov 11, 2018 10:14 am
Rather than hard coding the number of PSYNC clocks to skip, I'll try to bring it out as a configurable parameter with sensible Beeb specific defaults for CPLDv1 and CPLDv2.
That would be even better. It's effectively an extension of the current 4 bit pixel offset (we only really need 3 bits for the pixel value as any higher bits would be part of the new word offset so that might free up a register)
Last edited by IanB on Sun Nov 11, 2018 9:08 pm, edited 2 times in total.

User avatar
IanB
Posts: 268
Joined: Sun Sep 04, 2011 7:28 pm
Contact:

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

Post by IanB » Sun Nov 11, 2018 8:55 pm

Looking at possible alternative systems that could be supported, most use a multiple of the NTSC colour crystal frequency as their clock (like the Atom) so pixel clocks would be 3.579545, 7.15909, 14.31818 and the sample clock on the PI would have to be 85.90908 Mhz. Would the CPLD require any other changes to work with such a sample frequency? (ZX80 /81 is 3.5Mhz so sample clock of 84Mhz)
Looking at your Atom work linked above, you would need 4 bits rather than 3 to capture all the colours, similarly the IBM PC's CGA output requires 4 bits (RGBI) so it looks like an additional bit is required for full operation, is it possible to add an extra bit to the current CPLD on a spare pin (maybe if the MUX input was sacrificed)? The existing video memory would remain the same as it is already 4 bits although the OSD would have to be tweaked as it would no longer have a private palette.

BTW I saw this recently:
https://www.youtube.com/watch?v=9SII7ujB3FY
Which is a converter for PC style resolutions like MDA and CGA but it has a VGA output, not HDMI. My latest PC monitor didn't even come with a VGA input so I guess even that's disappearing as well!
Last edited by IanB on Sun Nov 11, 2018 9:04 pm, edited 2 times in total.

User avatar
hoglet
Posts: 7596
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 Nov 11, 2018 9:51 pm

Ian,

Thanks for that info about clocking. You are right, that also needs to be configurable.

I've just done a big push to the dev branch with hopefully enough to work with your UK101 out of the box:
https://github.com/hoglet67/RGBtoHDMI/commits/dev

Here's a summary...

The CPLD now starts sampling the line 8us earlier than before. Hopefully that should be sufficient.

In the Pi Firmware I've added:
- an Expert option that exposes some additional parameters (below) that should allow non-Acorn machines to be supported
- a Mode 7 Disable option that disables special treatment of Mode 7

The new "expert" parameters are added as part of the mode configuration (i.e. middle button).

These ones allow the "capture window" within the frame to be specified:
- "H Offset" (in 4 pixel units, i.e. half psync cycles)
- "H Width" (in 8 pixel units, i.e. full psync cycles)
- "V Offset" (in field scan-lines)
- "V Height" (in field scan-lines)
- "Delay" (in pixels)

And these ones allow the Pi's framebuffer size to be specified:
- "FB Width" (in pixels)
- "FB Height" (in pixels)

For a UK101 you should be able to add the following to the cmdline.txt file:

Code: Select all

sampling06=0,4,4,4,4,4,4,0,16,21,96,270,800,540,0 info=1 palette=0 deinterlace=0 scanlines=0 mux=0 elk=0 vsync=0 pllh=0 nbuffers=2 debug=1 expert=1 m7disable=1
That would use a 800x540 size framebuffer.

All of these values can be changed dynamically through the UI or (more preferably) set in the cmdline.txt file.

There are more comments in the sample cmdline.txt file.

More work is still needed, for example to be able to specify:
- the CPLD sample clock frequency (currently 96MHz)
- the expected number duration of a field (currently 20,000us or 19,968us)
- improve the cmdline.txt file format, it's currently a huge hack

Plus I'm sure this will have introduced a lot of bugs.

Dave
Last edited by hoglet on Sun Nov 11, 2018 9:55 pm, edited 4 times in total.

User avatar
IanB
Posts: 268
Joined: Sun Sep 04, 2011 7:28 pm
Contact:

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

Post by IanB » Sun Nov 11, 2018 10:58 pm

hoglet wrote:
Sun Nov 11, 2018 9:51 pm
I've just done a big push to the dev branch with hopefully enough to work with your UK101 out of the box:
Thanks, I'll give it a try.

It's a good thing I ordered some more boards: :D

boards.jpg

User avatar
IanB
Posts: 268
Joined: Sun Sep 04, 2011 7:28 pm
Contact:

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

Post by IanB » Mon Nov 12, 2018 1:37 am

hoglet wrote:
Sun Nov 11, 2018 9:51 pm
Plus I'm sure this will have introduced a lot of bugs.
Only a couple of things I noticed so far:

Mode 7 is misaligned or maybe my simple modulo 3 code has been broken and needs replacing with something more generic. (If I can get the new version to work that code isn't required anyway).

The mode 7 disable isn't working as the bit that needs to be disabled is this (starts around line 778):

Code: Select all

        // Check for mode change:
        // Odd: Mode 0..6 should be 21us, Mode 7 should be 23us
        // Even: Mode 0..6 should be 53us, Mode 7 should be 55us
        //
        // The above changes with smooth horizontal scrolling
        // - with R3= 6: 20.0us/52.0us
        // - with R3= 7: 20.5us/52.5us
        // - with R3= 8: 21.0us/53.0us <<< "Normal" case
        // - with R3= 9: 21.5us/53.5us
        // - with R3=10: 22.0us/54.0us
        //
        // Hence we use thresholds of 22.5us and 54.5us
        tst    r3, #BIT_FIELD_TYPE
        ldreq  r5, =22500     // Use 22.5us threshold in odd field
        ldrne  r5, =54500     // Use 54.5us threshold in even field
        cmp    r6, r5
        movlt  r0, #0         // Modes 0-6
        movge  r0, #1         // Mode 7
        tst    r3, #BIT_PROBE
        bne    exit
        tst    r3, #BIT_CALIBRATE
        bne    skip_switch_test
It causes jumping and loss of picture on the UK101

Other than that it seems to work just fine!
The command line I'm using is:

Code: Select all

sampling06=0,4,4,4,4,4,4,0,23,26,99,270,800,540,0 info=1 palette=0 deinterlace=0 scanlines=0 mux=0 elk=0 vsync=0 pllh=0 nbuffers=2 debug=1 expert=1 m7disable=1
Changes:
H Offset: = 23
V Offset: = 26
H Width: = 99
The H Width should really be 100 to capture all 800 pixels but it is limited to 99 maximum at the moment.

This is MONUK02 with it's screen output centred:
monuk02.jpg
My UK101 has never looked so good!

This is WEMON with the same settings:
wemon.jpg

As you can see it's start of display is pushed 2 chars to the left but that's a software choice by WEMON
If the Hwidth could be increased to 100 it would be possible to get both captured with one setting by adjusting the H offset by 1 char so WEMON would have two blank chars on the right and MONUK02 would have two blank chars on the left.
It may be better to patch WEMON to match MONUK02. I don't use it much anyway as it broke compatibility with just about everything.

EDIT: After the machine had been on for a while I lost all output even though sync and video were still present. After the machine cooled down again it started working. I think the likely cause is that the H and V sync pulses are timed by RC monostables so will drift and any accurate sync pulse timing code is going to produce unpredictable results. Maybe the disable mode 7 option needs to also disable any accurate sync analysis as well (like the horizontal scrolling code) and revert to simplistic discrimination between H and V sync bearing in mind that Hsyncs could be way off 4.7uS and Vsyncs might be low for the entire vsync duration and contain no inverted H syncs (the UK101 does it like that).
Last edited by IanB on Mon Nov 12, 2018 1:50 pm, edited 3 times in total.

User avatar
hoglet
Posts: 7596
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 Nov 12, 2018 7:41 am

IanB wrote:
Mon Nov 12, 2018 1:37 am
Mode 7 is misaligned or maybe my simple modulo 3 code has been broken and needs replacing with something more generic. (If I can get the new version to work that code isn't required anyway).
Yes, I'm aware of this. It needs to take account of H_OFFSET, which shifts everything in units of 4 pixels.

On reflection, I think the previous version was only working by luck. It adjusts the delay to gain character alignment, but as far as I understand, your deinterlacing requires more than this. It requires modulo 3 alignment - i.e. column 0 of the mode 7 display should be start in word N where N % 3 == 0. If it actually does, that's more by luck than anything else.
IanB wrote:
Mon Nov 12, 2018 1:37 am
The mode 7 disable isn't working as the bit that needs to be disabled is this (starts around line 778):
That's interesting, I thought I had disabled it just with BIT_MODE_DETECT below this point:

Code: Select all

       tst    r3, #BIT_MODE7
        moveq  r5, #0         // Modes 0-6
        movne  r5, #1         // Mode 7
        tst    r3, #BIT_MODE_DETECT // Have we been told to exit on mode change
        cmpne  r5, r0         // Check if we have changed mode
        bne    exit           // If so, then bail, as the frame buffer needs to be resized
(BIT_MODE_DETECT is set to zero when m7detect=1)
IanB wrote:
Mon Nov 12, 2018 1:37 am
Other than that it seems to work just fine!
Cool. I must dig out my Superboard II and give it a try.
IanB wrote:
Mon Nov 12, 2018 1:37 am
The H Width should really be 100 to capture all 800 pixels but it is limited to 99 maximum at the moment.
I'll increase the limits so that is within range.
IanB wrote:
Mon Nov 12, 2018 1:37 am
EDIT: After the machine had been on for a while I lost all output even though sync and video were still present. After the machine cooled down again it started working. I think the likely cause is that the H and V sync pulses are timed by RC monostables so will drift and any accurate sync pulse timing code is going to produce unpredictable results. Maybe the disable mode 7 option needs to also disable any accurate sync analysis as well (like the horizontal scrolling code) and revert to simplistic discrimination between H and V sync bearing in mind that Hsyncs could be way off 4.7uS and Vsyncs might be low for the entire vsync duration and contain no inverted H syncs (the UK101 does it like that).
I'll have a think about what might be causing this. Complete loss of picture is a bit unexpected. Can you see in the log at what point it is hanging?

Dave
Last edited by hoglet on Mon Nov 12, 2018 7:42 am, edited 1 time in total.

User avatar
IanB
Posts: 268
Joined: Sun Sep 04, 2011 7:28 pm
Contact:

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

Post by IanB » Mon Nov 12, 2018 1:21 pm

hoglet wrote:
Mon Nov 12, 2018 7:41 am
I'll have a think about what might be causing this. Complete loss of picture is a bit unexpected. Can you see in the log at what point it is hanging?
Some further info:

I got it to fail again and noticed a couple of things:
I started the UK101 from cold, calibrated it and let it warm up. It carried on displaying active video but after it had warmed up, I tried a recalibration and it went through the process then lost the video output. I then tried pressing reset or power cycling the Pi and it had no effect and remained with no video output. This means that after the timings have drifted there is a hangup during initialisation but if the drift occurs after initialisaion it will carry on capturing and displaying video until the next reinit or reset. In failure mode, it still printed all the status info on the debug port after a reset.

Also when calibrating, I noticed a vertical band of noisy chars that moved across the screen as the sample point was changed (although it did find a clean point). This was likely due to a large difference between the UK101's pixel clock and the Pi's sample frequency. The status info showed >700ppm error on the field frequency. That error is effectively the difference between the UK101's pixel clock and the Pi's sample frequency so maybe that info should be used to adjust the Pi's sample frequency from the nominal 96Mhz as well as the HDMI clock as that might increase the window of good sample points and may have helped with my Master 128 clock issue as well. This would make the Pi's sample clock frequency locked to the computer's pixel clock although it wouldn't be phase locked so would still have 1 cycle of jitter.

User avatar
hoglet
Posts: 7596
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 Nov 12, 2018 2:01 pm

IanB wrote:
Mon Nov 12, 2018 1:21 pm
I got it to fail again and noticed a couple of things:
I started the UK101 from cold, calibrated it and let it warm up. It carried on displaying active video but after it had warmed up, I tried a recalibration and it went through the process then lost the video output. I then tried pressing reset or power cycling the Pi and it had no effect and remained with no video output. This means that after the timings have drifted there is a hangup during initialisation but if the drift occurs after initialisaion it will carry on capturing and displaying video until the next reinit or reset. In failure mode, it still printed all the status info on the debug port after a reset.
The most likely place it is hanging is in wait_for_vsync():

Code: Select all

        // Compare with 6us to descriminate short from long
        // - normal hsync pulses are 4us
        // - during vsync everything is either inverted, or clamped to zero
        // - this results in hsync pulses between 9us and 128us
        cmp    r5, #6144
        blt    seen_short
This uses the value of 6.144us to discriminate normal HSYNC pulses from longer pulses that occur during VSYNC.

Now, if the normal HSYNC pulse exceeds 6.144us then I think the code will loop indefinitely.

Could you try to accurately measure the HSYNC pulse width once everything has warned up, and the problem has happened?

(We have a bit of room to increase this threshold before it would impact operation on the Beeb)

Edit: Looking at the schematic, the pulse is generated by a 74123 monostable with R=15K and C=1000pF. The data sheet says this will give a pulse of about 5us, but I guess it's possible things are way off.

Edit: Edit: You could always try increasing the 6144 to say 7680

Dave
Last edited by hoglet on Mon Nov 12, 2018 3:26 pm, edited 5 times in total.

User avatar
hoglet
Posts: 7596
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 Nov 12, 2018 2:27 pm

IanB wrote:
Mon Nov 12, 2018 1:21 pm
Also when calibrating, I noticed a vertical band of noisy chars that moved across the screen as the sample point was changed (although it did find a clean point). This was likely due to a large difference between the UK101's pixel clock and the Pi's sample frequency. The status info showed >700ppm error on the field frequency. That error is effectively the difference between the UK101's pixel clock and the Pi's sample frequency so maybe that info should be used to adjust the Pi's sample frequency from the nominal 96Mhz as well as the HDMI clock as that might increase the window of good sample points and may have helped with my Master 128 clock issue as well. This would make the Pi's sample clock frequency locked to the computer's pixel clock although it wouldn't be phase locked so would still have 1 cycle of jitter.
Can you post a complete log of the Pi starting up?

The first thing it does it to measure the vsync frequency and whether the signal is interlaced or not:
- If the signal is interlaced, it assumes the frame duration is 625 lines x 64 us = 40,000 us.
- If the signal is non-interlaced, it assumes the frame duration is 624 lines x 64 us = 39,936 us.

It then uses one or other of these to measure the clock difference between the Pi and the source, and then sets the 96MHz sampling clock taking account of this error. So it should already be accurately match the sources clock, and the sampling point should not drift noticeably across the screen. So something is goinf wrong.

If it's incorrectly detecting the video signal as interlaced, then that might explain this.

Anyway, the log should be useful. It's this section specifically:

Code: Select all

INFO:      Nominal clock = 384000000 Hz
INFO: Nominal frame time = 40000000 ns (interlaced)
INFO:  Actual frame time = 40017401 ns
INFO:   Frame time error = 435 PPM
INFO:      Optimal clock = 383833023 Hz
INFO:        Final clock = 383833023 Hz
Edit: Again looking at the schematic, the signal it generates is 624 line non-interlaced (i.e. two identical 312 line fields). That should be detected correctly without any issues.

Dave
Last edited by hoglet on Mon Nov 12, 2018 3:23 pm, edited 6 times in total.

User avatar
IanB
Posts: 268
Joined: Sun Sep 04, 2011 7:28 pm
Contact:

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

Post by IanB » Mon Nov 12, 2018 5:40 pm

hoglet wrote:
Mon Nov 12, 2018 2:27 pm
Can you post a complete log of the Pi starting up?

Code: Select all

INFO: Clock out of range 380MHz-388MHz, defaulting to 384MHz
INFO:        Final clock = 384000000 Hz
INFO: PLLH: PDIV=1 NDIV=68 FRAC=513365 AUX=256 RCAL=256 PIX=1 STS=527361
INFO: Original PLLH: 1314.999994 MHz
INFO: CPLD  Design: Normal
INFO: CPLD Version: 2.1
INFO: config.txt:        info = 1
INFO: config.txt:     palette = 0
INFO: config.txt: deinterlace = 0
INFO: config.txt:   scanlines = 0
INFO: config.txt:         mux = 1
INFO: config.txt:         elk = 0
INFO:   Target PLLH: 1314.999994 MHz
INFO: Old fract = 513365 (when read back)
INFO: New fract = 513365
INFO: New fract = 513365 (when read back)
INFO: PLLH: PDIV=1 NDIV=68 FRAC=513365 AUX=256 RCAL=256 PIX=1 STS=527361
INFO:   Actual PLLH: 1314.999994 MHz
INFO: config.txt:        pllh = 0
INFO: config.txt:    nbuffers = 2
INFO: config.txt:       vsync = 0
INFO: config.txt:       debug = 1
INFO: config.txt:      expert = 1
INFO: config.txt:   m7disable = 1
INFO: config.txt:  sampling06 = 0,4,4,4,4,4,4,0,23,26,99,270,800,540,0
INFO: cpld: All offsets = 0
INFO: cpld: A offset = 4
INFO: cpld: B offset = 4
INFO: cpld: C offset = 4
INFO: cpld: D offset = 4
INFO: cpld: E offset = 4
INFO: cpld: F offset = 4
INFO: cpld: Half = 0
INFO: cpld: H offset = 23
INFO: cpld: V offset = 26
INFO: cpld: H width = 99
INFO: cpld: V height = 270
INFO: cpld: FB width = 800
INFO: cpld: FB height = 540
INFO: cpld: Delay = 0
INFO: Framebuf struct address: 0x8010000
INFO: Initialised Framebuffer: 800x540
INFO: Pitch: 400 bytes
INFO: Framebuffer address: DF929000
hoglet wrote:
Mon Nov 12, 2018 2:27 pm
If it's incorrectly detecting the video signal as interlaced, then that might explain this.
The hsyncs are 5us, hot or cold but the position of the Vsync seems to change when the system has warmed up:
Vsync when cold:
goodvsync.jpg

Vsync when warmed up:
badvsync.jpg
Closeup of left and right of bad vsync:
badvsync_left.jpg
badvsync_right.jpg

User avatar
hoglet
Posts: 7596
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 Nov 12, 2018 5:43 pm

IanB wrote:
Mon Nov 12, 2018 5:40 pm

Code: Select all

INFO: Clock out of range 380MHz-388MHz, defaulting to 384MHz
INFO:        Final clock = 384000000 Hz
I think you have truncated the log - there should be some lines prior to the clock out of range error. These would be very useful!

The first line should be:

Code: Select all

INFO: RGB to HDMI booted
Last edited by hoglet on Mon Nov 12, 2018 5:48 pm, edited 2 times in total.

User avatar
hoglet
Posts: 7596
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 Nov 12, 2018 5:45 pm

If there isn't anything before that, could you try a debug build?

Code: Select all

./clobber.sh
./configure_rpi.sh -DDEBUG=1
make -Bj
Last edited by hoglet on Mon Nov 12, 2018 5:46 pm, edited 1 time in total.

User avatar
IanB
Posts: 268
Joined: Sun Sep 04, 2011 7:28 pm
Contact:

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

Post by IanB » Mon Nov 12, 2018 6:15 pm

hoglet wrote:
Mon Nov 12, 2018 5:43 pm
I think you have truncated the log - there should be some lines prior to the clock out of range error. These would be very useful!
Sorry, I didn't select all when doing a copy/paste:

Code: Select all

INFO: RGB to HDMI booted
INFO:      Nominal clock = 384000000 Hz
INFO: Nominal frame time = 39936000 ns (non-interlaced)
INFO:  Actual frame time = 40993458 ns
INFO:   Frame time error = 26478 PPM
INFO:      Optimal clock = 374094422 Hz
INFO: Clock out of range 380MHz-388MHz, defaulting to 384MHz
INFO:        Final clock = 384000000 Hz
INFO: PLLH: PDIV=1 NDIV=68 FRAC=513365 AUX=256 RCAL=256 PIX=1 STS=527361
INFO: Original PLLH: 1314.999994 MHz
INFO: CPLD  Design: Normal
INFO: CPLD Version: 2.1
INFO: config.txt:        info = 1
INFO: config.txt:     palette = 0
INFO: config.txt: deinterlace = 0
INFO: config.txt:   scanlines = 0
INFO: config.txt:         mux = 1
INFO: config.txt:         elk = 0
INFO:   Target PLLH: 1314.999994 MHz
INFO: Old fract = 513365 (when read back)
INFO: New fract = 513365
INFO: New fract = 513365 (when read back)
INFO: PLLH: PDIV=1 NDIV=68 FRAC=513365 AUX=256 RCAL=256 PIX=1 STS=527361
INFO:   Actual PLLH: 1314.999994 MHz
INFO: config.txt:        pllh = 0
INFO: config.txt:    nbuffers = 2
INFO: config.txt:       vsync = 0
INFO: config.txt:       debug = 1
INFO: config.txt:      expert = 1
INFO: config.txt:   m7disable = 1
INFO: config.txt:  sampling06 = 0,4,4,4,4,4,4,0,23,26,99,270,800,540,0
INFO: cpld: All offsets = 0
INFO: cpld: A offset = 4
INFO: cpld: B offset = 4
INFO: cpld: C offset = 4
INFO: cpld: D offset = 4
INFO: cpld: E offset = 4
INFO: cpld: F offset = 4
INFO: cpld: Half = 0
INFO: cpld: H offset = 23
INFO: cpld: V offset = 26
INFO: cpld: H width = 99
INFO: cpld: V height = 270
INFO: cpld: FB width = 800
INFO: cpld: FB height = 540
INFO: cpld: Delay = 0
INFO: Framebuf struct address: 0x8010000
INFO: Initialised Framebuffer: 800x540
INFO: Pitch: 400 bytes
INFO: Framebuffer address: DF929000
I measured the hsyncs with a frequency meter at 15.6124Khz
Dividing the reciprocal of that into the actual frame time above yields 639.9889608
Looks like it's sending out 320 lines per field
Last edited by IanB on Mon Nov 12, 2018 6:23 pm, edited 3 times in total.

User avatar
hoglet
Posts: 7596
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 Nov 12, 2018 6:25 pm

This is what's confusing it:

Code: Select all

Actual frame time = 40993458 ns
Yes, dividing that by 64us gives ~640 lines, which as you said is 320 lines per field.

According to the schematic, it should send 312 lines per field.

Can you try to measure the time between two VSYNC pulses on a scope, just to confirm?

Dave
Last edited by hoglet on Mon Nov 12, 2018 6:34 pm, edited 2 times in total.

User avatar
hoglet
Posts: 7596
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 Nov 12, 2018 6:32 pm

I think you might have a fault on your UK101, or at least a difference from the published schematic.

This is from page 18 of the schematic:
uk101a.PNG
uk101a.PNG (24.27 KiB) Viewed 68 times
It's part of a 4-chip counter that generates all the video timing.

The extra 8 lines would be explained if IC61 pin 4 was connected to 0V rather than 5V.

Can you check the voltages on pins 3,4,5,6?

Or possibly IC61 is faulty and not correctly loading the value on it's parallel inputs.

Dave
Last edited by hoglet on Mon Nov 12, 2018 6:35 pm, edited 2 times in total.

User avatar
IanB
Posts: 268
Joined: Sun Sep 04, 2011 7:28 pm
Contact:

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

Post by IanB » Mon Nov 12, 2018 6:48 pm

hoglet wrote:
Mon Nov 12, 2018 6:32 pm
Can you check the voltages on pins 3,4,5,6?
The voltages on 3,4,5,6 were all correct and my scope measured the vsync period as 19.95ms which implies 312 lines.
Maybe the non standard VSYNC pulse is affecting the frame time measurement.

User avatar
hoglet
Posts: 7596
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 Nov 12, 2018 6:58 pm

IanB wrote:
Mon Nov 12, 2018 6:48 pm
The voltages on 3,4,5,6 were all correct and my scope measured the vsync period as 19.95ms which implies 312 lines.
Maybe the non standard VSYNC pulse is affecting the frame time measurement.
Gosh, that's slightly surprising.

Looking at the vsync scope plots you posted earlier, there's nothing there that should cause any problems. Even if the HSYNC pulse is close to VSYNC, it shouldn't really matter (unless there is literally < 100ns between them).

Can you hit reset on the Pi five times and capture that section from the log each time?

I want to see how consistent the actual clock measurement is.

Dave

Post Reply