RGB to HDMI using a Pi Zero and a small CPLD

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
IanB
Posts: 376
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

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

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

hoglet wrote:
Mon Oct 15, 2018 9:24 pm

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

The aim was not that this be perfect. Rather that when used with double/triple buffering the rate of buffer skipping would be once every few minutes or better.
OK It's probably a bit of confusion over how it was meant to work.

In non-interlace, 623 was best and with interlace 624 was best with the bar moving very slowly.

I had assumed you were trying to keep a lock by effectively doing a software PLL continually varying the HDMI clock to keep the vsyncs aligned.
In theory that would stop tearing and might not require any buffering at all, eliminating the lag.

User avatar
hoglet
Posts: 8189
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 Oct 16, 2018 6:49 am

IanB wrote:
Mon Oct 15, 2018 9:48 pm
I had assumed you were trying to keep a lock by effectively doing a software PLL continually varying the HDMI clock to keep the vsyncs aligned.
In theory that would stop tearing and might not require any buffering at all, eliminating the lag.
Yes, this was a first step on the way to that goal, showing we can adjust the HDMI clock on the fly without loosing sync.

Dave

User avatar
IanB
Posts: 376
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 » Wed Oct 17, 2018 9:09 pm

hoglet wrote:
Tue Oct 16, 2018 6:49 am
Yes, this was a first step on the way to that goal, showing we can adjust the HDMI clock on the fly without loosing sync.
Sounds good.

Meanwhile I've made some changes to the mode 7 capture code that provide motion adaptive deinterlacing with minimal artefacts, just minor edge twitter around moving parts of the screen.
Since I last PM'ed you about this I have fixed the remaining issues and everything seems to be working great so please give it a try:

rgb_to_fb.zip
(5.17 KiB) Downloaded 4 times

Note I split up the mode 7 and mode0-6 code for clarity and this version currently breaks the OSD as you have to change the code to write the OSD into the comparison buffer instead of the display buffer.

Look for comments starting //*** where I have made changes

It would be useful to get some sort of mode 7 test code together that tested this thoroughly.
Last edited by IanB on Wed Oct 17, 2018 9:12 pm, edited 2 times in total.

User avatar
IanB
Posts: 376
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 Oct 18, 2018 2:03 am

Here is a slightly updated version:
rgb_to_fb_v2.zip
(5.42 KiB) Downloaded 5 times

This has some constants put in registers rather than recalculated for each pixel word. I don't know if it makes any significant difference to the timing but it can't hurt. Also the vsync red line should now work without affecting deinterlace.

The OSD still needs fixing but in it's current form it may never work properly with the deinterlace code as multiple bytes get overwritten without extracting the OSD bits from each of them and there isn't enough processor time to do that (I tried).
I think the best way to work around this is to disable the deinterlace code when the OSD is on, so to get it working the OSD needs to be written to the second buffer instead of the display buffer (that one immediately follows the display buffer) and a test needs to be added to skip over the deinterlace code when the OSD is on screen.
Last edited by IanB on Thu Oct 18, 2018 2:13 am, edited 2 times in total.

User avatar
hoglet
Posts: 8189
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 Oct 18, 2018 8:54 am

Hi Ian,
IanB wrote:
Thu Oct 18, 2018 2:03 am
Here is a slightly updated version.
This is looking very good, and is most definitely an improvement on no de-interlacing!

The only artefact I've noticed if you have a Basic program listing up and the screen scrolls just one line, everything "fizzes" for slightly longer than I would have expected. Have a look and see if this is expected. I don't personally have much experience with different de-interlacing algorithms.

I've also made two further changes:
- I've fixed the OSD issue by simply writing it to both buffers (that's how the code used to be at one point)
- I've also bypassed the de-interlacing during calibration, as it was causing lots of additional errors to be seen

Anyway, I've committed this to the dev branch (after changing tabs to spaces):
https://github.com/hoglet67/RGBtoHDMI/commits/dev

Oh, and the vsync marker is now grey - was that a deliberate change? Edit: No it isn't - I'd accidentally selected the MONO palette.

Attached is a build if anyone else wants to give this a try:
RGBtoHDMI_20181018_518c1ba.zip
(450.18 KiB) Downloaded 5 times
Dave
Last edited by hoglet on Thu Oct 18, 2018 8:56 am, edited 1 time in total.

User avatar
IanB
Posts: 376
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 Oct 18, 2018 10:46 am

hoglet wrote:
Thu Oct 18, 2018 8:54 am
The only artefact I've noticed if you have a Basic program listing up and the screen scrolls just one line, everything "fizzes" for slightly longer than I would have expected. Have a look and see if this is expected. I don't personally have much experience with different de-interlacing algorithms.
I had to extend the time it deinterlaces otherwise you still get combing artefacts, this may be due to the fact mode 7 isn't double buffered.
hoglet wrote:
Thu Oct 18, 2018 8:54 am
I've also made two further changes:
- I've fixed the OSD issue by simply writing it to both buffers (that's how the code used to be at one point)
- I've also bypassed the de-interlacing during calibration, as it was causing lots of additional errors to be seen
Deinterlacing needs to be bypassed when the OSD is on screen as well, try scrolling a mode 7 screen with the OSD on.

Also after the OSD is switched off or calibration has been run, the screen is left dimmed.

User avatar
BigEd
Posts: 2488
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 » Thu Oct 18, 2018 11:47 am

hoglet wrote:
Mon Oct 15, 2018 9:01 pm
I'll test this with BigEd's Master (hopefully Wednesday) and then merge this into Master.
Best-laid plans - I was rather unwell, so this event is punted, probably to next week...

User avatar
hoglet
Posts: 8189
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 Oct 18, 2018 12:18 pm

IanB wrote:
Thu Oct 18, 2018 10:46 am
Deinterlacing needs to be bypassed when the OSD is on screen as well, try scrolling a mode 7 screen with the OSD on.
Ah yes, indeed it does. I'll have another think. Probably your idea of just bypassing the deinterlacing might be better,
IanB wrote:
Thu Oct 18, 2018 10:46 am
Also after the OSD is switched off or calibration has been run, the screen is left dimmed.
I'm not currently seeing that. Can you give me the exact steps to reproduce?

Dave
Last edited by hoglet on Thu Oct 18, 2018 12:18 pm, edited 1 time in total.

User avatar
IanB
Posts: 376
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 Oct 18, 2018 1:27 pm

hoglet wrote:
Thu Oct 18, 2018 12:18 pm
I'm not currently seeing that. Can you give me the exact steps to reproduce?
Looks like it's a build problem, my version does this, your version posted above doesn't. (I deleted my source folder and pulled the dev branch from githib to ensure a clean build)
I'm building on Windows 10 linux subsystem using gcc version (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0

User avatar
hoglet
Posts: 8189
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 Oct 18, 2018 1:50 pm

IanB wrote:
Thu Oct 18, 2018 1:27 pm
Looks like it's a build problem, my version does this, your version posted above doesn't. (I deleted my source folder and pulled the dev branch from githib to ensure a clean build)
I'm building on Windows 10 linux subsystem using gcc version (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
I was using an older version of GCC:

Code: Select all

gcc version 6.3.1 20170620
So I just updated to:

Code: Select all

gcc version 7.3.1 20180622
That still doesn't have a problem.

Can you upload your build so I can try it?

What's the output of:

Code: Select all

arm-none-eabi-gcc -v
Dave

User avatar
IanB
Posts: 376
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 Oct 18, 2018 2:14 pm

hoglet wrote:
Thu Oct 18, 2018 1:50 pm
Can you upload your build so I can try it?
What's the output of:

Code: Select all

arm-none-eabi-gcc -v
The following zip contains my build plus my changed config & command files (so you can replicate my setup exactly) and a text file with the output of the above command.
I'm running it on a Pi zero, not a zero W, also I have the new cpld firmware
kernelrpi.zip
(30.3 KiB) Downloaded 5 times

User avatar
hoglet
Posts: 8189
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 Oct 18, 2018 4:24 pm

IanB wrote:
Thu Oct 18, 2018 2:14 pm
The following zip contains my build plus my changed config & command files (so you can replicate my setup exactly) and a text file with the output of the above command.
I'm running it on a Pi zero, not a zero W, also I have the new cpld firmware
It seems to be the same compiler version exactly as I'm using, but the kernelrpi.img file is different.

Can you add the ELF binary (rgb-to-hdmi in the src/scripts directory) to the ZIP file?

Then I can look at the generated code.

(I can replicate it just by dropping your kernelrpi.img onto my SD card)

Dave
Last edited by hoglet on Thu Oct 18, 2018 4:25 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8189
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 Oct 18, 2018 6:26 pm

Ian,

I've just pushed a small fix to the dev branch that disables de-interlacing when the OSD is active. That sorted out the corruption of the OSD when the screen changed underneath.

In spite of the implementation only being 10 instructions (all commented!), I'm struggling to fully understand the algorithm it implements.

Specifically, it's this bit I'm not really understanding:

Code: Select all

        addne  r8, r11, r2          //*** adjust pointer to next line in comparison buffer
        strne  r10, [r12,r8]        //*** if pixels different overwrite next line of comparison buffer (delays end of deinterlacing)
I've tried removing these two lines and this actually seemed to improve the result - the "fizzing" artefacts I noticed previously when slowly scrolling a basic listing were gone.

Dave
Last edited by hoglet on Thu Oct 18, 2018 6:32 pm, edited 2 times in total.

User avatar
IanB
Posts: 376
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 Oct 18, 2018 7:15 pm

hoglet wrote:
Thu Oct 18, 2018 6:26 pm
Specifically, it's this bit I'm not really understanding:

Code: Select all

        addne  r8, r11, r2          //*** adjust pointer to next line in comparison buffer
        strne  r10, [r12,r8]        //*** if pixels different overwrite next line of comparison buffer (delays end of deinterlacing)
I've tried removing these two lines and this actually seemed to improve the result - the "fizzing" artefacts I noticed previously when slowly scrolling a basic listing were gone.
If you remove those two lines, the deinterlacing still works and you get a reduced 'fizzing' period but you still get weaving artefacts phasing in and out for about 50% of the time.
The two lines deliberately corrupt the comparison field data for the two subsequent fields so that the deinterlacing algorithm runs for another frame to ensure all remaining weaving is removed and that extends the fizzing period. (Note technically there is a buffer overrun there as it writes one line beyond the buffer at the end but as the following data is an unused buffer it didn't matter)
I think if double buffering of mode 7 was implemented that remaining weaving would disappear (so you could leave those lines out permanently) but I'm not 100% sure.

here's the elf and binary again (different datestamp as I rebuilt it but not including the OSD fix above):
rgb_to_hdmi.zip
(59.98 KiB) Downloaded 4 times
Edit: Try running the mode 7 scramble ssd posted earlier in this thread
Last edited by IanB on Thu Oct 18, 2018 7:28 pm, edited 3 times in total.

User avatar
hoglet
Posts: 8189
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 Oct 18, 2018 8:04 pm

OK, I've understood now why my build was differing from yours, even though we were using the same compiler.

I hadn't re-run clobber.sh and configure_rpi.sh, so I think some of the GCC 6.x libraries were still being used.

Anyway, now the my kernel is identical to yours, palette bug and all, so I'll look into that tomorrow.

Dave
Last edited by hoglet on Thu Oct 18, 2018 8:04 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8189
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 Oct 18, 2018 9:32 pm

Hi Ian,

As a quick work-around to the palette issue, if you build with DEBUG=1 then it should disappear:

Code: Select all

./clobber.sh
./configure_rpi.sh -DDEBUG=1
make -B
I'll look into this properly over the next couple of days.

Dave

User avatar
IanB
Posts: 376
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 » Fri Oct 19, 2018 12:28 am

hoglet wrote:
Thu Oct 18, 2018 6:26 pm
I've tried removing these two lines and this actually seemed to improve the result - the "fizzing" artefacts I noticed previously when slowly scrolling a basic listing were gone.
If you prefer that form of deinterlacing then maybe it's worth adding a config and menu option to control the deinterlace. i.e.
0 = deinterlace off
1 = fast deinterlace (with some residual combing)
2 = slow deinterlace (with almost no combing)

If you look at the mode 7 scramble game, with option 1 the rocket has comb lines and with option 2 it only has one or two lines at the top.
Similarly in the Quest Paint mouse driven mode 7 menu the cursor has weave lines with option 1 but not with option 2.
Unfortunately Quest Paint is a PalRom so I can't post an image for you to test but I recall that another paint ROM "The Artist" has a mode 7 mouse menu so maybe you could try that one.
After thinking about it, I'm not sure double buffering will help that much, I think the residual combing is down to things like motion stopping half way through a frame or very brief motion. Double buffering might get rid of the tiny amount of remaining combing in option 2.

I tried a few other ideas but they didn't work as there isn't enough processing time to do anything else. Frankly I'm amazed it works as well as it does with only a handful of instructions.
Last edited by IanB on Fri Oct 19, 2018 2:13 am, edited 3 times in total.

User avatar
hoglet
Posts: 8189
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 Oct 19, 2018 6:48 am

IanB wrote:
Fri Oct 19, 2018 12:28 am
If you prefer that form of deinterlacing then maybe it's worth adding a config and menu option to control the deinterlace. i.e.
0 = deinterlace off
1 = fast deinterlace (with some residual combing)
2 = slow deinterlace (with almost no combing)
Already done and pushed!
https://github.com/hoglet67/RGBtoHDMI/c ... e72fc95d06

There is also now a deinterlace setting cmdline.txt.

I've also fixed the OSD/Palette bug.
IanB wrote:
Fri Oct 19, 2018 12:28 am
If you look at the mode 7 scramble game, with option 1 the rocket has comb lines and with option 2 it only has one or two lines at the top.
Similarly in the Quest Paint mouse driven mode 7 menu the cursor has weave lines with option 1 but not with option 2.
Unfortunately Quest Paint is a PalRom so I can't post an image for you to test but I recall that another paint ROM "The Artist" has a mode 7 mouse menu so maybe you could try that one.
I'll take a look at this. I have it somewhere on my SD Card.
IanB wrote:
Fri Oct 19, 2018 12:28 am
After thinking about it, I'm not sure double buffering will help that much, I think the residual combing is down to things like motion stopping half way through a frame or very brief motion. Double buffering might get rid of the tiny amount of remaining combing in option 2.
I'm also in two minds as to whether double-buffering would help. It would also get a bit messy, as it would need to be disabled when deinteracing was disabled.
IanB wrote:
Fri Oct 19, 2018 12:28 am
I tried a few other ideas but they didn't work as there isn't enough processing time to do anything else. Frankly I'm amazed it works as well as it does with only a handful of instructions.
I think it's absolutely brilliant as well.

I'll merge back to master and push a release as soon as we are both happy there is no further tweaking needed.

It would be nice of deinterlacing could remain enabled when the OSD is active. At the moment, you can change the denterlace setting in the OSD, but you don't see the effect until the OSD is exited, which is a bit counter intuitive.

Dave
Last edited by hoglet on Fri Oct 19, 2018 9:05 am, edited 2 times in total.

User avatar
IanB
Posts: 376
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 » Fri Oct 19, 2018 12:29 pm

hoglet wrote:
Fri Oct 19, 2018 6:48 am
Already done and pushed!
https://github.com/hoglet67/RGBtoHDMI/c ... e72fc95d06
One minor thing: Adaptive is misspelled as Adpative in the OSD
hoglet wrote:
Fri Oct 19, 2018 6:48 am
It would be nice of deinterlacing could remain enabled when the OSD is active. At the moment, you can change the denterlace setting in the OSD, but you don't see the effect until the OSD is exited, which is a bit counter intuitive.
I don't think that would be possible as you would have to add an extra read for each of the additional writes to preserve the OSD bits.
The only idea I can think of is to temporarily blank the osd when you press the button down for more than a fixed period (e.g. 1 sec) to change the interlace type and restore the osd when you release the button so if you hold the button down for a few secs when cycling through the interlace options you can use that to see what effect it has on any moving mode 7 source.

i.e.
call up menu and select interlace
briefly pressing & releasing the button to cycle through the three options would work as now but if you hold the button down for more than 1 sec after the interlace value has changed the osd is blanked until the button is released.
An alternative behaviour would be to auto cycle through the options when the button is held down
(1 second may not be the optimal time for this behaviour)

Edit: Yet another option would be to apply the hold down behaviour to the middle button and let the right button cycle through the options as normal.
i.e. briefly press & release the middle button until the interlace option is visible then keep the button held down for more than 1 sec to blank the OSD and then press the right button to cycle the options (This hold down behaviour could apply to all menu options, not just interlace.) Releasing the middle button would restore the OSD.
Last edited by IanB on Fri Oct 19, 2018 1:15 pm, edited 2 times in total.

User avatar
hoglet
Posts: 8189
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 Oct 19, 2018 2:38 pm

IanB wrote:
Fri Oct 19, 2018 12:29 pm
One minor thing: Adaptive is misspelled as Adpative in the OSD
Thanks, fixed.
IanB wrote:
Fri Oct 19, 2018 12:29 pm
I don't think that would be possible as you would have to add an extra read for each of the additional writes to preserve the OSD bits.
Do we know this is not possible without causing disruption?

I might give it a try anyway....

Dave
Last edited by hoglet on Fri Oct 19, 2018 3:09 pm, edited 2 times in total.

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

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

Post by dp11 » Fri Oct 19, 2018 4:23 pm

I've not been really tracking this project. Is there critical section of code that i can look at to see if there are any obvious optimisations?

User avatar
IanB
Posts: 376
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 » Fri Oct 19, 2018 5:52 pm

hoglet wrote:
Fri Oct 19, 2018 2:38 pm
Do we know this is not possible without causing disruption?
Well at the moment the code has 1 screen memory read and 4 screen memory writes. While experimenting earlier I changed it to 2 reads and 3 writes and that caused glitches so a screen memory read causes much more of a latency problem than a screen memory write which points to the screen being read cached with the glitches being caused by cache line fills.

I just added 12 additional dummy writes with no visible issues. When I increased it to 16 I got very occasional glitches and increasing to 20 generated more.
This means that if the read caching was switched off and a single read was equivalent to a single write there should be enough time for fixing the OSD and maybe improving the deinterlace further still.

There will be some loss by disabling cacheing as the current single read mentioned above is sequential so there will be an additional time penalty to read those sequential words.

Also this may affect any OSD processing you do in the blanking period so it might have to be re-enabled for the other modes

User avatar
IanB
Posts: 376
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 » Fri Oct 19, 2018 7:08 pm

dp11 wrote:
Fri Oct 19, 2018 4:23 pm
I've not been really tracking this project. Is there critical section of code that i can look at to see if there are any obvious optimisations?
I think it's mainly cache line fill latency that's causing the problem at the moment

User avatar
BigEd
Posts: 2488
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 » Fri Oct 19, 2018 7:14 pm

I might be missing something here... consider that reads may stall the pipeline, while writes can be posted to a write buffer, and possibly consolidated into bursts. Does that explain the observation?

User avatar
IanB
Posts: 376
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 » Fri Oct 19, 2018 7:16 pm

BigEd wrote:
Fri Oct 19, 2018 7:14 pm
I might be missing something here... consider that reads may stall the pipeline, while writes can be posted to a write buffer, and possibly consolidated into bursts. Does that explain the observation?
Yes that could be a possible expanation.
Last edited by IanB on Fri Oct 19, 2018 7:19 pm, edited 1 time in total.

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

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

Post by dp11 » Fri Oct 19, 2018 10:15 pm

a few armv6 and onwards tips

If you are using the shifter make sure the register isn't changed in the previous cycle

Code: Select all

        and    r9, r8, #(7 << (PIXEL_BASE + 9))
        orr    r10, r10, r9, lsl #(15 - PIXEL_BASE) // takes 2 cycles  as R9 isn't ready in time for the shifter 
Make sure the result of LDRs are used for at least for at least two cycles ( longer if not in the cache or the result is the used in the next LDR)

Code: Select all

        
        ldr    r0, =INTPEND2
        ldr    r0, [r0]				// stall for 3 cycles before executing 
        tst    r0, #(1<<VSYNCINT)		// stall for at least 2 cycles  before executing
        
If you schedule some instructions using other registers during the stalls you get them for effectively free.

the above examples aren't in the critical code , but are used to show how the pipeline can stall
Last edited by dp11 on Fri Oct 19, 2018 10:19 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8189
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 Oct 20, 2018 12:02 pm

Thanks Dominic for those tips. We might well need them, as we're really on the edge here.

I've had a go at re-working the code to allow deinterlacing to continue while the OSD is active.

I've pushed what I have so-far to dev - it starts here:
https://github.com/hoglet67/RGBtoHDMI/b ... _fb.S#L247

Every 8 pixels (500ns) there is now:
1 - load from comparison buffer
2 - store to comparison buffer
3 - load from frame buffer (if pixel data changed)
4 - store to frame buffer (if pixel data changed)
5 - load from comparison buffer (in Motion Adaptive 2 mode only)
6 - store to comparison buffer (in Motion Adaptive 2 mode only)
7 - store to frame buffer

So worst case there are now three loads and four stores. But that worst case only occurs in Motion Adaptive 2 mode, and only when there is motion on the screen.

I think this is working without introducing any sampling jitter, but it's a little hard to tell.

Ian, would you like to give it a try and see what you think.

Dave

User avatar
IanB
Posts: 376
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 » Sat Oct 20, 2018 4:50 pm

hoglet wrote:
Sat Oct 20, 2018 12:02 pm
I think this is working without introducing any sampling jitter, but it's a little hard to tell.
Ian, would you like to give it a try and see what you think.
I managed to get glitches in motion adaptive 2 but not a great amount so it's just marginal.
Try to *DUMP a file and you will see random glitches. It helps to use CTRL+SHIFT to start/stop the scrolling
This doesn't seem to happen in motion adaptive 1

If dp11 can't come up with any optimisations that help, as it's very marginal and only happens under chronic cases, a workaround would be to have separate loops for when the OSD is on and off. (i.e. we revert to the old code when the OSD is off).

Here is a simple mode 7 motion test program (M7TEST):
mode7test.zip
(11.93 KiB) Downloaded 4 times

It's on the mode 7 scramble disk so you can use that for testing as well.

The mode 7 test program moves blocks across the screen at 50 Hz (upper) and 25Hz (lower)
Motion adaptive 1 only deinterlaces the 25 Hz motion and motion Adaptive 2 does both. This isn't surprising as the algorithm compares even with even and odd with odd so it can only detect 25Hz motion. To properly detect 50Hz motion it should be comparing odd with even but as they are not identical even when the video is stationary that would require much more complex processing which is why I ended up with the workaround we discussed above.
BTW a good test to look at the 'fizzing' is to use basic editor and press the Escape key to switch between the screens.
Last edited by IanB on Sat Oct 20, 2018 4:53 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8189
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 Oct 20, 2018 5:05 pm

Thanks for that Ian - I plan to continue this tomorrow, as there are some further things I want to try.

In some respects getting the deinterlacing to work with the OSD active is a bit of a luxury. But in trying, we are getting a better understanding of exactly how much memory activity is possible. That might eventually lead to even better deinterlacing.

Dave
Last edited by hoglet on Sat Oct 20, 2018 5:05 pm, edited 1 time in total.

User avatar
IanB
Posts: 376
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 » Sat Oct 20, 2018 7:01 pm

hoglet wrote:
Sat Oct 20, 2018 5:05 pm
In some respects getting the deinterlacing to work with the OSD active is a bit of a luxury. But in trying, we are getting a better understanding of exactly how much memory activity is possible. That might eventually lead to even better deinterlacing.
I fixed the glitches by reordering some more instructions and re-arranging register use according to dp11's helpful hints above.
I'm now going to retry some of my other deinterlacing ideas using the same re-ordering trick to see if they make any improvement.

Post Reply