MiSTer FPGA Forum

Posted: **Sat Jan 23, 2021 8:10 pm**

This tool might be useful for those wanting to calculate their own aspect ratio's. It's based on source code by Rysha, converted to python and now available online:

MiSTer Aspect Ratio Calculator

Posted: **Sat Jan 23, 2021 8:32 pm**

You're doing a great job man!

Your tools have been my go-to for everything CRT related, and I thank you for that

Also maybe this reference should be pinned for all of us scratching our heads.

Posted: **Sun Jan 24, 2021 1:25 pm**

Glad to be able to give something back. I'm taking a look at that reference you linked. Maybe it would useful to have presets available in these tools?

Posted: **Sun Jan 24, 2021 8:27 pm**

morf77 wrote: ↑Sun Jan 24, 2021 1:25 pm Maybe it would useful to have presets available in these tools?

Certainly! Not only would that make life easier, but it would also preserve this reference work (as I'm afraid a geocities hosted page won't be up forever)

Posted: **Mon Jan 25, 2021 1:27 pm**

Presets have been added to the video_mode calculator.

Posted: **Sat Jan 30, 2021 3:27 pm**

Here are some integer scaled custom aspect ratios I've calculated for various consoles and games using this calculator, mostly using the pixel clocks from here: http://www.geocities.ws/podernixie/htpc/modes-en.html

Some of the resolutions listed on that page won't work for MiSTer as e.g. the TurboGrafx-16 core will only output vertical resolutions of 242 (with overscan visible) or 231 (with overscan hidden), not the values listed on that page. Taking a screenshot of the core and checking the resolution seems to give the correct values needed for the calculator.

I've commented out all but two ARs for each console as the current function only allows that many. Let me know if this is useful to anyone else, or if you find any errors!

720p

Code: Select all

[Gameboy]
custom_aspect_ratio_1=8:7      ; 256:224 (160:144)

[Genesis]
custom_aspect_ratio_1=8:7      ; 256:224, Border Off
custom_aspect_ratio_2=10:7     ; 320:224, Border Off
;custom_aspect_ratio_1=280:243 ; 280:243, Border On
;custom_aspect_ratio_2=344:243 ; 344:243, Border On

[MegaCD]
custom_aspect_ratio_1=8:7      ; 256:224, Border Off
custom_aspect_ratio_2=10:7     ; 320:224, Border Off
;custom_aspect_ratio_1=280:243 ; 280:243, Border On
;custom_aspect_ratio_2=344:243 ; 344:243, Border On

[NeoGeo]
custom_aspect_ratio_1=10:7     ; 320:224
;custom_aspect_ratio_2=19:14   ; 304:224 (not necessary)

[NES]
custom_aspect_ratio_1=8:7      ; 256:224

[SMS]
;Use Original Aspect Ratio with Border Off for 1:1 PAR in SMS mode (need 256/248 width fix commits)
;custom_aspect_ratio_1=4:3     ; 256:192, SMS, Border Off
;custom_aspect_ratio_2=31:24   ; 248:192, SMS, Border Off (BG: Cut after 256/248 width fix commits)
;custom_aspect_ratio_2=282:239 ; 282:239, SMS, Border On (obsolete after 256/248 width fix commits)
custom_aspect_ratio_1=10:9     ; 160:144, Game Gear, square PAR (untested)
custom_aspect_ratio_2=11:9     ; 160:144, Game Gear, wider PAR (untested)

[SNES]
custom_aspect_ratio_1=8:7      ; 256:224, use for most games
custom_aspect_ratio_2=256:239  ; 256:239, use for Dragon Quest V
;custom_aspect_ratio_2=32:21   ; 512:224, use for Secret of Mana (too wide)
;custom_aspect_ratio_2=8:7     ; 512:448, use for Radical Psycho Machine Racing (USA)

[TGFX16]
custom_aspect_ratio_1=90:77    ; 270:231, Overscan Hidden
custom_aspect_ratio_2=120:77   ; 360:231, Overscan Hidden, use for R-Type & Daimakaimura (wide)
;custom_aspect_ratio_2=80:77   ; 360:231, Overscan Hidden, use for R-Type & Daimakaimura (thin)
;custom_aspect_ratio_1=135:121 ; 270:242, Overscan Visible
;custom_aspect_ratio_2=180:121 ; 360:242, Overscan Visible, use for R-Type & Daimakaimura

1080p

Code: Select all

[Gameboy]
custom_aspect_ratio_1=8:7      ; 256:224, square PAR (160:144)
custom_aspect_ratio_2=10:7     ; 256:224, wider PAR (160:144)

[Genesis]
custom_aspect_ratio_1=10:7     ; 256:224, Border Off
;custom_aspect_ratio_2=10:7    ; 320:224, Border Off (happens to be the same ratio as 256:224 at 1080p)
;custom_aspect_ratio_1=350:243 ; 280:243, Border On
;custom_aspect_ratio_2=344:243 ; 344:243, Border On

[MegaCD]
custom_aspect_ratio_1=10:7     ; 256:224, Border Off
;custom_aspect_ratio_2=10:7    ; 320:224, Border Off (happens to be the same ratio as 256:224 at 1080p)
;custom_aspect_ratio_1=350:243 ; 280:243, Border On
;custom_aspect_ratio_2=344:243 ; 344:243, Border On

[NeoGeo]
custom_aspect_ratio_1=10:7     ; 320:224
;custom_aspect_ratio_2=19:14   ; 304:224 (not necessary)

[NES]
custom_aspect_ratio_1=10:7     ; 256:224

[SMS]
;Use Original Aspect Ratio with Border Off for 1:1 PAR in SMS mode (need 256/248 width fix commits)
;custom_aspect_ratio_1=8:5     ; 256:192, SMS, Border Off
;custom_aspect_ratio_2=31:20   ; 248:192, SMS, Border Off (BG: Cut after 256/248 width fix commits)
;custom_aspect_ratio_1=705:478 ; 282:239, SMS, Border On (obsolete after 256/248 width fix commits)
custom_aspect_ratio_1=10:9     ; 160:144, Game Gear, square PAR (untested)
custom_aspect_ratio_2=11:9     ; 160:144, Game Gear, wider PAR (untested)

[SNES]
custom_aspect_ratio_1=10:7     ; 256:224, use for most games 
custom_aspect_ratio_2=320:239  ; 256:239, use for Dragon Quest V
;custom_aspect_ratio_2=8:7     ; 512:224, use for Secret of Mana
;custom_aspect_ratio_2=4:7     ; 512:448, use for Radical Psycho Machine Racing (USA)

[TGFX16]
custom_aspect_ratio_1=225:154  ; 270:231, Overscan Hidden
custom_aspect_ratio_2=90:77    ; 360:231, Overscan Hidden, use for R-Type & Daimakaimura
;custom_aspect_ratio_1=675:484 ; 270:242, Overscan Visible
;custom_aspect_ratio_2=135:121 ; 360:242, Overscan Visible, use for R-Type & Daimakaimura

1440p

Code: Select all

[Gameboy]
custom_aspect_ratio_1=8:7      ; 256:224, square PAR (160:144)
custom_aspect_ratio_2=4:3      ; 256:224, wider PAR (160:144)

[Genesis]
custom_aspect_ratio_1=4:3      ; 256:224, Border Off
custom_aspect_ratio_2=10:7     ; 320:224, Border Off
;custom_aspect_ratio_1=112:81  ; 280:243, Border On
;custom_aspect_ratio_2=344:243 ; 344:243, Border On

[MegaCD]
custom_aspect_ratio_1=4:3      ; 256:224, Border Off
custom_aspect_ratio_2=10:7     ; 320:224, Border Off
;custom_aspect_ratio_1=112:81  ; 280:243, Border On
;custom_aspect_ratio_2=344:243 ; 344:243, Border On

[NeoGeo]
custom_aspect_ratio_1=10:7     ; 320:224
;custom_aspect_ratio_2=19:14   ; 304:224 (not necessary)

[NES]
custom_aspect_ratio_1=4:3      ; 256:224

[SMS]
;Use Original Aspect Ratio with Border Off for 1:1 PAR in SMS mode (need 256/248 width fix commits)
;custom_aspect_ratio_1=32:21   ; 256:192, SMS, Border Off (2048:1344, wider than 1920)
;custom_aspect_ratio_2=31:21   ; 248:192, SMS, Border Off (1984:1344, wider than 1920) (BG: Cut after 256/248 width fix commits)
;custom_aspect_ratio_1=282:239 ; 282:239, SMS, Border On, square PAR (obsolete after 256/248 width fix commits)
;custom_aspect_ratio_2=329:239 ; 282:239, SMS, Border On (wider than 1920) (obsolete after 256/248 width fix commits)
custom_aspect_ratio_1=10:9     ; 160:144, Game Gear, square PAR
custom_aspect_ratio_2=11:9     ; 160:144, Game Gear, wider PAR

[SNES]
custom_aspect_ratio_1=4:3      ; 256:224, use for most games
custom_aspect_ratio_2=896:717  ; 256:239, use for Dragon Quest V
;custom_aspect_ratio_2=8:7     ; 512:224, use for Secret of Mana 
;custom_aspect_ratio_2=16:21   ; 512:448, use for Radical Psycho Machine Racing (USA)

[TGFX16]
custom_aspect_ratio_1=15:11    ; 270:231, Overscan Hidden
custom_aspect_ratio_2=100:77   ; 360:231, Overscan Hidden, use for R-Type & Daimakaimura
;custom_aspect_ratio_1=162:121 ; 270:242, Overscan Visible
;custom_aspect_ratio_2=144:121 ; 360:242, Overscan Visible, use for R-Type & Daimakaimura

Posted: **Sat Jan 30, 2021 5:36 pm**

Thanks for that list!

I'm wondering whether this at some point could become integrated into the Mister framework. Given you only need 3 known variables for these calculations, the Mister could in theory calculate AR at runtime. I'm not saying these custom aspect ratios should be forced on the user but I see no reason why this couldn't become a feature auto-suggesting integer scaled aspect ratios. This would solve the issue of being limited by 2 AR's per core and would allow AR's per game as they are calculated dynamically.

Posted: **Sun Jan 31, 2021 5:19 am**

morf77 wrote: ↑Sat Jan 30, 2021 5:36 pm I'm wondering whether this at some point could become integrated into the Mister framework.

Depending on how it's implemented, it could also solve the problem of e.g. Genesis games switching from 256 to 320 width modes. Currently, you have to manually toggle each time if you want to maintain integer scaling horizontally (amusingly, 10:7 works as integer scaling for both modes at 1080p).

I've noticed custom aspect ratios don't seem work properly with SMS games as of the most recent released build. Even taking into account the 256/248 horizontal inconsistency (there's a thread in the SMS category regarding this), something isn't right. Despite having vscale=1, changing the aspect ratio seems to somehow also change vertical resolution via the scaler. None of the appropriate ratios give correct results. I think there's some issue that will need correcting before custom ARs will work in that core, at least with Master System (Game Gear seems to be fine with default settings at a glance)

Posted: **Sun Jan 31, 2021 3:32 pm**

Genesis has a separate setting for 320 and 256 resolution aspect ratios, doesn't it? I think only the main setting has custom ratios though.

Regarding the SMS, changing the aspect ratio makes no difference to the vertical resolution on my system. I have what appear to me to be consistent square pixels on the default setting, and I can get 6:5 pixels by setting a custom aspect ratio of 8:5 on 1080p. I think maybe the problem you're having comes from using the scandoubler? The SMS's vertical resolution is 192. If you turn the scandoubler on, the core puts out an image that is 384 pixels tall. The scaler then works on whatever the core is putting out, multiplying it by the largest integer that doesn't give a vertical resolution higher than the resolution the mister is set to. So on 1080p, it multiplies the normal signal by five for a vertical resolution of 960. The scandoubled image is multiplied by two for a vertical resolution of 768 (4 times the normal signal rather than 5). The "original" setting should still give a 4:3 aspect ratio and a 1:1 pixel aspect ratio, but 8:5 will no longer give a clean integer horizontal upscale. I think most other cores don't do this because their vertical upscale will be by an even number so the scandoubler makes no difference to the final vertical resolution.

Another thing with the SMS is the 248/256 issue that you mentioned. I made some code to add a menu option for consistent horizontal resolution, and that has been pulled into the main version's code, but not actually released yet - my pull request didn't include a build because I wasn't sure if I was supposed to include one. There is a build on my fork now (SMS_20210124.rbf), but unless you've sought that out then the 256/248 problem won't be solved on your mister which might be why you're getting incorrect results.

Posted: **Sun Jan 31, 2021 5:29 pm**

Edit: OK, my original 720p settings just now worked perfectly for integer scaling in both 256 and 248 modes on the current core (without the 248/256 fix in yet). I don't know what happened but I'm going to check 1440p as well now.

Edit 2: Most of the below is moot. The problem only appears to occur for me at 1440p resolution. 720p custom aspect ratios appear to work as intended. Original Aspect Ratio does work for integer scaling in 256x modes, but 248x modes (which are more common in gameplay in my experience) look terrible on this setting. Seems like the new build with the 256/248 fix might render some of this less relevant since it should be integer scaled by default in Original.

---

Quick clarification: I can't confirm the vertical resolution changes, but when setting certain custom aspect ratios (with vscale=1), my monitor loses sync temporarily, which doesn't happen when applying custom aspect ratios on any other core. I don't use scandoubler on any cores, currently, so that shouldn't be an issue. I don't know exactly what's wrong, but using the same process I've used to get good results for most other cores has consistently not given integer scaled pixels for SMS thus far. I created separate modes for 248 and 256 since the core actually fully switches resolution in the current build instead of just masking the left column, but neither work.

8:5 matches my calculation for SMS, but I haven't tested 1080p modes yet. I usually am capturing either 720p while playing on CRT, or playing on LCD 1440p, and in both cases I've been unable to find the right values for integer scaling. I can see interpolation when I switch the custom scaler on or off.

Normally all I have to do is find the resolution of a screenshot, use the pixel clock to generate the aspect ratios, then use them. Here are the values I've tested the most, for a 720p resolution:

[SMS]
custom_aspect_ratio_1=4:3 ; 256:192, Border Off
custom_aspect_ratio_2=31:24 ; 248:192, Border Off
;custom_aspect_ratio_2=282:239 ; 282:239, Border On

When I set the 31:24 custom AR in e.g. gameplay in a game that masks the 8 left pixels, I do not get integer scaling. The monitor loses sync for a moment. I don't appear to get integer scaling when setting 4:3 on a 256 width screen either. I thought may I could work around the issue by using Border On since the resolution seems to be consistent in this mode, but I still couldn't get integer scaled pixels.

Here is the calculation I made. Something is weird with this core. I'm going to try it with your build now.

Code: Select all

Pixel clock in mhz
5.370

Visible pixels
256

Visible lines
192

Video type

NTSC

Calculation Results:
Dots per line: 280.000000, Lines: 240.000000 Standard: NTSC
Aspect ratio: (32:21) (Floating Point:1.523810  Fraction:1.523810)
Square aspect ratio: (35:24)
480p
Integer aspect ratio for 480p (2x and 2x): (4:3)
720p
Integer aspect ratio for 720p (3x and 3x): (4:3)
1080p
Integer aspect ratio for 1080p (6x and 5x): (8:5)
1200p
Integer aspect ratio for 1200p (7x and 6x): (14:9)
1440p
Integer aspect ratio for 1440p (8x and 7x): (32:21)
1576p
Integer aspect ratio for 1576p (9x and 8x): (3:2)

Code: Select all

Pixel clock in mhz
5.370

Visible pixels
248

Visible lines
192

Video type

NTSC

Calculation Results:
Dots per line: 280.000000, Lines: 240.000000 Standard: NTSC
Aspect ratio: (31:21) (Floating Point:1.476190  Fraction:1.476190)
Square aspect ratio: (35:24)
480p
Integer aspect ratio for 480p (2x and 2x): (31:24)
720p
Integer aspect ratio for 720p (3x and 3x): (31:24)
1080p
Integer aspect ratio for 1080p (6x and 5x): (31:20)
1200p
Integer aspect ratio for 1200p (7x and 6x): (217:144)
1440p
Integer aspect ratio for 1440p (8x and 7x): (31:21)
1576p
Integer aspect ratio for 1576p (9x and 8x): (93:64)

Now I need to double-check that the scandoubler is really off! I might have accidentally toggled it...

Posted: **Sun Jan 31, 2021 5:42 pm**

OK, the problem appears to only occur at 1440p. When I set a custom Aspect Ratio of 32:21, the LCD monitor loses sync for a second, and the pixels are not integer scaled. Scandoubler is off. None of my calculated settings appear to integer scale correctly at 1440p. I think the other resolutions may be unaffected? This is still with the existing build. Gonna drop the new build in to see if that makes any difference.

Posted: **Sun Jan 31, 2021 6:01 pm**

Alright, custom aspect ratios do not appear to work correctly in the SMS core at 1440p. However, in the build posted by Yim above (SMS_20210124.rbf), Aspect Ratio = Original gives integer scaled pixels by default and the 256/248 mode fix allows this to apply in gameplay as well. This is a good band-aid for now.

Still, there's an issue, and it's weird. Would anyone be able to confirm the issue on their end? To reproduce, set vscale=1, load the SMS BIOS (256x width), then apply 32:21 as a custom aspect ratio. The vertical resolution of the game changes over the scaler (?) and the ratio does not appear to be correct as the result is not integer scaled. To be clear, none of the custom aspect ratios appear to work entirely correctly at 1440p in this core, but this aspect ratio should be the easiest to tell whether it's working.

Posted: **Mon Feb 01, 2021 12:03 am**

I don’t have a screen capable of 1440 so I can’t test anything, but I notice that on integer scaling at that resolution 32:21 should give a resolution of 2048x1344. According to this post 2048 is the maximum mister can put out horizontally, so maybe it’s to do with running so close to the edge?

Actually, looking at mister.ini, video mode 12 gives 1920x1440@60. Is that what you’re set to? If so, then I reckon the problem is you’re asking for a horizontal resolution that’s higher than the mister is running at, so it’s scaling the image down to 1920 horizontal, messing up the integer scaling, and also scaling the vertical down to 1260 to keep the aspect ratio, which would be why you’re seeing a vertical resolution change. That’d mess up vertical integer scaling as well, so maybe it’s scaling down to 1152 to preserve that and rescaling the horizontal to match. Either way, unless you’re using a custom video mode I reckon this is probably the problem. The solution would be to make a custom video mode with a 2048x1440 resolution, if you’re not doing that already. That’s not a standard aspect ratio though, so you might have problems with your monitor rescaling it, depending on the monitor.

I think it’s an issue with SMS and not other systems because SMS runs such a wide picture.

Posted: **Mon Feb 01, 2021 6:52 pm**

Yim, you rock! Your assessment is spot on. This has an implication for the aspect ratio calculator linked in the original post here, as the values I entered were all generated via that calculator. It seems to potentially not be respecting the 4:3 1920 by 1440 picture in the default video_mode for 1440p and expecting a wider aspect.

Posted: **Tue Feb 02, 2021 12:56 am**

Unfortunately I'm using a monitor that isn't able to run the video_mode=12 default to replicate this issue.

The 1440p video_mode I'm using

Code: Select all

video_mode=1920,128,208,344,1440,1,3,56,234000

Not having this issue with above video_mode. Maybe this could be explained by different timings?

http://tinyvga.com/vga-timing/1920x1440@60Hz

Video_mode 12 seems to correspond with video_mode=1920,48,32,80,1440,2,4,38,185203

If I'm understanding this correctly and people can confirm the Vesa timing to give proper integer AR, the video_mode=12 exceeds the horizontal limit of the modeline as pointed out by Yim whereas the Vesa timing can handle this due to a higher pixel clock and HTOTAL. The video_mode=12 is there I suppose because of its pixel clock being less out of spec. The Vesa 1440p timing probably pushes the misters pixel clock capabilities a bit too far.

For the calculator in this scenario, I could add a notice saying 1440p AR won't work with the default video_mode=12 and requires a higher pixel_clock video_mode displaying the 1440p Vesa timing as default. Another alternative is to suggest using a multiplier one step below the 1440p res, in this example requiring a 1792x1344 video_mode.

Posted: **Tue Feb 02, 2021 4:41 am**

Updated python script below, this includes a warning in case video_mode=12 would cause an issue with 2048 width limit required pixel_clock limits and suggests an alternative custom video_mode.
The online calculator will be modified reflecting these changes.

Code: Select all

import math
import numpy as np
from fractions import Fraction

def find_nearest_h(integer_lines, visible_pixels, proper_ratio, v_multi):
    last_remainder = 1
    r = 1
    for x in range(-5,6):
        integer_pixels = visible_pixels * (v_multi + x)
        try:
          diff = abs((integer_pixels / integer_lines) - proper_ratio)
          if (diff < last_remainder):
              last_remainder = diff
              r = x
        except:
              return 1
    return r

def find_gcm(x,y):
    for i in range(30,0,-1):
       if (np.mod(x,i) == 0 and np.mod(y,i) == 0):
          return i
    return 1

print("Mister Aspect Ratio Calculator")
print("Expected format: <visible dots> <visible lines> <dot clock in mhz>")

NTSC_CONST = "704.0/13.5"
PAL_CONST = "702.0/13.5"

ACTION_SAFE= 0.035
TITLE_SAFE = 0.05

LINES_NTSC = 240.0
LINES_PAL = 288.0


pixel_clock = float,input("Pixel clock: ")
visible_pixels = float,input("Visible pixels: ")
visible_lines = float,input("Visible lines: ")
video_type  = input("Video type (NTSC/PAL):")
clockstr = str(pixel_clock[1])
pixelstr = str(visible_pixels[1])
linestr = str(visible_lines[1])
print("Calculating for visible area of "+pixelstr+" x "+linestr+" at "+clockstr+" mhz pixel clock")

if video_type == "NTSC":
  pix_per_line = round(float(pixel_clock[1]) * 704.0 / 13.5)
  video_lines = LINES_NTSC
else:
  pix_per_line = round(float(pixel_clock[1]) * 702.0 / 13.5)
  video_lines = LINES_PAL

print("Dots per line: %f, Lines: %f Standard: %s\n" % (pix_per_line, video_lines,video_type))

horizontal_aspect = 4.0 * float(visible_pixels[1]) / pix_per_line
vertical_aspect   = 3.0 * float(visible_lines[1]) / video_lines

arx=0
ary=0
proper_ratio = horizontal_aspect / vertical_aspect


ratiofraction = Fraction.from_float(proper_ratio).limit_denominator(4096)
x = ratiofraction.numerator
y = ratiofraction.denominator


print("Aspect ratio: (%d:%d) (Floating Point:%f  Fraction:%f)" % (x, y, proper_ratio, (x / y)))

arx = 0
ary = 0


fractratio = pix_per_line / float(visible_lines[1])
ratiofraction = Fraction.from_float(fractratio).limit_denominator(4096)
xres = ratiofraction.numerator
yres = ratiofraction.denominator

print("Square aspect ratio: (%d:%d)" % (xres, yres))

res = [480, 720, 1080, 1200, 1440, 1576]


for i in range(0,6):
        arx = 0
        ary = 0
        v_multi = int(int(res[i]) / int(visible_lines[1]))
        integer_lines =float(visible_lines[1]) * v_multi

        nearest_h = find_nearest_h(integer_lines, int(visible_pixels[1]), proper_ratio, v_multi)
        integer_pixels = float(visible_pixels[1]) * (v_multi + nearest_h)


        if integer_lines > 0:
          fractratio = integer_pixels / integer_lines
          ratiofraction = Fraction.from_float(fractratio).limit_denominator()
          xres = ratiofraction.numerator
          yres = ratiofraction.denominator
        else:
          print("zero or negative")
          xres = 1
          yres = 1

        scaledwidth=int(v_multi + nearest_h) * int(visible_pixels[1])
        scaledheight=int(v_multi + nearest_h) * int(visible_lines[1])
        near1440Hor=int(v_multi) * int(visible_pixels[1])
        near1440Vert=int(v_multi) * int(visible_lines[1])
        if video_type == "NTSC":
           framerate = 60
           blankperiod = 1.172
        else:
           framerate = 50
           blankperiod = 1.188
        reqclock = float(scaledwidth) * float(integer_lines) * float(framerate) * float(blankperiod)

        print("Integer aspect ratio for %dp (%dx and %dx): (%d:%d) minimum required pixel clock: %f mhz" % (res[i],(v_multi + nearest_h),v_multi, xres, yres, reqclock/1000000))



        if int(res[i])==1440:
           if reqclock/1000000 > 185.203 :
              print("!! WARNING !! %dx integer scaling will not run with video_mode=12 and will require a custom_video" % (v_multi + nearest_h))
              print("!! WARNING !! To enable %dx integer scaling set a custom 1440p video_mode for this core with at least %f mhz pixel clock" % (v_multi+nearest_h, reqclock/1000000))
              print("!! WARNING !! Or use %dx integer scaling requiring a (%dx%d) video_mode." % (v_multi, near1440Hor, near1440Vert))   
              print("!! WARNING !! eg video_mode=1792,128,200,328,1344,1,3,46,204800")

These warnings include suggestions for other video_modes that might not work in all scenarios. From a post on the atari forum:

-Frequencies
* 20MHz : Minimal frequency set by the MiSTer software
* 150MHz : This is the designed frequency target for the scaler, to support 1920x1080. The scaler was optimised to get [almost] no timing errors at that frequency.
* 165MHz : This is the maximum frequency supported by the ADV7513 HDMI encoder.
* 200MHz : This is the limit set by the MiSTer software.

Frequencies far beyond 150MHz are not guaranteed to work, may not work on all cores, or when the FPGA or HDMI encoder is too warm.
It is sometimes possible to lower pixel frequency by reducing blanking and synchro times.

Posted: **Tue Feb 02, 2021 6:38 am**

I think the issue is that mode 12 is a 4:3 aspect ratio at 1440p, so it’s not that 1440p isn’t supported, it’s that wider aspect ratios that give horizontal resolutions above 1920 won’t fit. Apparently horizontal resolutions above 2048 aren’t supported by the MiSTer at all. I think the same issue would apply for mode 13, which is 2048x1536, also 4:3.

Posted: **Tue Feb 02, 2021 7:39 am**

I'm a bit confused whether horizontal 2048 is supported or not seeing this post viewtopic.php?p=626#p626 I get the impression it can work upto 2048 but not above. Seems like pixel clock is more of a limiting factor upto that point. The 8x integer scaling with 32:21 aspect ratio in this test case scenario results in exactly 2048 pixels not above.

My assumption is the horizontal sync is getting messed up because the pixel clock used by video_mode=12 doesn't allow it at 2048 pixels. Resulting in shimmering. Interested to hear whether this aspect ratio of 32:21 on the SMS core can work with a custom video_mode=1920,128,208,344,1440,1,3,56,234000 or 1792,128,200,328,1344,1,3,46,204800. These both have higher pixel clocks than the default video_mode=12, allowing for more horizontal width.

Both of these are beyond the misters pixel clock limit so it might not be possible or we need to find a video_mode with pixel clock that does support it.

TLDR: the 185.203 mhz pixel clock of video_mode=12 is too low to achieve 2048 horizontal res. It would require at least 193mhz pixel clock to support 2048 pixels if I'm not mistaking (at 60hz NTSC)

Code: Select all

Pixel Clock Equation: 

Hres * Vres * Framerate * (1 +0.172 ( NTSC Blanking Period)) = 2048 * 1344 * 60 * 1.172 = 193.5566 mhz

This pixel_clock can be reduced by blanking and synchro times as stated before. During my tests I found this video_mode for the SMS 1440p 32:21 AR but might not work on all displays (it does work on my pc crt):

Code: Select all

video_mode=2048,48,32,80,1440,2,4,38,196350

I've tweaked the generated video_mode manually by lowering the syncro/blanking on it resulting in a reduced pixel clock: originally 292.7 mhz (pixel clock of generated 2048x1440@60 modeline), lowered to 196.35 mhz by manual editing. No guarantees this will work on your display, you will have to experiment yourself to find out what works.

Script and online calculator have been modified to check the pixel_clock required for 1440p aspect ratio's and displays a warning when the pixel_clock of mode=12 doesn't support the integer scaled width.

Posted: **Tue Feb 02, 2021 2:08 pm**

I'm still struggling to understand the workings of the pixel clock, but I think this boils down to resolution. I set up a couple of very wide custom aspect ratios for my SMS core and gave them a shot running on video mode 8 (1920x1080). At 1080p the SMS's vertical resolution of 192 is multiplied five times to 960.

28:15 - this works out to 1792x960, so it fits inside the 1920 horizontal resolution of mode 8. It displays as expected, "perfect" pixels, each consisting of a 7x5 rectangle of screen pixels

32:15 - this works out to 2048x960, too wide for mode 8. This displayed at the full width of the screen with no cropping, but I got a vertical resolution change, just like meauxdal was getting in 1920x1440. I'm not sure what exact vertical resolution it changed to, but I'd expect it to be 900 to maintain the 32:15 aspect ratio. With this image I no longer had integer scaling.

I think in the end it's a matter of finding an aspect ratio that gives a final image resolution that fits in the screen resolution. For SMS on 1920x1440, the solution might be to change the border mode to only include vertical borders, no extra horizontal. That would give a base image of 256x240 which could then be scaled up six times vertically and seven times horizontally to 1792x1440, which would be fairly close to correct but would fit within the screen resolution. The border mode could also be left with say eight pixels of horizontal border on each side, which would scale up seven times to 1904 horizontal, still within the limit. I'm not sure on what basis the size of the overscan border of the SMS was established, though. Maybe it is the size it is now for accuracy reasons or something, so it might not be desirable to change it for this reason.

Depending on the monitor, the best solution for 1440p might actually be to run the mister at 720p, which doubles cleanly to 1440. If the monitor's upscaler doesn't mess up the image too much in the process that would allow more flexibility with aspect ratio width.

Posted: **Tue Feb 02, 2021 9:12 pm**

SMS using video_mode=12 is in an acceptable state using the build Yim posted earlier in this thread. The Aspect Ratio: Original setting gives a 4:3 ratio by default, which results in 1:1 PAR and horizontal integer scaling when vscale=1. It would be nice to have a wider mode for certain games (Game Gear conversions come to mind) that works with 1920x1440, but given "perfect" pixels are achievable in an accurate AR, I'm pretty happy with the status quo. It's just a little confusing, so I'm glad this thread exists in the interest of hashing out these quirks!

(I tried using morf's 2048 pixel width video_mode on my LCD monitor, and while it did sync, it scaled oddly and nullified any benefit integer scaling might have had before monitor scaling)

Game Gear using the SMS core is interesting. You get a 4:3 PAR using AR: Original with this core, which also integer scales horizontally using vscale=1. This is accurate to the original console, but some games will look better with custom aspect ratios of either 10:9 (square PAR) or 11:9 (compromise between 1:1 PAR and 4:3 PAR). Tempo Jr. is a good example - CD-shaped pickups look horizontally stretched using AR: Original, but are perfectly square/round at 10:9.

Posted: **Tue Feb 02, 2021 10:10 pm**

Edit: I can't recommend this specific mode, see viewtopic.php?p=17641#p17641

Just now done a test in the SMS core (Yim build) with the following mode:

video_mode=2560,48,32,80,1440,3,5,33,241500

This is 2560x1440, with a pixel clock of 241.500MHz, so, pretty well over-clocked past the target timing. I didn't test long enough to confirm whether the sync would remain stable, but it did at least sync, display correctly, and remain synced when applying e.g. 32:21 custom aspect ratio. Of course, I also confirmed that horizontal integer scaling was in effect.

I'm not sure if a mode like this is "safe". Are there risks to the MiSTer hardware if pushing the limits this hard?

Posted: **Wed Feb 03, 2021 12:10 am**

meauxdal wrote: ↑Tue Feb 02, 2021 10:10 pm Just now done a test in the SMS core (Yim build) with the following mode:
video_mode=2560,48,32,80,1440,3,5,33,241500
I'm not sure if a mode like this is "safe". Are there risks to the MiSTer hardware if pushing the limits this hard?

Interesting, this confirms the pixel clock is more of a limit than the horizontal resolution is for the Mister, but that's just a detail because they mutually affect each other. Concerning safety there is a thread on the atari forum addressing this https://www.atari-forum.com/viewtopic.php?f=117&t=32542

As I understand it the Cyclone V is industrial grade and can go up to 100°C. It also has an I2C bus which you could use to monitor temperatures. I wouldn't recommend pixel clocks like that but if you have a fan, heatsink and it remains stable, doesn't blow up in your face burning your house down who am I to say you shouldn't? Keep in mind though the results of using such extreme video_modes might not be the same on all cores and could cause inconsistencies (disregarding the safety concern).

Yim wrote: ↑Tue Feb 02, 2021 2:08 pm I'm still struggling to understand the workings of the pixel clock, but I think this boils down to resolution. I set up a couple of very wide custom aspect ratios for my SMS core and gave them a shot running on video mode 8 (1920x1080). At 1080p the SMS's vertical resolution of 192 is multiplied five times to 960.

28:15 - this works out to 1792x960, so it fits inside the 1920 horizontal resolution of mode 8. It displays as expected, "perfect" pixels, each consisting of a 7x5 rectangle of screen pixels

32:15 - this works out to 2048x960, too wide for mode 8. This displayed at the full width of the screen with no cropping, but I got a vertical resolution change, just like meauxdal was getting in 1920x1440. I'm not sure what exact vertical resolution it changed to, but I'd expect it to be 900 to maintain the 32:15 aspect ratio. With this image I no longer had integer scaling.

I think in the end it's a matter of finding an aspect ratio that gives a final image resolution that fits in the screen resolution.

I understand what you're saying Yim the only problem with these tests is I'm not sure what pixel_clock mode 8 is using. It could be mode 8 has a pixel clock preventing it to upscale to those dimensions. An interesting test would be to use a video_mode that wouldn't fit the upscaled res (from AR setting) but has a high enough pixel clock to allow those upscales. The SMS core with a custom 1920x1440 video_mode and a pixel_clock above 193.5 with AR 32:21 (@60hz NTSC) could answer this. On my PC CRT this seems to work but I'd love to see someone replicate a similar test on their display. I just want to fully understand what sets the limit for the custom_aspect_ratio upscaling. Video_mode defined resolution or pixel_clock. Not for the sake of who's right or wrong but for the benefit of our understanding.

You could also test this at lower resolutions by calculating the minimum required pixel clock for the AR upscaled resolution. The formula is quite simple:

Code: Select all

reqclock = scaledwidth * scaledheight * framerate * (1+  blankperiod)

The blanking period for NTSC is 17.2% and 18.8% for PAL.
Eg for a 1920x1440 at 60 hz NTSC it would render 1920*1440*60*1.172 = 194.420736 mhz minimum pixel_clock required for this resolution.

If anyone knows the mode 8 pixel clock I could also calculate the minimum required pixel clock and tell you whether that was the limiting factor or not in your tests.

Think of pixel_clock as bandwith for the video stream. A wider resolution requires more bandwith. So do higher framerates or faster blanking periods and synchro's. When you multiply the pixel clock fequency with the color depth of the signal you get the troughput in Mbps.

I'm considering to display these minimum required pixel_clocks in the AR calculator as a default and will create a github for these tools in the near future.

Posted: **Wed Feb 03, 2021 2:30 am**

Yim wrote: ↑Tue Feb 02, 2021 2:08 pm I'm still struggling to understand the workings of the pixel clock, but I think this boils down to resolution. I set up a couple of very wide custom aspect ratios for my SMS core and gave them a shot running on video mode 8 (1920x1080). At 1080p the SMS's vertical resolution of 192 is multiplied five times to 960.

28:15 - this works out to 1792x960, so it fits inside the 1920 horizontal resolution of mode 8. It displays as expected, "perfect" pixels, each consisting of a 7x5 rectangle of screen pixels

32:15 - this works out to 2048x960, too wide for mode 8. This displayed at the full width of the screen with no cropping, but I got a vertical resolution change, just like meauxdal was getting in 1920x1440. I'm not sure what exact vertical resolution it changed to, but I'd expect it to be 900 to maintain the 32:15 aspect ratio. With this image I no longer had integer scaling.

The pixel_clock of video_mode=8 runs at 148.5. I calculated the minimum required pixel clock for 2048x960 to be 138.2547 mhz. So it seems the pixel clock is indeed not the cause in this scenario (or I'm calculating the required frequency wrongly). I don't know where the 32:15 aspect ratio comes from though, I can't reproduce it as an integer scaled AR with the calculator.

Code: Select all

Calculating for visible area of 256 x 192 at 5.37000 mhz pixel clock
Dots per line: 280.000000, Lines: 240.000000 Standard: NTSC

Aspect ratio: (32:21) (Floating Point:1.523810  Fraction:1.523810)
Square aspect ratio: (35:24)

Integer aspect ratio for 1080p (6x and 5x): (8:5) minimum required pixel clock: 103.691059 mhz

The mister is using this video_mode for the 8 default setting:

video_mode=1920,88,44,148,1080,4,5,36,148500

This seem to be the standard VESA modeline for 1920x1080@60

For reference these are the video_modes of the default modes at time of writing:

Code: Select all

vmode_t vmodes[] =
{
    { { 1280, 110,  40, 220,  720,  5,  5, 20 },  74.25  },     //0
    { { 1024,  24, 136, 160,  768,  3,  6, 29 },  65     },         //1
    { {  720,  16,  62,  60,  480,  9,  6, 30 },  27     },           //2
    { {  720,  12,  64,  68,  576,  5,  5, 39 },  27     },            //3
    { { 1280,  48, 112, 248, 1024,  1,  3, 38 }, 108     },        //4
    { {  800,  40, 128,  88,  600,  1,  4, 23 },  40     },         //5
    { {  640,  16,  96,  48,  480, 10,  2, 33 },  25.175 },       //6
    { { 1280, 440,  40, 220,  720,  5,  5, 20 },  74.25  },    //7
    { { 1920,  88,  44, 148, 1080,  4,  5, 36 }, 148.5   },      //8
    { { 1920, 528,  44, 148, 1080,  4,  5, 36 }, 148.5   },     //9
    { { 1366,  70, 143, 213,  768,  3,  3, 24 },  85.5   },        //10
    { { 1024,  40, 104, 144,  600,  1,  3, 18 },  48.96  },      //11
    { { 1920,  48,  32,  80, 1440,  2,  4, 38 }, 185.203 },    //12
    { { 2048,  48,  32,  80, 1536,  2,  4, 38 }, 209.318 },    //13
};

Posted: **Wed Feb 03, 2021 3:26 am**

I guess I’ve been wrong about 2048 being a hard limit for the mister’s horizontal resolution. Whoops.

I think I’m starting to get my head around this pixel clock thing, but it’s still pretty confusing. From the MiSTer GitHub, video.cpp, the full details of mode 8 are:

Code: Select all

 { { 1920,  88,  44, 148, 1080,  4,  5, 36 }, 148.5   }, //8

As I understand it, the meaning of those parameters are:

Horizontal resolution: 1920 pixels
Horizontal front porch (the portion of the scanline which is not shown and occurs after the displayed image): 88 pixels
Horizontal synch (the time taken to reset the horizontal position from end of line to start of line): 44 pixels
Horizontal back porch (the portion of scanline not shown occurring before the displayed image): 148 pixels
Vertical resolution: 1080 lines
Vertical front porch (non-displayed lines occurring after displayed image): 4 lines
Vertical synch (time taken to reset from bottom of image to top): 5 lines
Vertical back porch (non-displayed lines occurring before displayed image): 36 lines
Pixel clock: 148.5 MHz

Adding up all the horizontal components and multiplying by the vertical components and by 60 for the frame rate gives 148.5 million, so I guess that’s where the pixel clock comes from. In which case the resolution could be increased without changing the pixel clock by decreasing the front and back porches? This would probably mess up CRTs because they actually use the blanking period, but I think would be ok on digital displays. Alternatively the pixel clock could be upped, but this would also increase the frame rate? Sorry if this is basic stuff, I’m trying to understand it myself rather than looking to explain what others already know.

Not for the sake of who's right or wrong but for the benefit of our understanding.

100 per cent. I am not looking for a competition. This is friendly cooperation.

Edit: your latest post came while I was working on this one morf, so a lot of what I’ve just said is redundant. The 32:15 aspect ratio is one I came up with to deliberately exceed the 1920:1080 resolution of mode 8. It’s an eight times horizontal integer upscale and a five times vertical upscale. The resulting resolution is 2048x960, which simplifies to 32:15, and the pixel aspect ratio is 8:5. So far as I can tell, the mister scales it down to 1920x900 to fit within the 1920x1080 resolution. That still gives a PAR of 8:5, but instead of being perfect 8x5 pixel rectangles they are 7.5x4.6875 rectangles. Since modern displays can’t do fractional pixels this results in a mix of rectangles that are 7x4, 7x5, 8x4, and 8x5, so the picture is uneven. I think this replicates at 1080p the problem meauxdal was having at 1440.

Posted: **Wed Feb 03, 2021 3:38 am**

Yes tweaking those blanking and synchro numbers can have different results on different displays. When you tweak the blanking period or synchro in a video_mode line you will see the mister will calculate the new pixel_clock (with video_info). It will use this calculated value and overrule whatever your video_mode is still saying in your ini file.

I'm guessing with custom aspect ratio in the mister code these upscaled resolutions aren't achieved by tweaking video_modes though, I think it takes the pixel_clock it's running at (from your video_mode line) and raises it. This would result into a higher res image. This is speculation though and I could be wrong, I don't know how it's dealt with in source code.

Posted: **Wed Feb 03, 2021 3:55 am**

The pixel_clock of video_mode=8 runs at 148.5. I calculated the minimum required pixel clock for 2048x960 to be 138.2547 mhz. So it seems the pixel clock is indeed not the cause in this scenario (or I'm calculating the required frequency wrongly).

I think you’re right if you’re looking to have the MiSTer output 2048x960, the problem is that unless you’re using a 2048x960 display (or a display that can have its internal scaling turned off and only use part of the screen) this will result in the display distorting the image by scaling it. The video mode controls the whole image, including the black borders that you get with integer scaling, so those extra pixels need to be factored in.

In terms of reducing the blanking period, I should have said transferring pixels from the blanking period to the active display. So if you wanted to modify mode 8 to give 2048 horizontal at the same pixel clock, you could reduce the back porch by 128 and increase the horizontal resolution by the same amount:

1920 2048, 88, 44, 148 20, 1080, 4, 5, 36, 148.5

I think (assuming removing the blanking doesn’t break anything) this would give a good 2048x960 active image within a 2048x1080 total image at the same pixel clock and frame rate, but then my 1920x1080 tv would downscale it to fit (or possibly crop, I guess) and distort the image again.

Posted: **Wed Feb 03, 2021 4:10 am**

I tested the mode you posted and on my CRT it's running at 148.3 mhz pixel clock working fine, just a little distortion in the image and displacement. I guess for LCD users it would be too much.

Posted: **Wed Feb 03, 2021 4:21 am**

Good outcome! I was only thinking of digital displays rather than CRTs, but if it works that’s good. I think more stuff gets done by the TV in the back porch than the front, so if there were problems it might make sense to take a few pixels away from the front porch and put them in the back (maybe 2048, 30, 44, 78).

Is it necessary to have so much upscaling on a CRT, though? I thought a CRT would do an analogue upscale to fill the screen, plus or minus borders that could maybe be tweaked with knobs on the set. Native core resolution should be enough. I haven’t touched a CRT in years though, so I could have it all wrong.

Posted: **Wed Feb 03, 2021 4:29 am**

On a CRT it's a bad idea. Recommend to run with scandoubler on CRT's and use low resolutions. Only for some TATE arcade games this stuff can become useful (vertical scanlines). My mister is currently only hooked up to a PC Crt but it's nice to be able to test these upscales.

Posted: **Wed Feb 03, 2021 3:40 pm**

Just an update regarding the 2560x1440 mode I posted earlier in this thread. I did a bit of testing on GBA with this video mode, the core with the most to gain from a 16:9 aspect ratio since it has a native 3:2 picture. Unfortunately, while this issue is not visible using 32:21 scaling in the SMS core, there is some kind of image issue around the left and right edges of the visible GBA picture. The game I used to test was Castlevania: Aria of Sorrow, and the text box at the bottom of the file select screen was rendering incorrectly at the horizontal edges.

Furthermore, at least on my monitor, I would get semi-random hiccups in the sync, which gave me a black screen for 1-2 seconds. Every few minutes it would lose sync momentarily. CRT still showed the correct image, and using the same aspect ratio at 720p over the HDMI scaler also showed no issue. Just wanted to add this in case anyone was thinking about using that mode I posted. I personally can't recommend it!

MiSTer FPGA Forum

MiSTer Aspect Ratio Calculator

MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator

Re: MiSTer Aspect Ratio Calculator