Forked cores with 4K horizontal resolution support

[justaguy]

Not sure how many other people this appeals to, but I modified some MiSTer cores to support horizontal output resolutions up to 4096px without pixel repetition. This doesn't mean 3840x2160 is possible, of course--there's just not enough bandwidth available. What you can do is use a lower vertical resolution like 720px and enable the "stretch to fit" setting on your display. Essentially you're giving up vertical resolution and sharpness in exchange for full use of your display's horizontal resolution. I'd ordinarily want to avoid the blurry vertical scaling from the display, but I've been using a simple scanline filter that just blanks out every third line at 3x (attached), and the end result is a nice basic soft scanline effect.

Stuff this is useful for:

• Integer scaling--you can achieve a 10:9 pixel aspect ratio for NTSC 256px modes, which is less than 3% away from the canonical 8:7 and doesn't require any cropping of a 240p image. Other console PARs like 12:7, 32:35, 6:7, 4:5, 4:7, and 16:35 also have close integer scales at 9x vertical.
• Non-integer scaling--I've strongly preferred integer scaling up until now, but with so much horizontal resolution, I can't see any scrolling shimmer with nearest neighbor, let alone the horizontal blur filters I've come to favor. I might just stick with the core default aspect ratio + V-Integer scaling from now on.
• Shadow mask and other CRT effects--these aren't my thing but I think they might look better with the extra resolution?

Notes if you want to try this out:

• Obviously your display has to be able to accept 3840x720--I'd expect PC monitors to be better than TVs for this, but my Sony XBR-49X900E handles it fine, at least. I'm using this modeline:

  Code: Select all

  video_mode=3840,48,32,80,720,3,10,8,177750,+hsync,-vsync

• I had to disable some features to save FPGA resources and meet timing requirements. Y/C output, the scandoubler (including HQ2X), and bilinear downscaling are disabled, as well as some logic in ASCAL for bilinear and bicubic scaling that isn't actually used by any cores to my knowledge. Not all of these actually needed to be disabled for every core, but I kept things the same across cores for simplicity.
• Core aspect ratios have been adjusted to compensate for the display stretching, so the non-stretched output will be 3x wider than the upstream core. TurboGrafx is a little bit wider than 3x so that the Narrow HV-Integer scaling setting will look decent with all video modes. If you want it to be the same as the upstream core you can use a custom aspect ratio (4:1, assuming overscan is cropped).
• If you happen to have a Sony TV with "Graphics" picture mode, turn it on! I first took note of this mode for its 1080p->4K nearest-neighbor scaling, but scaling from other resolutions is also cleaner than Game mode (which still seems to be doing some enhancement). Input lag is the same as game mode, at least on my TV.

Download links:
NES
SNES
MegaDrive
MegaCD
PSX
TurboGrafx16

[aberu]

Do you have any screenshot examples from a capture card?

[Neocaron]

Pretty cool addition I'll give it a try with my Panasonic TV! Really curious to see how it looks. I remember doing something similar before we had 1536p support and it worked decently well on my 4/3 screen at the time. If it turns out well, shadow mask could look great with this!

[justaguy]

Do you have any screenshot examples from a capture card?

Yeah, it would probably be a good idea to show what it looks like...

I don't have a capture card, but I can simulate it well enough with image editing tools. I've attached examples of what it should look like with two different horizontal scaling options--integer nearest-neighbor and non-integer linear (SharpBilinear000 in the official filter repository, though I use my own version with more phases which I've also attached). Raw versions are there for anyone who wants to try it out with their display's actual scaling, stretched versions are just bilinear scaled to 2160p.

[Newsdee]

Interesting. So this allows geting 4K by letting the TV do the vertical scandoubling (technically quadrupling)

This should work great for horizontal scrolling games, they often suffer from shimmering if they are not stretched properly.

Small suggestion, could you change the name of the core in config string (e.g. NES4k) so that settings can be saved for it separately?

[justaguy]

Small suggestion, could you change the name of the core in config string (e.g. NES4k) so that settings can be saved for it separately?

I'd like to do that, but there's a good deal of core-specific logic in main that looks for an exact name match, to the extent that changing the name can completely break the core. For instance, the PSX core can't boot games if it isn't named "PSX".

What I do instead is create MGL files alongside the official cores, like this:

Code: Select all

<mistergamedescription>
	<rbf>_Console/unofficial/NES4K</rbf>
	<setname>NES4K</setname>
</mistergamedescription>

[Neocaron]

Interesting. So this allows geting 4K by letting the TV do the vertical scandoubling (technically quadrupling)

This should work great for horizontal scrolling games, they often suffer from shimmering if they are not stretched properly.

Small suggestion, could you change the name of the core in config string (e.g. NES4k) so that settings can be saved for it separately?

I was also gonna suggest a name change in the strings this way we can have it all. I quickly tried on a PS1 game FFVIII and it looked quite good! Kind of surprising actually. I thought 2d backgrounds would hate this and they don't, with your filter it works very nicely and the integer scaling looks awesome.

Reallly good idea you had there!

[Newsdee]

I'd like to do that, but there's a good deal of core-specific logic in main that looks for an exact name match, to the extent that changing the name can completely break the core. For instance, the PSX core can't boot games if it isn't named "PSX".

You're absolutely right, I forgot about those! They are needed by most cores with a CD at least. Minimig also has lots of extra handling in MiSTer main.

I need to give this a try on my 4K TV, hope it will accept the signal...

[limi]

Any chance of an Amiga (Minimig) core using this technique?

[Hackshed_Carl]

Here's a random idea.... no idea how feasible it is though....

Instead of making custom cores, wouldn't it be possible to add the logic to each core and then have it as a menu selectable option?

My thinking here is that if it gets added to the core as a pull request / contrib (not a dev so no idea what it's called) then it should be fairly simple to add a menu option to enable / disable it.
That way it gets added at compile time and doesn't require each core to be manually edited & compiled

Of course, I could be talking absolute tosh in which case I shall apologise now and go back to my lane

[justaguy]

Any chance of an Amiga (Minimig) core using this technique?

I focused on the cores I spend a lot of time playing, but it could certainly be done for other cores as well. If there's demand I can do a second round, and at the very least I'll do a writeup on how I did this so people can make their own--it's really not all that complicated.

Here's a random idea.... no idea how feasible it is though....

Instead of making custom cores, wouldn't it be possible to add the logic to each core and then have it as a menu selectable option?

My thinking here is that if it gets added to the core as a pull request / contrib (not a dev so no idea what it's called) then it should be fairly simple to add a menu option to enable / disable it.
That way it gets added at compile time and doesn't require each core to be manually edited & compiled

Of course, I could be talking absolute tosh in which case I shall apologise now and go back to my lane

The dream would be to have it as part of the MiSTer framework so every core gets it when the framework is updated. The problem is that increasing the max horizontal resolution from 2048 to 4096 can cause timing issues and compilation failures due to resource limitations. I addressed these issues by removing features, but that wouldn't be a valid approach for upstream. I'm a total novice at this, so maybe a more experienced dev could make it work?

[Newsdee]

Would it be possible to support 3440 x 720 resolutions?
What modeline and filter should I use for that? (it would need 2x scanlines)

The problem is that increasing the max horizontal resolution from 2048 to 4096 can cause timing issues and compilation failures due to resource limitations. I addressed these issues by removing features, but that wouldn't be a valid approach for upstream. I'm a total novice at this, so maybe a more experienced dev could make it work?

Does every core need removing features? You could try placing the change under a compiler flag, so at least it is easier to merge whenever the upstream changes. That might be more palatable to core devs as it wouldn't affect normal operation of the core.

[Newsdee]

Sadly it doesn't work with my TV

[antibolo]

Wow that’s a really clever workaround to the HDMI port not being 4K capable! Love seeing stuff like this.

[justaguy]

Would it be possible to support 3440 x 720 resolutions?
What modeline and filter should I use for that? (it would need 2x scanlines)

For an ultrawide monitor? You'd still want 3x scanlines because you're still scaling from 240p to 720p on the MiSTer side. You'd need to set a custom aspect ratio that's 2x wider than usual instead of 3x, though.

Code: Select all

video_mode=3440,48,32,80,720,3,10,8,160000,+hsync,-vsync

(This calculator has been invaluable for me in coming up with modelines for weird resolutions--use the CVT-RB column.)

Does every core need removing features? You could try placing the change under a compiler flag, so at least it is easier to merge whenever the upstream changes. That might be more palatable to core devs as it wouldn't affect normal operation of the core.

The only two that strictly needed it were SNES and TurboGrafx16, where I had to disable the scandoubler and HQ2X to free up enough resources to get them to compile. All the other feature removals were done to improve timing, something that's nice to have but not an absolute must--some vanilla cores (e.g. MegaDrive) don't currently meet timing requirements.

The compiler flag idea is a good one. I'll try submitting a pull request to the framework repository in the next few days.

[justaguy]

I've tested this with a lot more cores now. It turns out that most of the feature removals were unnecessary--the only feature that needed to be removed was the scandoubler/HQ2X, and only for SNES, TurboGrafx16 and Saturn. So custom builds shouldn't be needed for most cores if/when this gets upstreamed--just a custom modeline and aspect ratio with vscale_mode=1.

Rather than make GitHub forks for everything, I just uploaded the RBFs to Google Drive. Many are untested, but give them a try if you're interested. The INI file in the root folder has modelines and aspect ratios for some (not all) of the cores--make sure to set the custom aspect ratio in the core menu as well.

https://drive.google.com/drive/folders/ ... 1nWzOmbeuH

4K MiSTer cores-20231220T173901.zip

(82.66 MiB) Downloaded 159 times

[justaguy]

So I opened a pull request and it got rejected. I'll try to keep the Google Drive folder somewhat up to date, at least.

For anyone who wants to recompile their favorite core to support 4K horizontal, it's usually quite simple. Just change the following line in sys/ascal.vhd:

Code: Select all

		OHRES        : natural RANGE 1 TO 4096 :=2048;

to this:

Code: Select all

		OHRES        : natural RANGE 1 TO 4096 :=4096;

If compilation fails due to the Cyclone V not having enough M10K blocks, you can disable the scandoubler and HQ2X by replacing sys/video_mixer.sv with the attached file (renamed to .txt due to forum limitations).

[Neocaron]

Why rejecting a cool feature like this if it doesn't break anything? Thanks for your hardwork on this nonetheless, I'll definitely be using those, I love my CRT, but when I have people over my 4K tv is much more convenient, so thank you since this make the games look much much better!

[FPGA64]

Why rejecting a cool feature like this if it doesn't break anything? Thanks for your hardwork on this nonetheless, I'll definitely be using those, I love my CRT, but when I have people over my 4K tv is much more convenient, so thank you since this make the games look much much better!

From the github

It was rejected because

MiSTer generally operates only with square pixels on HDMI. Introducing non-square pixels will make experience worse and too convoluted to manage.
As you already pointed out it reserves way too much BRAM so even some cores won't fit.

You can compile it for your own use, but it doesn't fit MiSTer, sorry.

[Neocaron]

Ok thanks for bringing up the reason, it still works since I've been testing it on multiple cores without issues. I guess it will remain a cool feature on the side. Image quality difference is so massively better that I think it's worth trying for anyone with a 4K TV.

[Asteld]

This is a very nice solution. I don't know how the changes affect the cores' logic, but it seems worth it to keep this idea alive.

Perhaps instead of a pull request for updated cores, you could make a pull request for the documentation. Perhaps it is possible to create a documentation entry for "unofficial 4k support" or something, in which you provide the above instructions.

It seems a shame to let this die in a (probably soon forgotten) forum thread.