Scaler

[Sorgelig]

Another version !

new version is much easier to use.
As i guess now can use any address of framebuffer divisible by 256?

[Sorgelig]

It seems more common color positions is when B least bits, then G then R in highest bits. So, opposite to current format. At least some linux graphic libraries expect these positions of colors.
It would be good to have a signal for swapping R/B components in frame buffer.

[Sorgelig]

@Grabulosaure:
i've added changes to Ascal for R/B swapping in Menu_MiSTer repository.
You can accept my changes or make your own. Up to you.

[Grabulosaure]

i've added changes to Ascal for R/B swapping in Menu_MiSTer repository.
You can accept my changes or make your own. Up to you.

Is it really useful to be able to choose the order?
And RGB565 seems a bit more common than RGB555. And there is one extra bit of green paint!

[Sorgelig]

New menu look:

20190524_064111.jpg

[Sorgelig]

i've added changes to Ascal for R/B swapping in Menu_MiSTer repository.
You can accept my changes or make your own. Up to you.

Is it really useful to be able to choose the order?
And RGB565 seems a bit more common than RGB555. And there is one extra bit of green paint!

It's better to have a choice so both orders can be used in case. My FB driver accepts both orders, so it can be changed on the fly.
565 is also good and can be added. There is one format number is unused.
I found that 32bit format is pretty much fast, so i use it now. 565/555 can be used if higher performance will be required.

[Sorgelig]

There is strange issue with new Menu. My monitor refuses to accept the video if i put new Menu core in startup. However if i use old version of Menu first - monitor start to display the video, and then i can use new Menu as much as i want. I can reboot - no problem. It works till i power off the MiSTer. With next power On i have to use old Menu core again to initialize the video.
My first suspect was added hdmi_limited option. But reverting it didn't help. So, the only suspect now is Scaler. Old Menu core didn't use the scaler...
Weird problem.

[JamesF]

Same here, new ascal menu will not turn on my pc monitor after power on.
Usually the pc monitor turns on when there is a signal.

I also see some pixel shift on the OSD font when using the new ascal menu, that was not present on the old menu.

[Sorgelig]

further investigation shown that pll_hdmi_adj is guilty in HDMI initialization problem.
Somehow it interfere with ADV7513 configuration. Once i set llena = 0; lltune = 0; i've got Menu core working. Even standard disable lowlat mode from HPS side doesn't prevent the problem. It's not a problem to disable pll_hdmi_adj in Menu explicitly, but it shows that any ADV7513 config from other cores is simply ignored. Probably pll_hdmi_adj should wait i2c bus activity to finish before issue any HDMI frequency configuration.

P.S.: somehow lltune bus affects this problem. So i have to set lltune = 0 to make ADV7513 config to work.

[Grabulosaure]

further investigation shown that pll_hdmi_adj is guilty in HDMI initialization problem.
Somehow it interfere with ADV7513 configuration. Once i set llena = 0; lltune = 0; i've got Menu core working. Even standard disable lowlat mode from HPS side doesn't prevent the problem. It's not a problem to disable pll_hdmi_adj in Menu explicitly, but it shows that any ADV7513 config from other cores is simply ignored. Probably pll_hdmi_adj should wait i2c bus activity to finish before issue any HDMI frequency configuration.

P.S.: somehow lltune bus affects this problem. So i have to set lltune = 0 to make ADV7513 config to work.

I won't be at home this WE and won't be able to test. Sorry. I'll look at the code though.

It's strange that llena=0 doesn't completely passivate PLL_ADJ.
The ADV7513 PLL tuning during HDMI initialisation probably doesn't like having an irregular input clock.
One day I'll revise again that PLL stuff, but I've tried so many times...

[Sorgelig]

I won't be at home this WE and won't be able to test. Sorry. I'll look at the code though.

It's strange that llena=0 doesn't completely passivate PLL_ADJ.
The ADV7513 PLL tuning during HDMI initialisation probably doesn't like having an irregular input clock.
One day I'll revise again that PLL stuff, but I've tried so many times...

I've pushed the fix to Menu repository. May be you can just check if it can interfere the vsync_adjust function or not.

[Sorgelig]

It seems SCL on I2C bus for ADV7513 is not really clock. The real clock is HDMI clock, and then internal i2c block just parses the stream from both SCL and SDA as pure data. So, stable HDMI clock frequency is a key to decode i2c properly.

[Sorgelig]

Just thought: we are very close to HPS OSD implementation. If you can make rendering HPS buffer over the core video with alpha channel (32bit RGBA color) then i will move OSD to HPS side. Then more fancy OSD will be possible.
To save resources and bandwidth It's possible to simplify some parts. For example HPS buffer can be restricted to integer-only magnification NN-only. It's also ok to limit max HPS buffer resolution to 1280x720 (960x540 can be used for 1920x1080).

[BBond007]

Just thought: we are very close to HPS OSD implementation. If you can make rendering HPS buffer over the core video with alpha channel (32bit RGBA color) then i will move OSD to HPS side. Then more fancy OSD will be possible.
To save resources and bandwidth It's possible to simplify some parts. For example HPS buffer can be restricted to integer-only magnification NN-only. It's also ok to limit max HPS buffer resolution to 1280x720 (960x540 can be used for 1920x1080).

Would the OSD still work on the RGB 15 pin or is this the point where RGB is depreciated? Maybe with 'vga_scaler=1'? I know you have always said that the RGB output is for developers and standard MiSTer output is HDMI. Definitely not complaining, I'm just curious....

[Sorgelig]

yeah.. I always forget about VGA output... VGA going to have a problems.. vga_scaler can solve this but i guess purists won't like it.

[Sorgelig]

Another idea: implement 256 color mode. Palette can be located before the frame buffer.
I'm just thinking it may be useful for Lunux applications. Probably some emulators may get advantage - and the framebuffer operations will be very fast, so absence of GPU won't hit as much as on hi/true color buffers.
I didn't explore it yet, but probably even linux console may be compatible with this mode. So it may save a lot of DDR bandwidth.
About bnadwidth: i think i found the way to hit the limit With 1920x1080x32 frame buffer if i open MC and then find some long directory then press and keep the enter, so MC will quickly switch between folders - i see screen sometimes broke to pieces. Not a big problem, but just see where is the limit.

[kitrinx]

yeah.. I always forget about VGA output... VGA going to have a problems.. vga_scaler can solve this but i guess purists won't like it.

This is a pretty important detail.

I think at this point we can't consider getting rid of a menu on VGA, people use this in arcade cabinets and other things that depend on it. Native RGB is a big bullet point for MiSTer enthusiasts, so I think it would be bad to force VGA scalar all the time too. So how can we deal with this? Switch to VGA scalar only when OSD is opened maybe, CRT should be able to adapt without issue, but how does it get the resolution right? Can VGA have a separate resolution? Maybe also possible to re-draw the HDMI framebuffer to a secondary framebuffer at 240p resolution, and make the OSD take full screen on VGA. It might be distorted and sounds like too much resource usage though.

A better UI is important to make MiSTer easier to use, and maintaining two separate menu/UI systems doesn't seem like it will work in the long run either.

[Sorgelig]

Having 2 separate scalers is very bad idea - it will consume to much resources. So when you use vga_scaler=1 it implies you don't need HDMI. You still can use both VGA and HDMI with scaler if output resolution is the same and both displays support it.

Scaler supports very low resolutions and slow pixel clocks. You can see TV-friendly resolution is listed in Gameboy core readme. So, it's possible to temporary switch to scaler output when OSD is active. Usually CRT instantly catches new resolution, so it won't be a problem to switch between 2 resolutions. Probably still can maintain the current OSD for VGA only. I don't plan to re-design the OSD data. If Scaler will be able to blend the FB onto core video, then it will have better looking menu while the OSD data from core will remain the same. So it should be compatible with both OSD systems.

[kitrinx]

Having 2 separate scalers is very bad idea - it will consume to much resources. So when you use vga_scaler=1 it implies you don't need HDMI. You still can use both VGA and HDMI with scaler if output resolution is the same and both displays support it.

Scaler supports very low resolutions and slow pixel clocks. You can see TV-friendly resolution is listed in Gameboy core readme. So, it's possible to temporary switch to scaler output when OSD is active. Usually CRT instantly catches new resolution, so it won't be a problem to switch between 2 resolutions. Probably still can maintain the current OSD for VGA only. I don't plan to re-design the OSD data. If Scaler will be able to blend the FB onto core video, then it will have better looking menu while the OSD data from core will remain the same. So it should be compatible with both OSD systems.

I think someday it would be good to have OSD widgets like sliders and number pickers. There are many things that could benefit by such a setting, like volume mixing adjustments, screen sizing, and other things of this nature. Maybe for now maintaining is both is okay, but I could see it becoming a limitation in the future. Maybe not. You know this system much better than me, so if you think maintaining both isn't a problem, then that's okay by me.

[Sorgelig]

If at some point maintaining both versions will be impossible then temporary switch to scaler output will be mandatory.

[Sorgelig]

Ok. First release with frame buffer.
It also includes fbv picture viewer.

[BBond007]

Ok. First release with frame buffer.
It also includes fbv picture viewer.

How do you use the fbv picture viewer?

I was attempting to use it via SSH:

# fbv /media/fat/PICS/test.png

Code: Select all

fbv - The Framebuffer Viewer
/media/fat/PICS/test.png
1275 x 716

Thanks!

[Sorgelig]

or:

Code: Select all

fbv -fer /media/fat/screenshots/SNES/*

[BBond007]

or:

Code: Select all

fbv -fer /media/fat/screenshots/SNES/*

That should work over SSH when running 'menu.rbf' core? I'm not seeing it do anything

The new F1 backgrounds do work though...

Thanks!

[Sorgelig]

you need to switch to HPS frame buffer to see the pic. F9