MiSTer FPGA Forum

Posted: **Fri Jul 30, 2021 7:55 pm**

So recently I started playing with the scaler on a 4:3 display, in this case an SVGA monitor running at 1600x1200. I used the menu core to determine the edges of this screen and got it lined up within the visible area, so the pixels should be roughly square and observations here should apply equally to 4:3 LCDs (especially 1200p ones).

On the gauntlet 2 arcade the entire visible area is filled edge-to-edge, perfectly scaled by 5x using integer scaling. So this core should be perfectly 4:3 as far as I can tell.

However if I fire up CPS2 (example: Dungeons & Dragons), not all of the visible area is used in vertical integer scaling. I think this is expected because the visible area is only 224p. However the borders on the left and right appear larger than the top and bottom. If I disable vscale so that top and bottom are filled, there is still a border on the left and right, meaning the visible area is narrower than 4:3. Only by changing the aspect ratio to "full/wide" do I get my screen filled on the left/right axis, and in order to keep that 4:3 I need to have vscale disabled so the top/bottom can be filled.

I've had the exact same experience with the Genesis core when using "normal" scaling (i.e. width is supposed to match original aspect ratio.) So this seems like some sort of design choice for scaling Mister cores in general.

If this is correct behavior then I don't understand why it is or what is going on. When most people calibrate their CRTs with the 240p suite on 224p viewable systems, they are likely to push the corners so that the viewable area is roughly 4:3. Yet it seems like "normal" scaling on square pixel displays is rendering them *thinner* than 4:3. If anything I'd expect them to be squashed fatter by taking the full 240(244?) lines into account to 4:3! Where is my math failing that it is desirable for "normal" scaling of the viewable area to actually be narrower than 4:3? Is this only an issue with 4:3 output resolutions for some reason?

And yes I know I can squish and stretch a VGA monitor to correct this, but that isn't an option on LCD monitors, and it would be nice not to have to manually adjust my monitor for playing saying Gauntlet II that uses the entire screen versus CPS2 games. I'd be fine with a border to maintain vertical integer scaling on 224p games but its kind of odd how the border is significantly fatter on the sides than the top/bottom!

Posted: **Fri Jul 30, 2021 8:06 pm**

Funny, I was looking at the exactly the same issue today playing D&D (on a 15khz CRT with no scaling). There definitely is too much overscan on left/right. It does not really affect gameplay, and arcade on MiSTer is not my main focus, but nevertheless it'd be nice to know if it's possible to correct this somehow.

It's similar to the NeoGeo problem I've mentioned elsewhere.

Posted: **Fri Jul 30, 2021 11:44 pm**

akeley wrote: ↑Fri Jul 30, 2021 8:06 pm Funny, I was looking at the exactly the same issue today playing D&D (on a 15khz CRT with no scaling). There definitely is too much overscan on left/right. It does not really affect gameplay, and arcade on MiSTer is not my main focus, but nevertheless it'd be nice to know if it's possible to correct this somehow.

It's similar to the NeoGeo problem I've mentioned elsewhere.

I'm skeptical this is directly related. Arcade systems expect you to tune the monitor to match their output, they were never intended for home use and most of them only ran one game at a time. So for example while D&D is 224p tall, it puts important information on the edge of that which you would never see in a home console because it would be considered the overscan area for consumer TVs. Guantlet II is even more striking because it uses the entire 240p and puts some critical information there (like wizard choice on the first character select screen) My concern here would be that, because most arcades expected you to exactly match the viewable area to a 4:3 monitor, without significant overscan or borders, shouldn't the visible result default to exactly 4:3 when scaled with "normal" aspect ratio?

I do think there remains a question about neo-geo though, with some games being 320 wide and others less. Currently the scaler seems to treat that like "extra" and gives you a visible display wider than 4:3. Were arcade monitors supposed to be tuned to that 320 wide, or was that expected to run off the screen? I think those kind of considerations should guide whatever is judged to be "normal" aspect ratio for the scaler.

Posted: **Sat Jul 31, 2021 12:32 am**

I found this video that sort of explains it, somewhere. Indeed it looks like the "standard" viewable area of many consoles is supposed to be narrower than 4:3, with the expectation that overscan will chop off more of the top and bottom than the sides. That would make lining up the 240p test suite 224p grid to perfectly align with the sides of your CRT kind of incorrect! I'm not as sure what that means for arcade cores though where its always a given that the owner can and should adjust the moniitor to match the arcade...

Posted: **Sat Jul 31, 2021 10:54 am**

I may have this wrong because I’m not sure entirely how you’re running your setup, but the first thing I’d say is that the horizontal borders should be slightly wider than the vertical borders are tall because the aspect ratio applies to them as well. Say you’re running a core with a 4:3 aspect ratio and a vertical resolution of 900 lines (a number I chose to make the maths easy). That would give a horizontal resolution of 1200 pixels. On your 1600x1200 display, you’d have vertical borders of 150 lines above and below, and horizontal borders of 200 pixels on either side (so the horizontal border is 4/3 times the size of the vertical one).

What sort of results do you get with a custom aspect ratio of 4:3? It looks like Gauntlet’s “Original” aspect ratio in the core is 4:3. I don’t think the CPS2 source is publicly available, so I dunno what’s in there aspect ratio wise. The genesis core actually doesn’t use a 4:3 aspect ratio most of the time. The core has four output resolutions: 256x224, 256x240, 320x224, and 320x240. The aspect ratios it uses are 64:49, 128:105, 10:7, and 4:3 respectively. If you turn on 320 correction then the 320 resolutions use the corresponding 256 aspect ratios instead (64:49 or 128:105). I’m sure those numbers derive from something but I don’t know what. I think the 224 aspect ratios are based on the aspect ratio of the 256/320 by 224 image within the 240 line image, so they should be wider, as you said. Maybe this is a dumb question, but do you have HV integer scaling turned on? That’ll cause aspect ratio changes.

Posted: **Sat Jul 31, 2021 1:20 pm**

What you said about the borders is true but the discrepency is larger than that. Because if I shut off vscale so that the resolution is filled vertically, there is still space horizontally. This space can be eliminated by changing aspect ratio in a core from normal to full.

However the conclusion I came to is that most console cores are NOT true 4:3, according to the TV standards of the time! And cores are likely striving to meet those standards rather than filling a 4:3 display after being scaled.

The best example given in the video is the infamous moon from Chrono Trigger. The moon is slightly fat at 4:3, it only appears perfectly circular when you use the slightly narrower results from forcing a 8:7 Pixel Aspect Ratio (i.e. using the shape of the non-square pixels themselves as the standard)

As I understand these non-4:3 ratios make sense in a world where your average consumer TV is going to chop things off in overscan anyway. I'm not as sure whether this is the best approach for representing arcades where the monitor is typically tuned to eliminate overscan, but at least there is some consistency to following the video/pixel clock standards and leaving it up to the user to adjust that. Maybe a "true" 4:3 aspect ratio option showing up in more cores for example.

Posted: **Sat Jul 31, 2021 4:18 pm**

I tried setting a custom aspect ratio of 4:3 in CPS2 and found that it gave a slightly wider picture than the Original setting, so maybe the aspect ratio set in the core is something else.

OK, I had a look after writing the above and in the code on Jotego’s GitHub I think the “Original” aspect ratio is defined as 1280:973. That works out to about 1.316, slightly narrower than 4:3’s 1.333, and I’m sure there’s a good reason it’s set to that but I don’t know what it is. You’re right, though, that the core is not defaulting to 4:3.

I’m kind of a skeptic of there being particular correct aspect ratios in a lot of cases. It’s hard to know what the people making these games intended, and it was all running on analogue technology where the final result would be influenced by the individual piece of hardware and how it was set. If you want it to be 4:3, you can set a custom aspect ratio for that, or just turn off vertical integer scaling and use “Full Screen” with a 4:3 resolution. I tend to favour integer scaling to avoid shimmery scrolling, so my settings will usually have the aspect ratio slightly wrong (I’m using 1152:896 for CPS2, which works out to 1.286, a fair bit narrower than 4:3, but gives a pixel aspect ratio of 3:4 with horizontal and vertical integer scaling), but it’s a matter of preference.

Posted: **Sat Jul 31, 2021 4:57 pm**

akeley wrote: ↑Fri Jul 30, 2021 8:06 pm Funny, I was looking at the exactly the same issue today playing D&D (on a 15khz CRT with no scaling). There definitely is too much overscan on left/right.

I have to issue a retraction. Have tried it again today and it's actually fine. I did change from a VGA-SCART converter to a cable in the meantime, and had to set composite sync=1, but I doubt it had anything to do with it. Most likely I just suggested myself: was playing a bit of Cyberbots then as well, and in that game characters can go slightly off-screen. Plus, in the other cores you have to usually apply horizontal shift to center the image. But, I compared it against MAME and the horizontal fit/width is nearly the same, barring few pixels (same in Gauntlet II & D&D). NeoGeo is still stretched a bit too much though.

But that's referring to my CRT TV setup with no scaling (Direct video). Maybe when using a scaler and another kind of display, there really is a problem, as Foxbat says.

Overall I agree with Yim, that there probably is no one-true-ratio, or a set of measurements when you consider all the analogue tech, different tools, platforms, and the human factor.

Posted: **Sun Aug 01, 2021 7:15 am**

We DO have standards for the analog signal though: the original hardware. And while I think more options are great, the default should always lean towards accuracy, which in most cases mister seems to, and should be corrected where not.

As for how to scale that signal: we have the Rec 601 standard, which effectively defines the viewable area and the aspect ratio on CRts that results from whatever pixel clock. That's certainly going to be applicable to most console and many computer cores, where consumers were not expected to be adjusting their geometry. Regardless of whether software devs took it into account and corrected for it properly, there was a default ideal for how the analog signal should translate to consumer sets, and its perfectly appropriate in many cases for the default scaling to be based upon that.

I just think it might get weirder with arcade cores, especially if they supply a test pattern to calibrate against that is not within Rec 601. But it seems that there should be a standard default here too, especially if the manufacturer is explicitly telling arcade operators how to calibrate their displays. Thanks to the newish [Arcade] option I can at least try to dump a custom 4:3 aspect ratio into all of them, although I'm not actually that confident on widespread support...

Posted: **Sun Aug 01, 2021 11:06 am**

I think I’d agree that “Original” in the aspect ratio menu should attempt to be accurate to the original hardware, but I still think original hardware is pretty variable in a lot of cases. For me with consoles, original hardware involved an RF signal to a PAL TV older than I am compressing a lot of games vertically because they were designed for NTSC systems. I’m not familiar with Rec 601 and haven’t been able to get much sense of it from google, so perhaps I’m missing something.

Jotego’s framework defaults to 4:3 unless the core changes it to something else, so presumably he thinks 1280:973 is more accurate for CPS2 for some reason. Whether that reason is good or bad, I don’t know.

If the custom aspect ratio thing isn’t working, you should be able to get 4:3 by turning off vertical integer scaling and using the “Full Screen” aspect ratio option with your 1600x1200 video mode, right?

Posted: **Sun Aug 01, 2021 2:44 pm**

It goes without saying that MiSter should strive to output the most accurate look per platform (though not sure you can/should apply an uniform rate to that). But my impression is that it already does that, perhaps in most cases. I actually measured some of the cores vs my real machines (Amiga, ZX Spectrum) and they were pretty much 1:1. I know there was some problem with C64 border size, but it might've been corrected already.

And while there might be some general output signal standard, it is still not a given that all the machines would display in the same way. Eg Amiga's image is always shifted horizontally on real hardware for some reason, which can be a major headache if you don't have a monitor with position adjustment knobs or know how to get into the service menu. PAL/NTSC is another quagmire. And there definitely wasn't a standard in regard to overscan, which could differ significantly per TV, and so can also vary per game design. When it comes to arcade it gets even wilder, what with all the different resolutions and monitors. You can try and correct it for one platform, but when you connect another source, it can all go out of the window anyway. I've spent enough time trying to make one-size-fits-all adjustments on my CRTs to know it's a pipe dream - even with help of tools such as Calamity's switchres. You can get pretty close for most, and that's the moment you should walk away and start enjoying the games.

I don't have experience with digital panels so not sure how much of it is related to the AR problem from the OP - if it's indeed a problem. I can speak only for CRTs, and like I said the CPS2 games fill the screen nearly ideally (going maybe 2-3 milimeter over) on my 4:3 set. Meanwhile, some others don't, eg Iron Horse has big black horizontal bars. And yet the sun/wheels look more round and "appropriate" than in MAME, which stretches it horizontally.

Posted: **Sun Aug 01, 2021 4:05 pm**

CPS2 Dungeons and Dragons looks normal to me when I play it. It's a 384x224 resolution game. I use this video mode:

Code: Select all

video_mode=1600,64,192,304,1200,1,3,46,162000

(which doesn't work for Genesis for some reason).

Here's a screenshot from OBS (grey lines are from OBS, black lines are from the display scaling).

: dnd.png (337.58 KiB) Viewed 4679 times

This makes sense because 384x224 is 12:7 aspect ratio and 1600x1200 is a 4:3 aspect ratio. If it's integer scaled completely there will necessarily be some bars on all sides. If it's proportional and scaled to fit vertically to full screen, it will still have black bars.

224 * 5 = 1120. if you integer scale to a 1200p display (meaning perfectly square pixels on that video output) then you will have a remainder of 80 pixels that will server as a vertical border. the borders on the left and right will increase as well. In my example above I don't have integer scaling turned on in mister.ini, it's scaled to height instead, which still leaves a border because 4:3 display =/= 12:7 video output.

Everything you observed is to be expected because of simple math

EDIT: lol my genesis core was corrupt, that's why it wasn't working. Here's 1600x1200 resolution with genesis core with integer scaling:

: P8IMUxsN8p.png (119.67 KiB) Viewed 4641 times

This is probably the same kind of borders you are seeing with 224p with integer scaling, because 224 doesn't divide evenly into 1200.

Posted: **Sun Aug 01, 2021 8:27 pm**

akeley wrote: ↑Sun Aug 01, 2021 2:44 pm I don't have experience with digital panels so not sure how much of it is related to the AR problem from the OP - if it's indeed a problem. I can speak only for CRTs, and like I said the CPS2 games fill the screen nearly ideally (going maybe 2-3 milimeter over) on my 4:3 set. Meanwhile, some others don't, eg Iron Horse has big black horizontal bars. And yet the sun/wheels look more round and "appropriate" than in MAME, which stretches it horizontally.

I'm not trying to bring up any issue with the analog output really. As long as it strives to match original hardware, that's as good as you can expect by default. This is completely a question of what the default/normal aspect ratio should be for scaled output; and me discovering that, although we colloquially speak of 4:3, actual systems often did not target that exact AR, if you displayed their signals on an ideal CRT perfectly calibrated to Rec. 601. This just leads to some oddities scaling to higher resolution 4:3 displays, but I agree that the default scaling should be to follow standards. I'm a little less sure how that should apply to arcade systems (really I don't have the expertise to answer this question), but home systems seem to be generally handled proper. It's just a bit of extra work now scaling to a 4:3 display!

aberu wrote: ↑Sun Aug 01, 2021 4:05 pm 224 * 5 = 1120. if you integer scale to a 1200p display (meaning perfectly square pixels on that video output) then you will have a remainder of 80 pixels that will server as a vertical border. the borders on the left and right will increase as well. In my example above I don't have integer scaling turned on in mister.ini, it's scaled to height instead, which still leaves a border because 4:3 display =/= 12:7 video output.

12:7 is not remotely the correct aspect ratio for CPS2, that is vastly wider than 4:3! If you were to represent 12:7 on a 4:3 display, without integer scaling, you would have massive borders on the top and bottom, letterboxing basically. Not mild borders on the sides.

You cannot directly derive aspect ratio from the resolution because the CPS2, like many systems with analog output meant for CRTs, was not targeting square pixels. The CPS2 pixels are meant to be rather slim (135:176 or practically 3:4), and if you multiply that by the horizontal resolution (339) and divide by the vertical resolution (224), you end up with an aspect ratio of 1.314, which is slightly less than the 1.333 repeating of a perfect 4:3 aspect ratio. That is why you have black bars on the side with default scaling, because CPS2's aspect ratio is a little narrower than your perfectly 4:3 display.

Posted: **Sun Aug 01, 2021 9:40 pm**

FoxbatStargazer wrote: ↑Sun Aug 01, 2021 8:27 pm 12:7 is not remotely the correct aspect ratio for CPS2, that is vastly wider than 4:3! If you were to represent 12:7 on a 4:3 display, without integer scaling, you would have massive borders on the top and bottom, letterboxing basically. Not mild borders on the sides.

https://twitter.com/FBXGargoyle/status/ ... 3639279617

Yes, it is technically "correct", since it's the raw signal. Standard resolution from Capcom arcade games, and they even ported it that way to the Playstation 1. This is the actual resolution, and then it is modified from there by either the way they push it out to the analog screen, or how software emulators or hardware emulators decide to present it. The extremely slight borders in the full screen screenshot I have above from DnD shows that the output is basically 4:3. If it were 8:7 that wouldn't make sense since there would be way more pixels blacked out horizontally as a border than what we are seeing there.

FoxbatStargazer wrote: ↑Sun Aug 01, 2021 8:27 pm You cannot directly derive aspect ratio from the resolution because the CPS2, like many systems with analog output meant for CRTs, was not targeting square pixels. The CPS2 pixels are meant to be rather slim (135:176 or practically 3:4), and if you multiply that by the horizontal resolution (339) and divide by the vertical resolution (224), you end up with an aspect ratio of 1.314, which is slightly less than the 1.333 repeating of a perfect 4:3 aspect ratio. That is why you have black bars on the side with default scaling, because CPS2's aspect ratio is a little narrower than your perfectly 4:3 display.

Yes, correct, all these kinds of games on CRT were displaying pretty much in 4:3 despite the pixels adding up to 12:7 (or some variation on this, like the SNES/NES were in 8:7). It's up to the core developers to add these options, raise an issue with Jotego on his github I think. Additionally you can just add this to your MiSTer.ini and the aspect ratio option should appear (however maybe it won't since Jotego uses his own framework and doesn't use the official mister framework, which sometimes causes inconsistencies for user experience like this).

Code: Select all

[jtcps2]
custom_aspect_ratio_1=4:3
custom_aspect_ratio_2=8:7
custom_aspect_ratio_3=12:7

etc...

This should open up an option in the OSD. If it doesn't, then it's on Jotego to add this functionality.

Posted: **Mon Aug 02, 2021 9:48 am**

FoxbatStargazer wrote: ↑Sun Aug 01, 2021 8:27 pm I'm not trying to bring up any issue with the analog output really.

I know, I'm just sort of piggybacking on your thread here and partially thinking out loud. It's an interesting subject and there might be an overlap between digital and analogue regarding some problems/solutions. And not many people talk about these things.

I was playing Double Dragon yesterday and this game outputs 256x240@57.4 Hz, making the image look look really "tall", with a big bar on the left end even bigger one on the right. So this goes back to the resize-it-yourself idea of the arcade displays, but looking online at some original DD cabs with live displays you can see that not all of them were actually adjusted - they look pretty much as-is. The question of "what was the intended look" becomes a bit philosophical then...most likely the devs did the art on PCs, presumably in 4:3...or did they? When I compare the original vs MAME (which stretches to ~4:3) the former looks perhaps too tall, but then the latter a bit too wide. It's similar with Iron Horse (and was even mentioned by Ace recently) though this game looks fine as-is to me. If my TV had this game's AR, I wouldn't have thought something's amiss.

Ideally, for the arcade (and perhaps benefitting other cores) would be having manual scaling and/or AR options in the OSD, something like in Retroarch where you can stretch and shrink the image either per pixel, or while locking the integer and doing step by step resizing, then saving the results per game. Unlikely to see it here though.

Posted: **Mon Aug 02, 2021 3:19 pm**

So it almost sounds like we're on the same page with scaling so it's not clear why this was brought up?

aberu wrote: ↑Sun Aug 01, 2021 4:05 pm This makes sense because 384x224 is 12:7 aspect ratio and 1600x1200 is a 4:3 aspect ratio. If it's integer scaled completely there will necessarily be some bars on all sides. If it's proportional and scaled to fit vertically to full screen, it will still have black bars.

224 * 5 = 1120. if you integer scale to a 1200p display (meaning perfectly square pixels on that video output) then you will have a remainder of 80 pixels that will server as a vertical border. the borders on the left and right will increase as well. In my example above I don't have integer scaling turned on in mister.ini, it's scaled to height instead, which still leaves a border because 4:3 display =/= 12:7 video output.

I'm not sure I agree about the AR of 384x224 being "truly" or "raw" as 12:7 because you can't even begin to speak of aspect ratio without assuming that pixels have a certain shape, in this case, square. But even if we grant that, the relevance of that to "normal" scaling is unclear. The whole point of "normal" aspect ratio scaling is that it tries to approximate the stretch and squish of a CRT. Whatever your vscale settings, using vertical integer scaling or not, normal scaling approximates how the aspect ratio of an active area of the analog signal would be interpreted on a CRT under Rec 601. So with integer scaling off, the reason D&D has slight borders on the side is because that is how the AR would appear on an "ideally" Rec 601 calibrated CRT. Super Nintendo and Genesis have vastly different "raw" ARs and yet they appear very similar to CPS2 in normal scaling (slight black bars on either side on a 4:3 display with vscale_adjust=0) for the same reason. The "raw" AR alone does not provide enough information for a normal scale, it always adjusted by a factor that reflects the shape of pixels on a CRT.

Even if you use horizontal integer scaling options in Mister (does CPS2 even have these?), these do not directly replicate the "raw" AR. Rather they look for what are the two nearest horizontal integer multiples to the fractional multiple used for normal scaling, which is again based on the odd shapes the pixels would take on a CRT. (I.E this is what HV Integer - and + oscillate between.)

Posted: **Mon Aug 02, 2021 3:27 pm**

The reason I'm bringing it up is... because you said the borders are larger horizontally than they are vertically... borders are larger horizontally than the borders vertically in the core right now. Change from integer scale to scale to fit screen in your mister.ini, then see what I mean on your 1600x1200 display, there are borders horizontally while there are non vertically. That means the aspect ratio is not 4:3 in the core, and Jotego would either have to adjust it or give an option for you to adjust it, or you will have to use custom_aspect_ratio option in your mister.ini or jotego would have to add support for that option if he doesn't have it already.

Raise an issue on Jotego's github for CPS1 (which includes CPS1.5 and CPS2) to get this addressed.

Posted: **Tue Aug 03, 2021 5:22 pm**

akeley wrote: ↑Fri Jul 30, 2021 8:06 pm It's similar to the NeoGeo problem I've mentioned elsewhere.

Check out recent updates, it seems the refresh and maybe overscan settings have been adjusted for AES mode. Apparently SNK also made some tweaks for use on consumer CRTs!

MiSTer FPGA Forum

Cores not defaulting to 4:3?

Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?

Re: Cores not defaulting to 4:3?