Scaler

[Grabulosaure]

can you release this patch?
That would be good for new release with fixed VSync.

Posted.

There is a WIP pipelined divider for the "phase accumulator" mode which now calculates correct interpolation (previously it used a multiplication by 1/SIZE which wasn't quite precise enough and got timing violations). The goal is to eventually get rid of the "delta" signals.

[HeroOfTheDay]

Genesis.zip
Those who have problem with last Genesis release, please try this one.

I've made VSync the same way as in VIP. May be it will fix the problem.

This fixed it for me on my 4k Samsung TV as well. Now just the NES and SNES that aren't working since the latest updates.

[jim150]

Genesis.zip
Those who have problem with last Genesis release, please try this one.

I've made VSync the same way as in VIP. May be it will fix the problem.

Yes this core works perfectly on my previously affected Sony TV. Thanks for your time and your effort!

[Sorgelig]

Ok. I see the problem has been fixed.

I've posted official Genesis release. Any further discussion should move to Genesis and other cores threads.

[Sorgelig]

There is a WIP pipelined divider for the "phase accumulator" mode which now calculates correct interpolation (previously it used a multiplication by 1/SIZE which wasn't quite precise enough and got timing violations). The goal is to eventually get rid of the "delta" signals.

In Genesis on Sonic 1 white screen with blue SEGA logo when using LCD effect coefficients you can see some vertical pale stripes. This is a believe result of rounding. Do you mean this problem?
VIP scaler has no such stripes.

[ghogan42]

There is a WIP pipelined divider for the "phase accumulator" mode which now calculates correct interpolation (previously it used a multiplication by 1/SIZE which wasn't quite precise enough and got timing violations). The goal is to eventually get rid of the "delta" signals.

In Genesis on Sonic 1 white screen with blue SEGA logo when using LCD effect coefficients you can see some vertical pale stripes. This is a believe result of rounding. Do you mean this problem?
VIP scaler has no such stripes.

This can not be fixed unless an integer scale is forced for horz. and vert. scaling. Maybe when MiSTer 2 supprts 4k TVs.

In his test builds, had 3 different "Poly methods": Poly, Poly Rounding Poly PhaseAcc. Each method had very minor differences in when you use dark scanlines or the LCD effect. I don't know which is the best (least rounding errors), but I'm not sure it matters because you can't get perfect results anyway (without perfect integer scaling).

[Gamepimp]

My issue with the top of the image (and apparently the bottom of it based off of the 240p test suite grid pattern) being cut off was fixed by changing the "Picture Size" option on my Samsung TV. There were 4 options: 16:9, Zoom, 4:3, and Custom. I had to choose "Custom" for the entire image to display (which is set to 4:3 in the core).

Unfortunately once I did that, I noticed some scanlines appeared darker while others appeared lighter when there was movement in the game. It created what looked like horizontal bands across the screen. I played around with the resolution settings in the config file as well as the vscale_integer value. The best image I was able to obtain (clean scanlines) while filling most of the screen vertically was to set the resolution to 720p (1280x720@60) and to set vscale_integer to 1.

[Sorgelig]

This can not be fixed unless an integer scale is forced for horz. and vert. scaling.

you didn't read my message carefully. I've wrote that VIP scaler has no such artifacts and it's not scaled by integer. Check the Genesis_20181126.
So it has nothing to do with integer scaling. It's simply an error accumulation in interpolation.

[Sorgelig]

My issue with the top of the image

Stop to post it here! It has no relation to scaler!

[Grabulosaure]

Here is an experiment.
I have posted scaler test versions of SNES and Genesis/Megadrive (on http://temlib.org/pub/mister/ascal/)
In the OSD menu, the first "Scaler:" entry allows to select different interpolers.

The questions are :
Which is better among the Polyphase interpolers ? Are there have visible defects ? No difference ? Which resolution are you using, which filter ?
Options are :
1) Poly
2) Poly Rounding
3) Poly Phase Acc
4) TEST (ignore the characters on top)
5) Original Altera VIP builds

Differences are very small.

Sub-question :
Which coefficients for default polyphase filter ?

[Note : I'm still optimising the scaler to achieve higher pixel rates, but these test versions, which implement additional hardware,
support lower freq. than final versions]

[ghogan42]

The questions are :
Which is better among the Polyphase interpolers ? Are there have visible defects ? No difference ? Which resolution are you using, which filter ?

[Note : I'm still optimising the scaler to achieve higher pixel rates, but these test versions, which implement additional hardware,
support lower freq. than final versions]

Just a note. Due to rounding errors (well the rounding is fine but row sums should be more important), a few of the coefficient sets in the filter repository that should have rows that sum to 128 actually have rows that sum to 127 or 129. The results is slight banding until I go back and fix them. That's not the fault of Grabulosaure's scaler. That's my fault in computing the coefficients and not checking for this carefully.

The ones that I have spotted so far include Gasussian_Sharp_01, Gaussian_Sharp_03, Bicubic.

These banding/line effects can change position based on the polyphase implementaion but aren't the scaler's fault.

[Sorgelig]

3) Poly Phase Acc

This one is the best polyphase version among others! When you will release it?
I test on LCD effect filter on white screen (240p suite). Other versions give stripes clearly visible. Phase Acc gives monotonic LCD effect (same as VIP).

[Sorgelig]

Just compiled ao486 with ascal and it works well with pixel clock 178MHz. This pixel clock is achieved when vsync_adjust=1 and ao486 uses some video mode with 72Hz.

[ghogan42]

3) Poly Phase Acc

This one is the best polyphase version among others! When you will release it?
I test on LCD effect filter on white screen (240p suite). Other versions give stripes clearly visible. Phase Acc gives monotonic LCD effect (same as VIP).

I did a few tests here too. I have a small modification to mister_main to make 'vscale_integer=1' allow scaling increments of 0.5 instead of 1.0.

When I do this with 100% scanline effect only the PhaseAcc option gives correct output (well Test looks ok too). So my vote is for PhaseAcc too.

[ghogan42]

I can't make a screenshot because I have no capture card. But for anyone that wants to see what I'm talking about I've made a test.

(1) I've compiled SNES with Phase Accurate enabled. To do this only requires two small changes.

(a) In sys_top.v line 563 you must change:

Code: Select all

.mode     ({1'b1,scaler_flt ? 3'd4 : 3'd0}),

to

Code: Select all

.mode     ({1'b1,scaler_flt ? 3'd6 : 3'd0}),

(b) In ascal.vhd line 422 you set the value to true

Code: Select all

  SIGNAL o_phacc : boolean := false; -- <TEST> False=Delta True=Phase acc.

to

Code: Select all

  SIGNAL o_phacc : boolean := true; -- <TEST> False=Delta True=Phase acc.

And then Phase Acc mode should be enabled.

To see the benefit of PhaseAcc clearly, you can download the zip file here: https://drive.google.com/open?id=1ndp_9 ... 6EBhx7ktzG

It contains a "normal" compile of the SNES core and a "PhaseAcc" version of the SNES core.

You need to use the copy of the mister binary in the zip as well and set

Code: Select all

vscale_integer=2 

in your mister.ini

Then if you set the filter to nomal_scanlines_100 (or others but this one is the easiest to see) you can see that the PhaseAcc version of the core scales without the problems in the standard version.

BTW, Sorgelig, I've modifed mister main so that vscale_integer works like this:

vscale_integer=0 Just as before. Free Scaling
vscale_integer=1 Just as before. Locked to integers 4.0, 5.0,...
vscale_integer=2 Locked to half values 4.0, 4.5, 5.0,...
vscale_integer=3 Locked to thirds 4.0,4.33, 4.67,...

up to vscale_integer=5 but 4 is probably the last useful value.

It's only a two line change in user_io.cpp and a one line change in cfg.cpp.
Would you want a pulll request for this (just the mister vscale_integer change)? The combination of half values and PhaseAcc has large benefits for scanline filters.

[Sorgelig]

that would be confusing to have integer scaling option which is not really integer

[foft]

For 0 delay fans, I had success with the synced plls option discussed earlier in the thread. For the Atari 800 core on my own cyclone V board.

The original pal core runs at 49.86Hz, so I overclocked it to exactly 50Hz. So 0.28% faster, but no lag. The fractional plls are very accurate, ok perhaps there is a frame dropped or glitched every few weeks. The horizontal timing is not matched but a few scanlines of buffer solves that.

Of course since I'm just doing one core I had the luxury of pre-computing the pll settings in octave, but it can be computed on the arm I think.

Anyway I know Sorgelig will just tell me that if I am not going to do it I should shut up (which is a fair point), but I wanted to say ... it works ... if anyone feels like implementing it. If you can live with slightly non-original refresh rates.

Anyway great work on the scaler...

[Sorgelig]

I didn't say it won't work. It just not universal solution. Some cores generate different resolutions with different timings.
Current MiSTer implementation already has solution for matching the output frame rate with input by altering the HDMI pixel clock. This is universal solution for all cores and even for those which generate different resolutions.
Yes, it requires TV/Monitor supporting variable pixel clock. But for those who care it's not a problem to find a compatible monitor - it's not that hard to find especially Monitors supporting variable pixel clocks.

[loloC2C]

Hello,

I would like to report an edge case bug on my TV set. It seems related to ascal with the latest cores and MiSter file (all files were last updated as of today on December 25th) as I did not have this problem with older cores using the default VIP scaler.

I could not reproduce the problem on my PC monitor so it definitely seems to be a video compatibility issue.

It looks like the very last line has some "garbage" pixels from another line (100% reproductible on Genesis, NES, SNES, TG16 and GB cores) :





You can easily notice the problem in the bottom left area as it's visible inside the left black bar but the whole line is off (better seen on the Sonic screenshot below the life counter).

I have all the default settings inside MiSTer.ini except for :
video_mode=8
vsync_adjust=1

The issue is there regardless of vsync_adjust being 1 or 0.

Thanks

[Sorgelig]

Do you use 4:3 aspect ratio in OSD? Or your TV adds some additional bars on the left/right?

[loloC2C]

Yes I use the default 4:3 aspect ratio and I suppose the black bars are coming straight from the HDMI.

Here are some additional pics with the TV's OSD input information on top of the display:





Thanks

[Grabulosaure]

Here is, at last, a new version of the scaler.

Changes :
- Phase accumulator
I've removed all the "delta" stuff and switched to the "phase accumulator" mode, which is more precise.
Maybe some further rounding could enhance a bit the output.

- Optimisations
Simplfications, timing optimisation. The BiCubic interpoler is a bit slower, but no one uses it anyway.
I think I have done enough pipelinig for now, it works at frequencies well above the announced HDMI encoder limit.

- Vertical downscaling of interlaced video
If the deinterlaced image height is larger than the output image height (for example 480i on a 640x400 display), then only half frames are used. Doing proper vertical interpolation would require to duplicate a part of the horizontal output pipeline and move vertical downsampling to the output side. I hope that there is no urgent need for fixing that.

- Low lag
I have removed the "low lag mode" in the scaler.
The scaler now has instead additional outputs (lltune([]) which indicates the frequency and phase difference between the input and output video. These signals could be used by a separate block which adjusts the HDMI PLL frequency to cancel frequency and phase offsets.

... And this is exactly what "pll_hdmi_adj.vhd" does in the demo version of Genesis/Megadrive.
This code was only tested around 60Hz, it should be replaced by a mathematically sound implementation compatible with more cores.
Video alignment can take up to 10 seconds (and disable vsync_adjust, no triple buffering).

I hope that there is no regression, there are many changes.

Here are some additional pics with the TV's OSD input information on top of the display:

Thanks

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

[Sorgelig]

Here is, at last, a new version of the scaler.

1) why you set OHRES to 4096 in your example?
Some cores like SNES are close to BRAM shortage already and i don't want to spend more precious BRAM to scaler.
2) How PLL autoadjust is controlled? Is it always ON in your example?

[Grabulosaure]

Here is, at last, a new version of the scaler.

1) why you set OHRES to 4096 in your example?
Some cores like SNES are close to BRAM shortage already and i don't want to spend more precious BRAM to scaler.
2) How PLL autoadjust is controlled? Is it always ON in your example?

1) For 2650x1600. What else ? The default can remain at 2048 though.
2) It is controlled with sconf[4] = llena. This PLL part is not quite ready yet.
ASCAL.vhd can directly replace the old version (there are additional outputs, but they can be left unused.)

[Sorgelig]

- Vertical downscaling of interlaced video
If the deinterlaced image height is larger than the output image height (for example 480i on a 640x400 display), then only half frames are used. Doing proper vertical interpolation would require to duplicate a part of the horizontal output pipeline and move vertical downsampling to the output side. I hope that there is no urgent need for fixing that.

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.

This PLL part is not quite ready yet.

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?