Scaler

https://github.com/MiSTer-devel/Main_MiSTer/wiki

Moderators: Mug UK, Zorro 2, Greenious, spiny, Sorgelig, Moderator Team

JamesF
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 104
Joined: Sat Dec 15, 2018 6:46 am

Re: Scaler

Postby JamesF » Mon Jan 28, 2019 8:15 am

I think Grabulosaure did not want to bother you with a small fix when he had a big update coming.

marqs
Atarian
Atarian
Posts: 2
Joined: Mon Jan 28, 2019 8:17 pm

Re: Scaler

Postby marqs » Mon Jan 28, 2019 8:35 pm

Looking back at the discussion on PLLs and vsync_adjust got me thinking if anybody has thought about using an external PLL instead of playing around with Cyclone V PLL which is not able to generate ideal output video clock with 0ppm error in general case? I have a breakout board for SI5351C-B clock generator (which I've used in cps2_digiav project) that should be a good fit (10-100MHz input, up to 200MHz output) here as well. I'm planning to hook it to De10-Nano GPIO and recompiling some core with fixed video clock (for starters to keep things simple) and see how it works out.

bitfan2011
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 108
Joined: Sat Dec 29, 2018 5:46 pm

Re: Scaler

Postby bitfan2011 » Mon Jan 28, 2019 11:12 pm

i'm not sure if this is related, but i seem to have a number of cores which stopped working over HDMI sometime during recent updates. all i get over HDMI is crazy digital garbage now :[

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4618
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Tue Jan 29, 2019 4:59 am

marqs wrote:Looking back at the discussion on PLLs and vsync_adjust got me thinking if anybody has thought about using an external PLL instead of playing around with Cyclone V PLL which is not able to generate ideal output video clock with 0ppm error in general case? I have a breakout board for SI5351C-B clock generator (which I've used in cps2_digiav project) that should be a good fit (10-100MHz input, up to 200MHz output) here as well. I'm planning to hook it to De10-Nano GPIO and recompiling some core with fixed video clock (for starters to keep things simple) and see how it works out.

Completely wrong and unneeded solution.
Besides that, try to feed 150Mhz clock from external - will laugh together ;)

marqs
Atarian
Atarian
Posts: 2
Joined: Mon Jan 28, 2019 8:17 pm

Re: Scaler

Postby marqs » Tue Jan 29, 2019 8:23 am

Sorgelig wrote:Completely wrong and unneeded solution.
Besides that, try to feed 150Mhz clock from external - will laugh together ;)
So you think De10-Nano PCB layout is not good enough for 150MHz from GPIO even in differential mode? That may well be the case (which is why said to test how it works out), but you could always input e.g. divide-by-4 clock and multiply it with Cyclone V PLL. As for the extenal solution not being needed, could you elaborate a bit why - are you able to generate output video clock with 0ppm error with Cyclone V itself? Continuous pixel clock or emulation speed adjustment don't sound very clean solutions to me - I'm not saying an extenal PLL would be ideal solution either but at least that could provide the clock with the needed exact ratio.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4618
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Tue Jan 29, 2019 9:25 am

marqs wrote:
Sorgelig wrote:Completely wrong and unneeded solution.
Besides that, try to feed 150Mhz clock from external - will laugh together ;)
So you think De10-Nano PCB layout is not good enough for 150MHz from GPIO even in differential mode? That may well be the case (which is why said to test how it works out), but you could always input e.g. divide-by-4 clock and multiply it with Cyclone V PLL. As for the extenal solution not being needed, could you elaborate a bit why - are you able to generate output video clock with 0ppm error with Cyclone V itself? Continuous pixel clock or emulation speed adjustment don't sound very clean solutions to me - I'm not saying an extenal PLL would be ideal solution either but at least that could provide the clock with the needed exact ratio.

Everything can be made with internal PLL.
Probably you don't understand the problem in details. In general case you cannot have 2 large periods of time (frame time) with different clocks with 100% match as there is no ideal things exist in the life. It's always come to how precise you measure, then how precise you set the PLL. Not always 2 numbers can be divided without remain. Divide 1 by 3 for example. External PLL won't give any advantage to existing solution with internal PLL.

JamesF
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 104
Joined: Sat Dec 15, 2018 6:46 am

Re: Scaler

Postby JamesF » Tue Jan 29, 2019 10:15 am

marqs is the creator of the OSSC.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4618
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Tue Jan 29, 2019 10:21 am

JamesF wrote:marqs is the creator of the OSSC.

ok. My post above is still valid.
If i remember correct, OSSC operates only with standard HDMI resolutions and clocks.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4618
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Tue Jan 29, 2019 10:53 am

marqs wrote:So you think De10-Nano PCB layout is not good enough for 150MHz from GPIO even in differential mode?

The GPIO connectors on DE10-nano are considered low frequency unbalanced and non-diffrential. Something like for up to 60Mhz. Feeding differential clock to pins which has unknown routing to FPGA i think useless and can give negative effect than single wire clock.
Yeah, SDRAM works up to 167MHz which is more a luck than expected.
It's just for a record. There is no reason to use external PLL as internal one can do the job.

ijor
Hardware Guru
Hardware Guru
Posts: 3781
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Scaler

Postby ijor » Tue Jan 29, 2019 7:02 pm

marqs wrote:Looking back at the discussion on PLLs and vsync_adjust got me thinking if anybody has thought about using an external PLL instead of playing around with Cyclone V PLL which is not able to generate ideal output video clock with 0ppm error in general case? I have a breakout board for SI5351C-B clock generator (which I've used in cps2_digiav project) that should be a good fit (10-100MHz input, up to 200MHz output) here as well. I'm planning to hook it to De10-Nano GPIO and recompiling some core with fixed video clock (for starters to keep things simple) and see how it works out.


As Sorgelig pointed out, the Nano GPIO is not the ideal interface for a clock. Other Terasic boards have a SMA connector specifically for clocking, but unfortunately only the older ones. It might still work at a slower frequency and then multiplying with an internal PLL. But to be really useful, the external synthesizer would need to support arbitrary fractions with probably something like a 22 bits divisor and multiplier. I'm not sure is that worth, but it would be interesting to test.

Btw, the nano actually has a clock synthesizer. But it is not user programmable. Anyway, welcome to the forum :)
Fx Cast: Atari St cycle accurate fpga core

ijor
Hardware Guru
Hardware Guru
Posts: 3781
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Scaler

Postby ijor » Tue Jan 29, 2019 7:09 pm

Sorgelig wrote:Everything can be made with internal PLL.
Probably you don't understand the problem in details. In general case you cannot have 2 large periods of time (frame time) with different clocks with 100% match as there is no ideal things exist in the life. It's always come to how precise you measure, then how precise you set the PLL. Not always 2 numbers can be divided without remain. Divide 1 by 3 for example. External PLL won't give any advantage to existing solution with internal PLL.


If the PLL supports fractional mode with enough resolution, the quotient being periodic is not important. You can configure a PLL to perform a fractional multiplication and division and it will lock perfectly with modulation. It will have jitter of course, but in this case we don't care too much about jitter because we don't need to synchronize at the cycle level. We only care if it would maintain the fractional ratio on the average, and a high quality fractional PLL can do that with absolute precision. The only problem is that we need a rather long denominator and multiplier to include the total number of cycles per frame.
Fx Cast: Atari St cycle accurate fpga core

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4618
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Wed Jan 30, 2019 1:08 am

ijor wrote:The only problem is that we need a rather long denominator and multiplier to include the total number of cycles per frame.

but PLL doesn't work with such parameters. It needs integer and fractional parts. And in general case fractional is not finite. Actually we need a loop where output cycles per frame will maintain relation to input cycles per frame.
Probably periodic slight adjust of fractional part may work, but it needs experimenting.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4618
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Thu Jan 31, 2019 3:30 am

Grabulosaure wrote:The hardware, both the FPGA and HDMI encoder, can barely reach 200MHz (which is far better than expected, and beyond the datasheet specs.). Mister software enforces 200MHz as max. freq.

I will extend the limits to unreachable values.
In the meantime new ascal has problem with rotated video in Donkey Kong arcade:
Arcade-DonkeyKong_MiSTer.zip

This is updated sources with ascal.
Right most char column is wrong. Some of older ascal version works well, so the problem is in ascal.
You do not have the required permissions to view the files attached to this post.

ijor
Hardware Guru
Hardware Guru
Posts: 3781
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Scaler

Postby ijor » Thu Jan 31, 2019 4:38 am

Sorgelig wrote:but PLL doesn't work with such parameters. It needs integer and fractional parts. And in general case fractional is not finite.


That's why I said it needs to support an arbitrary fraction with enough resolution. Not sure if such a PLL exists, but it seems to me that at least in theory, it should be possible.

Actually we need a loop where output cycles per frame will maintain relation to input cycles per frame. Probably periodic slight adjust of fractional part may work, but it needs experimenting.


That's essentially what a fractional PLL performs internally. But it does it with micro (pico) adjustments on every cycle. Not sure if "macro" adjustments would work. There is risk that the PLL would lose lock or provoke glitches. And there is also a risk that the monitor itself has its own PLL that might lose lock as well, as a consequence. It would be interesting to try nevertheless.
Fx Cast: Atari St cycle accurate fpga core

Grabulosaure
Atari maniac
Atari maniac
Posts: 89
Joined: Tue Sep 05, 2017 9:35 pm
Contact:

Re: Scaler

Postby Grabulosaure » Thu Jan 31, 2019 8:05 am

Sorgelig wrote:
Grabulosaure wrote:The hardware, both the FPGA and HDMI encoder, can barely reach 200MHz (which is far better than expected, and beyond the datasheet specs.). Mister software enforces 200MHz as max. freq.

I will extend the limits to unreachable values.
In the meantime new ascal has problem with rotated video in Donkey Kong arcade:
Arcade-DonkeyKong_MiSTer.zip
This is updated sources with ascal.
Right most char column is wrong. Some of older ascal version works well, so the problem is in ascal.


I will look. Sorry.
I have made many changes since the last version on temlib.org, which wasn't quite ready anyway.

The few tests I made beyond 200MHz showed "ungraceful" degradation. I expected more and more noise and jitter, it instead freezes the image, or goes blank, which makes difficult any evaluation of practical max. freq.

For me there is no real issue with the Altera PLL which is remarkably tolerant to the continuous tuning in low lag mode. My "problem" is minimising the lock time or find a way to have stable images (=very slow transitions), as some games change video modes often, or toggle interlaced mode, and that disturbs the PLL.

JamesF
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 104
Joined: Sat Dec 15, 2018 6:46 am

Re: Scaler

Postby JamesF » Thu Jan 31, 2019 8:23 am

Grabulosaure wrote:For me there is no real issue with the Altera PLL which is remarkably tolerant to the continuous tuning in low lag mode. My "problem" is minimising the lock time or find a way to have stable images (=very slow transitions), as some games change video modes often, or toggle interlaced mode, and that disturbs the PLL.


Mortal Kombat 3 on the Genesis changes between 320x224 and 256x224 almost every screen, just let the demo run indefinitely.
It wreaks havoc on the OSSC's PLL which may lock immediately or take a few milliseconds,, if the latter, the display will lose sync.

I don't mind some tearing during the "slow" phase synchronization as long as the display doesn't lose sync, but will eventually synchronize.
Maybe it would be useful to have both slow and fast methods available to choose, at least for the test build so people can report their findings on various displays?

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4618
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Thu Jan 31, 2019 8:53 am

Upcoming release of Genesis won't change the timings between 320px and 256px.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4618
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Thu Jan 31, 2019 8:57 am

Grabulosaure wrote:I will look. Sorry.
I have made many changes since the last version on temlib.org, which wasn't quite ready anyway.

if you want to test some changes, then it would be good to test it with me. I don't mind to spend as much time as it needs. Scaler is important system component so i'm glad to spend the time for testing and know what is happening.

By the way, is it possible for Ascal to accept this:
Most arcades have rotated screen, so my screen_rotate module waits till frame is filled and quickly push the whole frame to the scaler. It can be at 4x or even 8x speed. This reduces the unneeded latency. After push the frame the VSync is keeping active till the next frame. So, the frame rate is equal to original frame. This was working with VIP scaler but unfortunately doesn't work with Ascal.
You can set DOUBLING parameter to 0 in Donkey Kong to see this in action.

User avatar
kitrinx
Captain Atari
Captain Atari
Posts: 151
Joined: Wed Sep 26, 2018 6:03 am

Re: Scaler

Postby kitrinx » Thu Jan 31, 2019 5:54 pm

Sorgelig wrote:If i remember correct, OSSC operates only with standard HDMI resolutions and clocks.

Maybe you are thinking of Framemeister. OSSC works with many off-spec resolutions and clocks.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4618
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Fri Feb 01, 2019 4:07 am

kitrinx wrote:
Sorgelig wrote:If i remember correct, OSSC operates only with standard HDMI resolutions and clocks.

Maybe you are thinking of Framemeister. OSSC works with many off-spec resolutions and clocks.

Last time i've used OSSC was more than 2 years ago. So, probably it's more flexible now.

JamesF
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 104
Joined: Sat Dec 15, 2018 6:46 am

Re: Scaler

Postby JamesF » Sun Feb 10, 2019 12:49 pm

ASCAL scaler updated.

Grabulosaure
Atari maniac
Atari maniac
Posts: 89
Joined: Tue Sep 05, 2017 9:35 pm
Contact:

Re: Scaler

Postby Grabulosaure » Sun Feb 10, 2019 1:02 pm

JamesF wrote:ASCAL scaler updated.

AFAIK some arcade cores are about to be released, and they may benefit from the fixes to screen_rotation.

Grabulosaure
Atari maniac
Atari maniac
Posts: 89
Joined: Tue Sep 05, 2017 9:35 pm
Contact:

Scaler

Postby Grabulosaure » Sun Feb 10, 2019 1:26 pm

Changes in january version :
- ASCAL : Fixed rightmost line for some input resolutions (C64, Minimig)
- ASCAL : Fixed downscaling offset
- ASCAL : Half-frame updates of interleaved vided (50-60Hz instead of 25-30Hz output)
- ASCAL : Fixed image properties header writes. Updated content. Change endianness.
- ASCAL : removed debug.
- HDMI_PLL_ADJ : Support updates of multiplier register

Changes in current version :
- ASCAL : Support shorter horizontal blanking, use DE instead of HS (screen_rotate for arcades)
- HDMI_PLL_ADJ : Updated.

What remains to do:
- More non-regression tests.
- Low lag mode. Again.
- I have tried some tweaks in the phase and to rounding, for better image quality, but the results are not really convincing.

Notes:
- I have moved all image sizing code from ASCAL to HDMI_PLL_ADJ. They must be updated together. The o_lltune signal must be connected in sys_top.v for the low-lag mode to work.

- Various off-by-one and pipelining bugs triggered the extra line on the right on AMIGA and C64.

- The low lag mode stilll uses the older method (The version with exact serlai multiplier/divider is temperamental).
The Altera PLL reacts nicely to continuous small adjustments, there is IMHO no need of an external component.
All attempts of slow transitions for seamless mode changes have failed with my screen, but, as reported by paulbnl :
paulbnl wrote:I have done some tweaking on the minimum off_v & ofp_v values on lines 126,128 of pll_hdmi_adj.vhd and with off_v at 8 and ofp_v at 7 both my TV and monitor don't lose sync when loading a rom.

...in the SNES thread, some screens may better support slow changes (I can add an input to pll_adj for a slow mode).

- Half frame refresh now uses independent triple-buffer pointers for half frames in interlaced mode. Each output image is composed
from the latest two completed input half-fields.

- The image properties header insertion was fixed and storage format was changed to ease access from the ARM side (endianness).

- The problem with screen_rotate was principally the horizontal sync duration from screen_rotate.v: 4 cycles.
Pixels are pushed in a shift register then copied to a buffer 128 bits at a time.
At the end of each line, pixels still in the shift register need to be copied as well, which can take a few additional cycles (up to 6 cycles actually to shift out). The worst case is when these stray pixels need a new burst to the Avalon bus.
Because of the asynchronous clocks between Avalon and input video, some delay is put between consecutive writes to allow proper resynchronisation. And then counters are reset to prepare for the next line. And then a divider calculates the vertical phase for downscaling...

I have optimised that part, but it still needs more than 4 cycles. So screen_rotate need to be changed.
(btw, screen_rotate has a 2 cycles offset between pixel data and the HS/VS/DE signals and the first line is shorter by one clock cycle)

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4618
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Sun Feb 10, 2019 4:20 pm

Thanks for update!

Grabulosaure wrote:I have optimised that part, but it still needs more than 4 cycles. So screen_rotate need to be changed.
(btw, screen_rotate has a 2 cycles offset between pixel data and the HS/VS/DE signals and the first line is shorter by one clock cycle)

How many blank pixels scaler needs to guarantee a smooth transition between lines? There are much less blank lines than horizontal blank pixels, so after rotation i need to be careful not to use too much extra horizontal blanking to not make the output frame longer than input.
There is another problem in rotation, Scaler displays the line at the bottom from buffer outside the real buffer. As a result it displays garbage from previous core there. As a workaround i've updated the Menu core to clean the frame buffer, so next core will get a blank buffer at launch.

JamesF
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 104
Joined: Sat Dec 15, 2018 6:46 am

Re: Scaler

Postby JamesF » Mon Feb 11, 2019 6:27 am

Grabulosaure wrote:some screens may better support slow changes (I can add an input to pll_adj for a slow mode).

That would be interesting to test.


Return to “MiSTer”

Who is online

Users browsing this forum: No registered users and 6 guests