Scaler

[Sorgelig]

Although new phase accumulator is better, still it's not perfect.
I don't know how VIP did it, but there were no artifacts on LCD filter regardless the scaling factor.
I can provide some sources regarding this if Grabulosaure wants. May be it will help to improve the phase acc.

[Grabulosaure]

I hope it won't affect the 1280x720i Minimig resolution with 1280x720 HDMI output.
Interlaced modes on consoles aren't that important than on Minimig where interlace modes are the main modes for high resolutions.

Previous version was broken when downscaling interlaced video. This version gives sub-obtimal results.
When the size is equal, proper deinterlacing is possible.

can you tell more about what is ready and what is not. I want to add your PLL adjust module to framework and use single buffer when vsync_adjust is enabled. Will it work?

First, here is a video of what is does :
https://www.youtube.com/watch?v=veRuXe2wN0g

A goal was to separate the scaler from the low-lag tweaks. Fixing low lag should not impact the scaler.

The current implementation of pll_hdmi_adj is good enough for a test and for Genesis/Megadrive. It has issues with SNES. It cannot automatically readjust frequency between 50Hz and 60Hz. Fixing that will need a proper mathematical analysis (for example the PLL adjust is proportional to frequency, the scaler output is proportional to time) and characterisation of the PLL (max slew rate, when to reset it, other parameters...). And probably some cooperation with the MiSTer software about frequency settings.
In the Altera/Intel documentation, there is no clear indication that PLL frequency can be adjusted continuously without glitches, without having to reset the PLL (or I didn't find it).
This demo proves that it is possible!

[loloC2C]

Could you please test the versions there :
http://temlib.org/pub/mister/ascal/

I tested both the Genesis-lite.rbf and the SNES.rbf from the above link and the issue is still there.

[Sorgelig]

The current implementation of pll_hdmi_adj is good enough for a test and for Genesis/Megadrive. It has issues with SNES. It cannot automatically readjust frequency between 50Hz and 60Hz. Fixing that will need a proper mathematical analysis (for example the PLL adjust is proportional to frequency, the scaler output is proportional to time) and characterisation of the PLL (max slew rate, when to reset it, other parameters...). And probably some cooperation with the MiSTer software about frequency settings.
In the Altera/Intel documentation, there is no clear indication that PLL frequency can be adjusted continuously without glitches, without having to reset the PLL (or I didn't find it).
This demo proves that it is possible!

so you don't use PLL settings from MiSTer?
You can get initial PLL settings from MiSTer as it's already close to what is required for FPS lock. Then finetune it in your PLL adjustment module.

As for PLL adjustments, it's hard to tell. Basically it needs time to lock the desired VCO frequency. Probably small changes don't unlock the PLL.

[Grabulosaure]

You can get initial PLL settings from MiSTer as it's already close to what is required for FPS lock. Then finetune it in your PLL adjustment module.

The PLL adjust module is inserted between PLL_HDMI_CFG block which reprograms the PLL and your block that generates accesses from the software issued commands.
It snoops accesses to the register "000111" which sets the "M" fractional frequency coefficient and uses it as reference.
Maybe other settings such as "Charge Pump" and "Bandwidth" should be taken into account.

[Sorgelig]

Since this FPS lock thing is already come to non-standard tricks like constant PLL adjust, then it's worth to try other trick. It won't affect the PLL:
Your scaler may check the drifting of output and once it drift by one line, you add one VSync line or remove one VSync line. So scaler will keep the drifting within the one line.
Not sure how many TVs/Monitors will accept it.

[Sorgelig]

The PLL adjust module is inserted between PLL_HDMI_CFG block which reprograms the PLL and your block that generates accesses from the software issued commands.
It snoops accesses to the register "000111" which sets the "M" fractional frequency coefficient and uses it as reference.
Maybe other settings such as "Charge Pump" and "Bandwidth" should be taken into account.

So you adjust then PLL only once? How you can keep the output from drifting?

[Grabulosaure]

So you adjust then PLL only once? How you can keep the output from drifting?

No, the scaler delivers new measures on every frame. The syntonizer updates the PLL every time the drift exceeds a small value.

With a 32bits "M" counter, the Altera PLL tuning can be very precise. Screen already need to support small variations, for example quartz oscillators precision, typically up to 100PPM, and drifts, a few PPM/°C.

Since this FPS lock thing is already come to non-standard tricks like constant PLL adjust, then it's worth to try other trick. It won't affect the PLL:
Your scaler may check the drifting of output and once it drift by one line, you add one VSync line or remove one VSync line. So scaler will keep the drifting within the one line.
Not sure how many TVs/Monitors will accept it.

I have tried to add/remove one cycle to the output, it didn't work. I have tried to add/remove one whole line, it didn't work either.

[Sorgelig]

I've copied your solution to SNES (since i'm working on SNES now) and even in 60Hz it doesn't work well. After some time i start to see tearing in scroll. There is grid scroll test in 240p Suite. Sometimes it happens immediately, so it seems scaler doesn't re-sync it in the beginning for frame.

[Sorgelig]

With a 32bits "M" counter, the Altera PLL tuning can be very precise.

Not sure why you call it "M" counter, as fractional part is actually "K". Make sure your code uses correct parameter.

[Grabulosaure]

I've copied your solution to SNES (since i'm working on SNES now) and even in 60Hz it doesn't work well. After some time i start to see tearing in scroll. There is grid scroll test in 240p Suite. Sometimes it happens immediately, so it seems scaler doesn't re-sync it in the beginning for frame.

I've posted a new version of SNES more stable, with lower gain, but slower convergence (up to around 20s). And it doesn't like SNES interlaced video :

Code: Select all

@@ -130,7 +130,7 @@ BEGIN
             ELSIF phm='0' AND fcpt=2 THEN
               -- Frequency adjust
               IF off<10 THEN off:=10; END IF;
-              dif:=shift_right(mfrac,off);
+              dif:=shift_right(mfrac,off + 1);
               diff<=dif;
               sign<=lltune_sync(5);
               IF off>=18 THEN
@@ -143,7 +143,7 @@ BEGIN
             ELSIF phm='1' THEN
               -- Phase adjust
               IF ofp<5 THEN ofp:=5; END IF;
-              dif:=shift_right(mfrac,ofp + 3);
+              dif:=shift_right(mfrac,ofp + 3  + 1);
               IF (ofp>=18 OR off<16) AND fcpt=2 AND phcor=0 THEN
                 phm<='0';
               END IF;


Need to compensate the non-linearity. IMHO. Maths!

[Sorgelig]

Ok. i will release SNES with this option. Anyway it's an optional mode, so main usage should not be affected.
Users will test it better
In general case tweak only fractional part is not always enough. It can be on the edge of 0 or 1.

[ijor]

In the Altera/Intel documentation, there is no clear indication that PLL frequency can be adjusted continuously without glitches, without having to reset the PLL (or I didn't find it). This demo proves that it is possible!

The documentation might be a bit ambiguous, but it does state that the PLL should be reset after reconfiguration. It even recommends to disable the clock output in some cases.

I don't think that a test can prove it would work always. It might work in some situations, might not work in others. It might depend on when exactly the configuration is changed and what was the state of the counters at that time.

Might be worth to ask on Intel Forum. Not sure we'll get an authoritative answer. We might get just a not so useful commendation "you should better reset the PLL just in case". But you might be lucky.

[Sorgelig]

Might be worth to ask on Intel Forum. Not sure we'll get an authoritative answer. We might get just a not so useful commendation "you should better reset the PLL just in case". But you might be lucky.

my experience with Altera/Intel forum show it as useless in case if you ask specific question and want to get clear answer there.
Sometimes you can browse that forum (which has been ruined by intel's redesign recently) and get some clues.

[Sorgelig]

The documentation might be a bit ambiguous, but it does state that the PLL should be reset after reconfiguration. It even recommends to disable the clock output in some cases.

My vsync_adjust option doesn't reset PLL. And reconfiguration always works.

[ijor]

my experience with Altera/Intel forum show it as useless in case if you ask specific question and want to get clear answer there.
Sometimes you can browse that forum (which has been ruined by intel's redesign recently) and get some clues.

Yes, I mostly agree. That's why I said that you might be lucky an get a useful answer. May be somebody with a support contract can ask through an official support channel.

My vsync_adjust option doesn't reset PLL. And reconfiguration always works.

The issue is not if reconfiguration would work or not but how, with which secondary effects. You don't need or expect a smooth glitchless transition when you apply the option. You don't care if the monitor would resync at that time. That's different than reconfiguring the PLL constantly when the video is already live and you try to avoid glitches and loss of lock.

[Grabulosaure]

The documentation might be a bit ambiguous, but it does state that the PLL should be reset after reconfiguration. It even recommends to disable the clock output in some cases.

My vsync_adjust option doesn't reset PLL. And reconfiguration always works.

The PLL/Synthesiser has multiplication and division ratios, it has also the fine tuning parameter "K" which controls a delta-sigma modulator.
My hope is that it could be possible to start with K≈0.5, fix the multiplication and division ratios accordingly, then do only fine-tuning of K to keep synchronisation. If the delta-sigma modulator generates a few erroneous bits during updates, it won't change much the output frequency.

[Sorgelig]

My hope is that it could be possible to start with K≈0.5, fix the multiplication and division ratios accordingly, then do only fine-tuning of K to keep synchronisation.

This is not what can be chosen.

[Grabulosaure]

My hope is that it could be possible to start with K≈0.5, fix the multiplication and division ratios accordingly, then do only fine-tuning of K to keep synchronisation.

This is not what can be chosen.

The PLL VCO can cover a bit more than an octave. It should be possible to avoid values for K too close to 0 and 1.

[Sorgelig]

The PLL VCO can cover a bit more than an octave. It should be possible to avoid values for K too close to 0 and 1.

Not always. PLL Input freq is 50MHz. If output is close to 50,100,150 then K is close to 0(or 1) in any M/C ratio.
Popular frequency 148.50MHz is one of these.
Actually changing M is not harder than K. It's like 33th bit. But Altera doesn't recommend to use K values <0.05 and >0.95.

[Grabulosaure]

The PLL VCO can cover a bit more than an octave. It should be possible to avoid values for K too close to 0 and 1.

Not always. PLL Input freq is 50MHz. If output is close to 50,100,150 then K is close to 0(or 1) in any M/C ratio.
Popular frequency 148.50MHz is one of these.
Actually changing M is not harder than K. It's like 33th bit. But Altera doesn't recommend to use K values <0.05 and >0.95.

Ah! You are right. Sad.
Apart from cascading PLLs, or trying to change M, it won't work with frequencies close to multiples of 50MHz !

[Sorgelig]

I definitely don't like idea of 2 cascaded PLLs. Modification of M is much easier and more clean solution.

[Sorgelig]

By the way, while output performance of ascal is excellent, the input is not that good.
Tried ascal on ZX Spectrum core and got very bad video over HDMI (while VGA output is good).
ZX Spectrum uses common clock 112MHz for the whole core. ce_pix can vary from 7MHz to 56MHz depending on resolution and scandoubler Fx. And even with ce_pix = 7MHz the picture is garbled.
I had to re-clock the video to 56MHz to get correct picture.
So, regardless the CE rate, video clock is limited. SNES uses 85MHz for CLK_VIDEO and video is correct while 112MHz is already too much for ascal.

[Grabulosaure]

By the way, while output performance of ascal is excellent, the input is not that good.
Tried ascal on ZX Spectrum core and got very bad video over HDMI (while VGA output is good).
ZX Spectrum uses common clock 112MHz for the whole core. ce_pix can vary from 7MHz to 56MHz depending on resolution and scandoubler Fx. And even with ce_pix = 7MHz the picture is garbled.
I had to re-clock the video to 56MHz to get correct picture.
So, regardless the CE rate, video clock is limited. SNES uses 85MHz for CLK_VIDEO and video is correct while 112MHz is already too much for ascal.

Sorry. Bad clock gating of input video :

Code: Select all

@@ -1265,13 +1266,13 @@ BEGIN
       
       ------------------------------------------------------
       -- Push pixels to downscaling line buffer
-      i_lwr<=i_hnp4 AND i_ven5;
+      i_lwr<=i_hnp4 AND i_ven5 AND i_ce;
       IF i_lwr='1' THEN
         i_lwad<=(i_lwad+1) MOD OHRES;
       END IF;
       i_ldw<=i_hpix;
       
-      IF i_hnp3='1' AND i_ven4='1' THEN
+      IF i_hnp3='1' AND i_ven4='1' AND i_ce='1' THEN
         i_lrad<=(i_lrad+1) MOD OHRES;
       END IF;


I have posted a new version (also added interlaced video info in the Low Lag parameters, for uneven frames)
The input part should be able to reach frequencies close to the output part (similar pipelining, same interpoler, same phase accumulator for downsampling...).

I definitely don't like idea of 2 cascaded PLLs. Modification of M is much easier and more clean solution.

I don't like it either. More jitter, and the HDMI encoder has another cascaded multiplying PLL.

I will add updates to the M register to allow wider synchronisation ranges, automatic switching between 50Hz and 60Hz.
If seamless updates of the M register don't work, requiring pixel clock frequencies not too close to multiples of 50Hz is, IMHO, an acceptable constraint for those which desperately need low latency on MiSTer.

[Sorgelig]

I will add updates to the M register to allow wider synchronisation ranges, automatic switching between 50Hz and 60Hz.
If seamless updates of the M register don't work, requiring pixel clock frequencies not too close to multiples of 50Hz is, IMHO, an acceptable constraint for those which desperately need low latency on MiSTer.

Not sure if we are on the same wave or not, but MiSTer already provides pretty much precise PLL parameters for FPS locking when vsync_adjust option is enabled. It just cannot track the drifting and adjust the clock constantly. So your scaler doesn't need to lock the FPS in wide range as output FPS is already close to input. You just need to track the drifting and fine tune the frequency in tiny range.