Scaler

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

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

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

Re: Scaler

Postby Grabulosaure » Mon May 20, 2019 1:05 am

So, new version :
- Framebuffer address as "avl_base" signal. Updates taken into account after Vsync falling edge.
- Programmable colour depth "format" signal. 0=16bpp R5G5B5, 1=24bpp, 2=32bits RGB0.
I hope that byte order matches standards. Of course the screen-shooter will need to be updated. In the header, byte[1]=format.
Demo version and diff of Genesis/Megadrive (with selectable pix. format).

Anything to add?

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5106
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Mon May 20, 2019 1:26 am

Grabulosaure wrote:So, new version :
- Framebuffer address as "avl_base" signal. Updates taken into account after Vsync falling edge.
- Programmable colour depth "format" signal. 0=16bpp R5G5B5, 1=24bpp, 2=32bits RGB0.
I hope that byte order matches standards. Of course the screen-shooter will need to be updated. In the header, byte[1]=format.
Demo version and diff of Genesis/Megadrive (with selectable pix. format).

Anything to add?

Thanks!
From first sight the features are enough. There is one possible problem i see: the switch between core video and framebuffer should also be synchronous with other signals used in such transition. For example freeze should also be latched on vsync (and vimax/himax/iauto i think). It needs to prevent the scaler from filling the HPS framebuffer by core's video before new base address will be latched by scaler.

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

Re: Scaler

Postby Grabulosaure » Mon May 20, 2019 2:01 am

Sorgelig wrote:
Grabulosaure wrote:So, new version :
- Framebuffer address as "avl_base" signal. Updates taken into account after Vsync falling edge.
- Programmable colour depth "format" signal. 0=16bpp R5G5B5, 1=24bpp, 2=32bits RGB0.
I hope that byte order matches standards. Of course the screen-shooter will need to be updated. In the header, byte[1]=format.
Demo version and diff of Genesis/Megadrive (with selectable pix. format).

Anything to add?

Thanks!
From first sight the features are enough. There is one possible problem i see: the switch between core video and framebuffer should also be synchronous with other signals used in such transition. For example freeze should also be latched on vsync (and vimax/himax/iauto i think). It needs to prevent the scaler from filling the HPS framebuffer by core's video before new base address will be latched by scaler.


Resolution changes can be delayed until end of frame to allow that the last frame is fully updated, but if there is no guarantee of an input image, one cannot wait for the input Vsync.
Currently freeze should be set before changing the address.
The scaler isn't really able to do seamless transitions between video resolutions, particularly with interlaced video.

Oh, I also forgot that PLL lock must also be disabled if there is no input image...

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5106
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Mon May 20, 2019 4:52 am

i think this:

Code: Select all

avl_radrs <=o_adrs AND (avl_size - 1); -- <ASYNC>

can be safely changed to:

Code: Select all

avl_radrs <=o_adrs; -- <ASYNC>

Reading is safe and won't require to set the size of buffer for framebuffer mode.

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5106
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Mon May 20, 2019 9:58 am

Grabulosaure wrote:(note that in this mode, the scaler cannot downscale)

Is it hard to add downscaling for framebuffer mode? I see a problem here. Without ability to downscale it will be limited to minimum possible HDMI resolution like 640x480 (or even less). While it possible to make framebuffer resizable, it will be hard to manage it.

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5106
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Mon May 20, 2019 2:30 pm

I'm trying to make framebuffer mode but it seems something wrong with scaler. Or may be i doing something wrong..
I've updated Genesis sources with new scaler and FB mode. Also updated the Main with FB support. To switch to FB mode, load Genesis core and open the OSD menu. And then in OSD press F9. It will toggle to FB mode where you supposed to see horizontal color bars with transition from black to max color. But lines are messed.

Locutus73
Captain Atari
Captain Atari
Posts: 489
Joined: Wed Feb 07, 2018 6:13 pm

Re: Scaler

Postby Locutus73 » Mon May 20, 2019 6:24 pm

Sorgelig wrote:This can lead to a whole new experience which i even didn't fully realise yet :)

Sorry if I intrude in a scaler thread for devs... but having this and the audio buffer, if we hack a SDL2 implementation using both, couldn't we port something like EmulationStation frontend to MiSTer?
Image
Wouldn't it be nice?

Regards.

Locutus73

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5106
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Mon May 20, 2019 6:31 pm

Locutus73 wrote:Wouldn't it be nice?

nope.

Locutus73
Captain Atari
Captain Atari
Posts: 489
Joined: Wed Feb 07, 2018 6:13 pm

Re: Scaler

Postby Locutus73 » Mon May 20, 2019 7:08 pm

Sorgelig wrote:
Locutus73 wrote:Wouldn't it be nice?

nope.

Maybe main MiSTer, just after loading a core, could search for an image with the internal core name in /media/fat/splash and, when found, it would show it for few seconds. So we could have splash screens with the platform logo and an user prompt for hitting F12.

Then if the users doesn’t hit F12 for 30 seconds MiSTer could play a Rick Roll video


:lol:

Ok, Rick Roll apart the splash screen seems a good application to me.

Regards.

Locutus73


BBond007
Captain Atari
Captain Atari
Posts: 385
Joined: Wed Feb 28, 2018 3:23 am

Re: Scaler

Postby BBond007 » Mon May 20, 2019 9:11 pm

Locutus73 wrote:
Sorgelig wrote:This can lead to a whole new experience which i even didn't fully realise yet :)

Sorry if I intrude in a scaler thread for devs... but having this and the audio buffer, if we hack a SDL2 implementation using both, couldn't we port something like EmulationStation frontend to MiSTer?


I do like the idea of the SDL2 implementation for the purpose of running ScummVM (https://www.scummvm.org) on the ARM.

I don't like the EmulationStation front-end idea at all, but that is just my opinion.
Last edited by BBond007 on Tue May 21, 2019 4:19 am, edited 1 time in total.

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

Re: Scaler

Postby Grabulosaure » Tue May 21, 2019 1:37 am

Sorgelig wrote:I'm trying to make framebuffer mode but it seems something wrong with scaler. Or may be i doing something wrong..
I've updated Genesis sources with new scaler and FB mode. Also updated the Main with FB support. To switch to FB mode, load Genesis core and open the OSD menu. And then in OSD press F9. It will toggle to FB mode where you supposed to see horizontal color bars with transition from black to max color. But lines are messed.

Some fixes.
- I have posted a new version of ASCAL with some fixes to 16 and 32 bpp modes. I have also changed bit order of 16bpp for compatibility with ARM side.
- How to draw on the framebuffer (see main_mister.diff):
* Each line occupies in memory a multiple of the burst length (N_BURST=256 bytes, available in the header). It can be calculated as :
((IMAGE_WIDTH * number_of_bytes_per_pixel + N_BURST - 1) / N_BURST) * N_BURST
* When the header is enabled, the framebuffer start address has a N_BURST offset.
* The values of ihmax / ivmax shall be set to the last pixel position, not the size, e.g. 639x399 instead of 640x400.

I'll try to do more non-regression tests and code cleanup.

Handling downscaling with interpolation in the framebuffer mode is not simple, because of memory fetch issues. As an alternative, I have some still unfinished avalon framebuffer, made from pieces of ASCAL and other stuff, and it could be used both upstream from the scaler as a full screen framebuffer or downstream to do the OSD. A separate block could eventually include simple acceleration features (bitblt).

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5106
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Tue May 21, 2019 5:56 am

Grabulosaure wrote:Some fixes.

Thanks for fixes. I've pushed the fixes to Genesis and Main.
While it works, it still has issues while transition to frame buffer and back. Often i see how core's video pushed to HPS frame buffer. And it's hard to avoid it. The output render of scaler switches the base address on output VSync while input part is controlled by input VSync. Please revise my Genesis code - may be you can handle the transition better. I would like to avoid HPS frame buffer corruption because i don't plan to re-draw it between switches. How about add 2 bases to ASCAL? One will be dedicated video input from core, so whatever happened there will be locked to core's framebuffer. Another base will be dedicated to HPS. Basically scaler just need to switch the output part between these bases. The input part may continue to receive and draw the core's video - probably even freeze is not required in this case. Since only output part will jump between bases - it will be safe for both buffers.
With 2 bases, the base for core can be put to generic as it was before.

alanswx
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 142
Joined: Sat Nov 25, 2017 4:34 pm

Re: Scaler

Postby alanswx » Tue May 21, 2019 6:17 pm

Sorgelig wrote:
Grabulosaure wrote:Some fixes.

Thanks for fixes. I've pushed the fixes to Genesis and Main.
While it works, it still has issues while transition to frame buffer and back. Often i see how core's video pushed to HPS frame buffer. And it's hard to avoid it. The output render of scaler switches the base address on output VSync while input part is controlled by input VSync. Please revise my Genesis code - may be you can handle the transition better. I would like to avoid HPS frame buffer corruption because i don't plan to re-draw it between switches. How about add 2 bases to ASCAL? One will be dedicated video input from core, so whatever happened there will be locked to core's framebuffer. Another base will be dedicated to HPS. Basically scaler just need to switch the output part between these bases. The input part may continue to receive and draw the core's video - probably even freeze is not required in this case. Since only output part will jump between bases - it will be safe for both buffers.
With 2 bases, the base for core can be put to generic as it was before.


If there is a second base, then we can make a linux framebuffer driver, and point it at the second base, and keep it there.

alanswx
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 142
Joined: Sat Nov 25, 2017 4:34 pm

Re: Scaler

Postby alanswx » Tue May 21, 2019 6:17 pm

alanswx wrote:
Sorgelig wrote:
Grabulosaure wrote:Some fixes.

Thanks for fixes. I've pushed the fixes to Genesis and Main.
While it works, it still has issues while transition to frame buffer and back. Often i see how core's video pushed to HPS frame buffer. And it's hard to avoid it. The output render of scaler switches the base address on output VSync while input part is controlled by input VSync. Please revise my Genesis code - may be you can handle the transition better. I would like to avoid HPS frame buffer corruption because i don't plan to re-draw it between switches. How about add 2 bases to ASCAL? One will be dedicated video input from core, so whatever happened there will be locked to core's framebuffer. Another base will be dedicated to HPS. Basically scaler just need to switch the output part between these bases. The input part may continue to receive and draw the core's video - probably even freeze is not required in this case. Since only output part will jump between bases - it will be safe for both buffers.
With 2 bases, the base for core can be put to generic as it was before.


If there is a second base, then we can make a linux framebuffer driver, and point it at the second base, and keep it there.


Or maybe the HPS can write the new base address.

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5106
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Tue May 21, 2019 7:51 pm

@Grabulosaure,

Having 256 header in the beginning making the frame buffer incompatible with linux system. It needs page aligned buffer, so starting from +256 breaks the compatibility (or at least making it hard to workaround). At the same time scaler doesn't allow to set arbitrary offset for buffer. So i cannot set the framebuffer with -256 offset to leave the 256 header in previous page. And i cannot simply disable the header as it needed for core's video to be able to make screenshot.
Header must be removed from frame buffer mode. I think HEADER should be moved from generic to port.

alanswx wrote:If there is a second base, then we can make a linux framebuffer driver, and point it at the second base, and keep it there.

It has no relation at all. i can make linux frame buffer with current version.

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5106
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Tue May 21, 2019 10:35 pm

something already works:
20190522_062528.jpg

colors are wrong, but should be easily fixed.

There is another problem arises: linux framebuffer allows to change the resolution but doesn't allow to change the stride (line length in bytes). Originally i've planned to make dynamic resolution for framebuffer depending on HDMI resolution so it won't be distorted by scaling. Is it possible to fix the line length to maximum horizontal resolution 1920 while still have dynamic resolution (0-1920) depending on himax?
You do not have the required permissions to view the files attached to this post.

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

Re: Scaler

Postby Grabulosaure » Tue May 21, 2019 10:53 pm

.
Last edited by Grabulosaure on Tue May 21, 2019 11:07 pm, edited 1 time in total.

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

Re: Scaler

Postby Grabulosaure » Tue May 21, 2019 11:07 pm

Another version !

- RAMBASE as base address in scaler mode.
- New signals for the framebuffer mode : o_fb_ena,o_fb_height, o_fb_width (this time actual dimensions :640x400, not 639x399), o_fb_base, o_fb_format
- No header in the framebuffer mode.
- freeze and triple-buffering don't need to be disabled in FB mode.
- Frame synchronisation can be kept, the framebuffer will be synchronised with the input video (but there is resynchronisation when toggling mode in VSYNC_ADJUST=2, I don't know why yet)


(and for downscaling... I will try again. With the current architecture, there are 128bits*32 double buffers between avl_, i_ and o_ clock domains, this wide bus wastes lots of RAM blocks and downscaling would require replicating these buffers.)[/quote]

Sorgelig wrote:Is it possible to fix the line length to maximum horizontal resolution 1920 while still have dynamic resolution (0-1920) depending on himax?

I can force the line length in framebuffer mode to use a constant number of 256 bytes bursts per line, independently from the resolution.
I've made an ascal_hburst.vhd version with an additional o_fb_hburst signal, if it's what you're looking for.

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5106
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Tue May 21, 2019 11:32 pm

Grabulosaure wrote:I can force the line length in framebuffer mode to use a constant number of 256 bytes bursts per line, independently from the resolution.
I've made an ascal_hburst.vhd version with an additional o_fb_hburst signal, if it's what you're looking for.

No, it's not related to burst length. I was talking about total length of line fixed to maximum possible input horizontal resolution. But i found that i can unregister the frame buffer and then register again with new parameters. Console it seems fine - it even re-draw itself to new resolution. So, scrap the idea about the fixed line length.

Going to sleep, so will test your new version after wakeup.
cheers!

alanswx
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 142
Joined: Sat Nov 25, 2017 4:34 pm

Re: Scaler

Postby alanswx » Wed May 22, 2019 12:07 am

Sorgelig wrote:
Grabulosaure wrote:I can force the line length in framebuffer mode to use a constant number of 256 bytes bursts per line, independently from the resolution.
I've made an ascal_hburst.vhd version with an additional o_fb_hburst signal, if it's what you're looking for.

No, it's not related to burst length. I was talking about total length of line fixed to maximum possible input horizontal resolution. But i found that i can unregister the frame buffer and then register again with new parameters. Console it seems fine - it even re-draw itself to new resolution. So, scrap the idea about the fixed line length.

Going to sleep, so will test your new version after wakeup.
cheers!


It looks amazing. While the hacking is going on it would be amazing to think about doing an overlay. Vectrex and other systems could use an overlay. I know that might be super hard.

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5106
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Wed May 22, 2019 4:40 am

Grabulosaure wrote:(and for downscaling... I will try again. With the current architecture, there are 128bits*32 double buffers between avl_, i_ and o_ clock domains, this wide bus wastes lots of RAM blocks and downscaling would require replicating these buffers.)

I went with linux system frame buffer. And it seems it does a good job supporting variable resolutions. So downscaling is not required at this stage.

Locutus73
Captain Atari
Captain Atari
Posts: 489
Joined: Wed Feb 07, 2018 6:13 pm

Re: Scaler

Postby Locutus73 » Wed May 22, 2019 9:01 am

Sorgelig wrote:something already works:
Image
colors are wrong, but should be easily fixed.

Cool! Which terminal are you using?
By the way, if you add (but I can download them myself if you prefer) dialog command to the Linux distro, we can instantly have interactive GUI scripts like this
SettingsMenu.png

For now I used (as I usually do) Debian armhf packages
http://http.us.debian.org/debian/pool/m ... _armhf.deb
http://http.us.debian.org/debian/pool/m ... _armhf.deb
http://http.us.debian.org/debian/pool/m ... _armhf.deb

Thank you in advance.
Regards.

Locutus73
You do not have the required permissions to view the files attached to this post.

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5106
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Wed May 22, 2019 12:07 pm

Locutus73 wrote:Which terminal are you using?

standard agetty

Locutus73
Captain Atari
Captain Atari
Posts: 489
Joined: Wed Feb 07, 2018 6:13 pm

Re: Scaler

Postby Locutus73 » Wed May 22, 2019 12:26 pm

Sorgelig wrote:
Locutus73 wrote:Which terminal are you using?

standard agetty

Brilliant! Did you manage to send it keyboard events?
Thinking to dialog use, I believe mapping joypad dpad to arrow keys, button 1 to enter, button 2 to esc, button 3 to space and button 4 to tab would satisfy most use cases.
INI editor? Easy...
WiFi configuration? Few lines of code...
Bluetooth pairing with device selection? A breeze...

Regards.

Locutus73

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5106
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Wed May 22, 2019 12:29 pm

once you start agetty on tty1, it will get all input events.


Return to “MiSTer”

Who is online

Users browsing this forum: Mills and 4 guests