Scaler

[Grabulosaure]

this is error:

Code: Select all

poly_a2<=poly_a(FRAC+2 DOWNTO FRAC+3) & poly_a(FRAC+1 DOWNTO 2);

what should be instead of (FRAC+2 DOWNTO FRAC+3)?

It should be simply

Code: Select all

poly_a2<=poly_a(FRAC+1 DOWNTO 2);

I forgot to remove that part when I removed the option to store several sets of coefficients (which is useless with the new MISTER menu).
It doesn't change anything as (FRAC+2 DOWNTO FRAC+3) is a zero length vector.
Thank you for finding this.

Edges almost perfect but i still see irregularity of left/right edges. Use 240p Suite in Genesis. Grid 320x224 and 256x224. In 320 mode edges look almost perfect. In 256 mode left edge has doubling pixel in 16:9 ratio. 4:3 looks normal.

I have posted a fixed version. Hopefully.
It was _again_ the silly bug about OHSIZE and writes going beyond 2047. The fix got lost in refactoring. Much easier than pixel centering details and pipelining.

For interlaced, current implementation is Weave. I don't know much about how to implement more advanced methods, such as motion compensation, yet.

it seems Ascal doesn't like frames with different vertical sizes - this is usual for Interlace modes. That's why SNES in interlace makes Ascal crazy.
Note: the visible lines in both fields are the same but total lines in one of fields is one less. This is how interlace mode works. Genesis has the same total lines for both fields in interlace mode - this is just Genesis specific, not normal.

You have a sample ROM for testing that ?

[Sorgelig]

You have a sample ROM for testing that ?

sure! 240p Suite for SNES: https://sourceforge.net/projects/testsu ... /SNES_SFC/
On the main page the last option: "Video: 256x224p" choose it and it will switch to 256x480i
Also note that it's not exactly field0 should be one line longer than field1. It may be opposite for some other systems.
I suggest to measure the frame size only when f1=0 (field 0). So it will be universal between progressive and interlaced modes.
Or simply don't count non-visible lines.

[Sorgelig]

I have posted a fixed version. Hopefully.

Yeah. Now this is perfect from tests i've made. Hope edges problem is fixed
Still need to check on different cores.

one more note: many cores have irregularities outside the visible area. Some cores like SNES have several non-standard pixels in HBlank area. Genesis has other pixel clock in HBlank in 320pix mode. Currently i've added workaround for this, but it's not always possible to make. Many cores have more irregularities during VBlank.
So, it would be good if Ascal won't use or count pixels outside the i_de activity.

[ewok]

Perfect addition. What is the preferred resolution for the scalers?

[paulbnl]

Bob is not simple field to frame conversion! If you will do this, you will have flickering on static images. So even with bob you have to detect the motion, so static won't flicker and each frame for static must include both fields in Bob mode.

Bob is what ghogan42 described. Simply linedoubling fields. The flickering is why it is called Bob.

[Sorgelig]

Grabulosaure,

I'm trying to add Ascal to Minimig. There is problem with interlace modes:

20181202_235652.jpg

This is 1280x720i50 mode.
As you see scaler recognize the input resolution but somehow only place one frame as progressive and display it on upper half.
can you try to simulate 1280x720 (2 fields of 1280x360 each) interlace at 50FPS to see where is the problem?
P.S.: standard resolutions such as 320x576i50 work ok.

[Sorgelig]

More update about Mininig hires:
I found that Blank+ option in Minimig gives such distortion. I don't know yet if specific resolution is a reason ascal displaying it incorrectly. With Blank+ resolution is 1276x722 (bad display). With normal blank, resolution is 1320x722 (correct display).

The good thing is interlace mode in Minimig looks good and there are no much visible jagged edges on moving objects like cursor or scrolling windows. Not more than in VIP scaler with de-interlacer.

[cacophony]

I don't want to distract from the excellent progress that's being made towards switching to the new scaler, but here are a few findings that hopefully justify further attempts to get the low lag option working in the future.

Mike Tyson's Punch Out is often used as an example of needing low lag, and here is some captures from FCEUX with TAS editor which illustrate why. It turns out that the first punch in the match requires a reaction of less than ~13 frames, as that's the time from the first visual indication of the punch coming to the last frame when the controller input will dodge the punch.


Frame before first visual indication


First frame indication of punch coming


Last frame where a dodge input would be successful

So in an ideal circumstance where there's zero introduced controller/device/monitor lag, a person would have ~217ms to react to Mike Tyson. But the average reaction time for visual stimulus sounds like it's about 250ms, which I guess explains why so few people can actually beat Tyson:

https://backyardbrains.com/experiments/reactiontime
https://www.humanbenchmark.com/tests/re ... statistics

[Grabulosaure]

More update about Mininig hires:
I found that Blank+ option in Minimig gives such distortion. I don't know yet if specific resolution is a reason ascal displaying it incorrectly. With Blank+ resolution is 1276x722 (bad display). With normal blank, resolution is 1320x722 (correct display).

The good thing is interlace mode in Minimig looks good and there are no much visible jagged edges on moving objects like cursor or scrolling windows. Not more than in VIP scaler with de-interlacer.

Could you please test the version I've just posted.
With this version, lines are counted starting from DE instead of VSYNC, and image height is taken from first field.
(Interlaced with an odd number of visible lines will miss a line.)
It fixes SNES. Mostly (Sometimes SNES can have variable number of pixels per line? WTF ?)

While fixing that, I've found that vertical downscaling of interleaved video is likely broken.

I don't want to distract from the excellent progress that's being made towards switching to the new scaler, but here are a few findings that hopefully justify further attempts to get the low lag option working in the future.

Maybe this game is just badly coded and should be patched

From the scaler perspective, short latency is easy. I've tested it (with my oscilloscope ...). The problem, AFAIU, is matching clock frequencies, which can be different between cores and between screens.

[cacophony]

From the scaler perspective, short latency is easy. I've tested it (with my oscilloscope ...). The problem, AFAIU, is matching clock frequencies, which can be different between cores and between screens.

I realize this might go against the design goals for MiSTer, but maybe there could be an experimental option that enables it, and it would only work for certain cores/screens ?

Anyways, I don't mean to sidetrack the good work that's happening so carry on and thanks again for all the recent improvements

[ghogan42]

From the scaler perspective, short latency is easy. I've tested it (with my oscilloscope ...). The problem, AFAIU, is matching clock frequencies, which can be different between cores and between screens.

I realize this might go against the design goals for MiSTer, but maybe there could be an experimental option that enables it, and it would only work for certain cores/screens ?

Anyways, I don't mean to sidetrack the good work that's happening so carry on and thanks again for all the recent improvements

Grabulosaure's scaler has this built-in and is easy to enable already. It just doesn't work if you can't match the refresh rates exactly. It's not exposed in the OSD for the normal lite builds at the moment. But it's there.

[cacophony]

From the scaler perspective, short latency is easy. I've tested it (with my oscilloscope ...). The problem, AFAIU, is matching clock frequencies, which can be different between cores and between screens.

I realize this might go against the design goals for MiSTer, but maybe there could be an experimental option that enables it, and it would only work for certain cores/screens ?

Anyways, I don't mean to sidetrack the good work that's happening so carry on and thanks again for all the recent improvements

Grabulosaure's scaler has this built-in and is easy to enable already. It just doesn't work if you can't match the refresh rates exactly. It's not exposed in the OSD for the normal lite builds at the moment. But it's there.

Do we know that the option actually works for anyone? I thought the lite builds (http://temlib.org/pub/mister/ascal/) exposed the option as the 3rd Scaler item in the OSD (the one that starts in the "Normal" position). I was told that toggling that option enabled the low latency mode, but everyone who has tried just gets a black screen. I'm pretty sure my display supports the native refresh rates because it works fine with vsync_adjust=1 for the standard Genesis core. Or am I missing something?

[Sorgelig]

@cacophony,
this topic is for developers discussion. It's clear you don't understand the matter, so stop to post your non-sense here, otherwise i will simply delete your flood.

[Sorgelig]

Could you please test the version I've just posted.
With this version, lines are counted starting from DE instead of VSYNC, and image height is taken from first field.
(Interlaced with an odd number of visible lines will miss a line.)

Interlace with different lines per field looks working.
But now 256x239 (240p suite on SNES) mode with HQ2x is broken. Can you check what's wrong?

Sometimes SNES can have variable number of pixels per line? WTF ?

yeah, SNES has several non-regular lines. They are all outside of visible area. That's why i've said don't count the pixels outside of visible area
The safe counting is from end of HSync to activation of DE, i.e. left border. All other borders (top, bottom, right) may have irregular number of pixels on different retro systems.

About Minimig i cannot tell now because i've decided to rework the sync part of minimig. I want to add manual video adjustment because Amiga had no determined edges of blank. So, i will finish this part and then will tell how it works.

[Sorgelig]

@Grabulosaure,
is there a place on frame where i can switch input resolution without producing video glitch?
Some systems (for example SNES) may switch resolutions in the middle of frame. I know this is very bad thing for scaler and i don't ask for this feature. I have code in the core which will lock the resolution on beginning of frame, so scaler is guaranteed of stable resolution for the whole frame. But the moment when i switch between resolutions has video mess for 1 frames. Some games switch resolutions often, so it's distracting to see this mess often. Currently i switch resolution at beginning of VSync but still see this problem.
Is there any other place where can switch resolution smoothly?
Specifically to SNES, resolution is usually switched between 512px and 256px by simple doubling the pixels. All timings are remained the same - still have video glitches upon switch.

[Sorgelig]

New version works good with Minimig resolutions.
So, just strange bug with SNES 256x239 +HQ2x is present.
May be there are some other resolutions behave buggy but i didn't encountered them yet.

P.S.: found some more resolution giving problems with ascal. For example 1364x514 (and 1360x514) giving the same result as on picture i've posted above (Minimig). But if i increase it to 1368x514 or decrease to 1356x514 then problem disappears.

[Grabulosaure]

New version!

For example 1364x514 (and 1360x514) giving the same result as on picture i've posted above (Minimig). But if i increase it to 1368x514 or decrease to 1356x514 then problem disappears.

256 bytes bursts = 85 pixels + 1 byte. 16 bursts = 1365 pixels + 1 byte. 128 bits bus = 5 pixel + 1 byte
When the line ended exactly with a burst, the adder that skips interleaved lines wasn't used. Fixed.

is there a place on frame where i can switch input resolution without producing video glitch?

Instead of directly passing the detected input resolution to the output part "live", they are now sampled during output vsync. The last image before resolution change should be stable, particularly with double buffering.

So, just strange bug with SNES 256x239 +HQ2x is present.

I think it is due to reduced delay between DE and synchros. I've tried to add delay after HS, but it's not enough. Maybe VS ?

[Sorgelig]

New version!

256x239 in hq2x is fixed. But this version introduces right edge double pixel when "Scandoubler FX: None" and left edge double pixel with other options of Scandoubler Fx.
Update about shifting: this start to happen after i've started to use twice higher pixel clock, so 256pix now is 512pix. It's because i found some games dynamically switch 512/256 mode. So on next release SNES will have 512pix width regardless actual resolution. And in this mode i see pixel doubling on either left or right edge.
I'm investigating this issue, so don't look at this issue right now.

I think it is due to reduced delay between DE and synchros. I've tried to add delay after HS, but it's not enough. Maybe VS ?

In NTSC mode 239 visible lines is kind of extreme, so VBlank is very narrow. HBlank and HSync are normal.
May be use falling edge of VSync if you need more time at the bottom.

[Sorgelig]

256 bytes bursts = 85 pixels + 1 byte. 16 bursts = 1365 pixels + 1 byte. 128 bits bus = 5 pixel + 1 byte
When the line ended exactly with a burst, the adder that skips interleaved lines wasn't used. Fixed.

Unfortunately, not fixed. So instead of skipping lines as before, it messes the lines:

20181204_162930.jpg

And if before only in range 1360-1364 had issue, then now messed lines present in wide range of widths.

[Sorgelig]

Genesis 320pix mode, top line is shifted to the right.

[Grabulosaure]

...messed lines...

Too many changes, not enough tests. I hope this is better this time.
Pixel shifts were a part of the refactoring for changing offsets from synchros to DE. Bad interleaved mode due to not always skipping lines.
I have modified the test mode (mode = 111) to show input image parameters to ease reproduction of failures in the test bench.

Maybe there could be an experimental option that enables it, and it would only work for certain cores/screens ?

I have changed the code for synchronisation. Much simpler.
"vsync_adjust" must be enabled in mister.ini
I have posted a demo build of Genesis. When changing from "Normal" to "LowLatencySync", a resynchro event is
triggered and output image is re-aligned. (of course, "TripleBuffer" must be disabled for minimal latency)
There is a small drift, so that synchronisation only lasts for a few minutes, and it must be re-enabled after every
resolution change.

I don't have at hand screens to compare outputs, but here is a (colourised) trace from a vintage oscilloscope!

Red trace are input video lines, bottom are output, which starts after the fourth input line is displayed.

For reliable synchro, we need to find a way to compensate the drift and automatically re-trigger resynchronisation after resolution changes.
I don't know how tolerant screens are against variable input frequency or having a variable number of cycles per image.
(An alternative is to use exact frequencies and no vsync_adjust, but it is different for each resolution, each core, ...)

[Sorgelig]

I hope this is better this time.

Yeah, from my quick tests all recent problems are fixed. Minimig resolutions are fixed. Genesis top line shift is fixed.
In SNES i see top line is thinner than bottom. It can be considered a minor (non-critical) problem. In Genesis i don't observe the same problem, so it's somehow video timings specific.

Still it's possible some more problem will be discovered as more cores will migrate to ascal, so please don't leave too far

I think this scaler is reached initial milestone - congratulations!
I will make SNES next release with Ascal instead of VIP.

How about the name Scalosaure? Looks like unique

[Sorgelig]

There is a small drift, so that synchronisation only lasts for a few minutes,

Yeah, this is in general case is unavoidable. And it's in vain to explain to generic user who doesn't understand the technical details.

For reliable synchro, we need to find a way to compensate the drift and automatically re-trigger resynchronisation after resolution changes.
I don't know how tolerant screens are against variable input frequency or having a variable number of cycles per image.

Because total time of output frame is impossible to make exactly as input frame due to tolerance of PLL, there must be more tricks involved like skip/add the pixels on the end of output frame. Basically output rendering must wait exact position of input frame before start to output the next frame. This will only add more irregularities and out of HDMI standard limiting supported TVs/Monitors. So we came to the same position as it's now with VGA output and supported Monitors. The whole idea of MiSTer started exactly from this VGA problems and requirement of special monitor. So, i definitely don't want to come back to the same problem.
Though it requires more experiments. And since you are the author of scaler, you are the one who can test such re-sync in more effective way. At least you can check with your own monitor how it's surviving shorter/longer frames.
I think VSync time is the right time to hold and wait for new sync point.

What improvement i would like to see is smooth transition between input resolutions in triple buffer mode. In theory it's possible. It will require fixed buffer size per frame, so each frame will be independent inside its buffer. What do you think about this?

(An alternative is to use exact frequencies and no vsync_adjust, but it is different for each resolution, each core, ...)

Since there is no limit what output resolution can be used (and i'm not going to set such limit) it will be impossible. You cannot tweak every possible output resolution to every core.

[cacophony]

I have changed the code for synchronisation. Much simpler.
"vsync_adjust" must be enabled in mister.ini
I have posted a demo build of Genesis. When changing from "Normal" to "LowLatencySync", a resynchro event is
triggered and output image is re-aligned. (of course, "TripleBuffer" must be disabled for minimal latency)
There is a small drift, so that synchronisation only lasts for a few minutes, and it must be re-enabled after every
resolution change.

I don't have at hand screens to compare outputs, but here is a (colourised) trace from a vintage oscilloscope!

Red trace are input video lines, bottom are output, which starts after the fourth input line is displayed.

For reliable synchro, we need to find a way to compensate the drift and automatically re-trigger resynchronisation after resolution changes.
I don't know how tolerant screens are against variable input frequency or having a variable number of cycles per image.
(An alternative is to use exact frequencies and no vsync_adjust, but it is different for each resolution, each core, ...)

Thanks for the update! This latest version worked for me, and I played for about 5 minutes without issue. If there's any specific testing I could do that would be helpful let me know.

[Gamepimp]

I have a weird issue. The top (and possibly the bottom) of the screen when running the Genesis core appears to be cut off. I'm using 50% scanlines through the custom filters, although I had the same result when i used the old CRT filter at 50%. I've attached a screenshot of MiSTer (top) and of my Genesis console running through OSSC (bottom) to illustrate the missing pixels. Is there a way to configure the scaler to get the entire image to display? This is a 4K LCD TV. I've adjusted the MiSTer resolution as 720p and 1080p in the config file and the result is the same. I'm not sure if that setting is strictly for the menus or if it affects the cores themselves. Any help on this would be greatly appreciated. I suspect that I'm having issues with other Genesis games and possibly other cores as well although I haven't had a chance to do additional testing.

MiSTer.jpg

OSSC.jpg