Software Support > GroovyMAME
Trying to create monitor presets for KT-2914 (Betson-Kortek) MultiSync
8BitMonk:
I was able to do some more testing tonight and think I've made good progress towards troubleshooting the Mortal Kombat issue.
First thing was to recreate the issue in ArcadeOSD and try to compensate with the geometry controls. I ran a log of mk and then looked at the modeline values gm was applying...
gm starts with the basic super resolution 2560x256_60 16.74KHz 60.00Hz:
"2560x256_60 16.74KHz 60.00Hz" 55.31 2560 2680 2936 3304 256 259 262 279
then to match Mortal Kombat better calculates 2560x256_60 15.65KHz 54.71Hz:
"2560x256_60 15.65KHz 54.71Hz" 52.07 2560 2664 2912 3328 256 262 265 286
So this value is what I put into ArcadeOSD to match the issue and voila, it's janky.
As you can see it's bowed at the top and offset down and to the right just like when I run the game so time to try to compensate with geometry controls. I could easily center it but nothing I adjusted would change the bowing effect.
Since the Vres of Mortal Kombat is actually 54.81Hz I next tried dropping the Vres in ArcadeOSD settings from 256 to 254 and the bowing immediately goes away, 255 works as well. That fixes the geometry issue but as a side effect mk runs at 110% and it also affects games like 1943 that share that Vres, it looked a little blurry.
Since I couldn't come up with a universal solution and don't know how to make presets I decided to try an ini file for mk. Using the basic super resolution modeline "2560x256_60 16.74KHz 60.00Hz" 55.31 2560 2680 2936 3304 256 259 262 279 mk runs great though I'm sure it's not perfectly emulated since it's at 60hz. Oddly even though I only added mk.ini with this edit it applies it to every version of mk I run so mk2 and mk3 use it as well.
I tried the custom calculated gm value in an ini file with a minor alteration changing the 256 to 254 to prohibit the bowing like so: modeline "2560x256_60 15.65KHz 54.71Hz" 52.07 2560 2664 2912 3328 254 262 265 286 but it tells me it can't find a suitable resolution. I guess even though groovymame creates the custom modeline on the fly you can't do it from ini file, it must need to be added somewhere.
Hope that helps for troubleshooting Mortal Kombat res. Maybe with this info Calamity can come up with a modification to the preset or a more universal solution, or coach me on how to do it. At least I can use the mk.ini file with the basic super resolution in it as a temp fix.
8BitMonk:
Disregard my last couple posts, I just noticed I had left the monitor setting to arcade_15_25_31 so they'd apply to that setting and not Calamities custom preset. :banghead:
When I use Calamities preset values (below) and the monitor set to custom I get an 'out of range - ignoring' error when launching groovymame. It says it applies to the preset in bold, specifically 248.
crt_range0 15625-15900, 50-59.96, 7.800, 4.700, 10.600, 0.190, 0.191, 1.018, 0, 0, 192, 248, 448, 496
crt_range1 15625-15900, 59.98-80, 3.000, 4.700, 7.700, 0.190, 0.191, 1.018, 0, 0, 192, 248, 448, 496
crt_range2 16000-17200, 58-80, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 0, 0, 249, 256, 498, 512
crt_range3 18300-18800, 50-58, 8.300, 2.750, 9.000, 0.190, 0.191, 1.018, 0, 0, 257, 280, 514, 560
crt_range4 18800-19000, 50-80, 2.187, 4.688, 6.719, 0.140, 0.191, 0.950, 0, 0, 281, 320, 0, 0
crt_range5 24000-29000, 50-80, 2.020, 2.820, 6.460, 0.890, 0.148, 1.373, 0, 0, 384, 400, 0, 0
crt_range6 30000-34000, 50-80, 0.636, 3.813, 1.906, 0.020, 0.106, 0.607, 0, 0, 448, 496, 0, 0
crt_range7 34001-38000, 50-80, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 512, 600, 0, 0
I'll have to retest after figuring out why the second part of the split 15Khz preset is out of range.
Calamity:
Hi 8BitMonk,
Thanks for your report.
You're right, the preset is wrong, unfortunately nobody had reported it before. Try replacing it with this:
crt_range1 15625-16240, 59.98-80, 3.000, 4.700, 7.700, 0.190, 0.191, 1.018, 0, 0, 192, 248, 448, 496
The good thing is that GroovyMAME is smart enough to check these things and at least gives an error message. This was the error:
--- Code: ---(progressive_lines_max + hfreq_max * vertical_blank) * vfreq_min > hfreq_max
--- End code ---
The way it was before: crt_range1 15625-15900, 59.98-80, 3.000, 4.700, 7.700, 0.190, 0.191, 1.018, 0, 0, 192, 248, 448, 496
(248 + 15900 * (0.190 + 0.191 + 1.018) / 1000) * 59.98 = 16234 (we had 15900 as hfreq_max so we were out of range).
Thus increasing hfreq_max to 16240 fixes the range.
Regarding your issues with sound stuttering, I'd say you're forcing -syncrefresh in mame.ini. Don't do it, just keep -syncrefresh, -waitvsync and -triplebuffer as 0 (default), so GM can choose which one to use in each case.
Besides, I'd say you're using -frame_delay. Bear in mind -frame_delay *disables* sound synchronization. If the target refresh doesn't match the original with several decimal figures you'll have sound glitches for sure. The -frame_delay option has become popular but I want to remark that it is still experimental and it shouldn't be applied as a general option. It is recommended to enable it in a per game basis, trying to find the greater value that doesn't cause issues for that game and then creating a custom modeline (read: modeline, NOT crt_range) for that game to better tweak the frequency by manual fine tuning of the timings. So it is something you do once you have all up and running.
Regarding the problems with MK, notice the trick you did by reducing the active lines to 254 is not doing what you think it is. Windows 7 doesn't allow you to do that. The active lines/active horizontal size of the modeline must match the logical resolution, otherwise the modeline is ignored and the default timings will apply, that is why automatically the 60 Hz refresh is activated, it seems to be fixing the geometry but actually it's just picking another modeline. As you see the game runs at 110% so it's ignoring your timings.
This monitor is probably the most complicated monitor we have worked with, as we just noticed by the beginning of this thread. It behaves different depending on the vertical refresh, rather than just the horizontal frequency. For this reason, we had to divide the 15 kHz range in two subranges (50-59.96) (59.98-80). Maybe we need an extra subrange.
8BitMonk:
Hi Calamity,
Thanks for the update and additional info!
--- Quote from: Calamity on September 06, 2014, 05:09:07 am ---
--- Code: ---(progressive_lines_max + hfreq_max * vertical_blank) * vfreq_min > hfreq_max
--- End code ---
The way it was before: crt_range1 15625-15900, 59.98-80, 3.000, 4.700, 7.700, 0.190, 0.191, 1.018, 0, 0, 192, 248, 448, 496
(248 + 15900 * (0.190 + 0.191 + 1.018) / 1000) * 59.98 = 16234 (we had 15900 as hfreq_max so we were out of range).
Thus increasing hfreq_max to 16240 fixes the range.
--- End quote ---
Thanks for this, I was curious how the math worked out. I had tried changing some values to correct with no luck.
--- Quote from: Calamity on September 06, 2014, 05:09:07 am ---Regarding your issues with sound stuttering, I'd say you're forcing -syncrefresh in mame.ini. Don't do it, just keep -syncrefresh, -waitvsync and -triplebuffer as 0 (default), so GM can choose which one to use in each case.
--- End quote ---
-syncrefresh was already at 0 but sync_refresh_tolerance was at 2. I set sync_refresh_tolerance to 0 for my new tests and most of the sound issues are gone. Not sure if this is due to the preset edit or this setting.
--- Quote from: Calamity on September 06, 2014, 05:09:07 am ---Besides, I'd say you're using -frame_delay. Bear in mind -frame_delay *disables* sound synchronization. If the target refresh doesn't match the original with several decimal figures you'll have sound glitches for sure. The -frame_delay option has become popular but I want to remark that it is still experimental and it shouldn't be applied as a general option. It is recommended to enable it in a per game basis, trying to find the greater value that doesn't cause issues for that game and then creating a custom modeline (read: modeline, NOT crt_range) for that game to better tweak the frequency by manual fine tuning of the timings. So it is something you do once you have all up and running.
--- End quote ---
Good to know. I left frame_delay at 1 for the time being for this round of tests, wanted test the preset edit alone first before tweaking this.
--- Quote from: Calamity on September 06, 2014, 05:09:07 am ---Regarding the problems with MK, notice the trick you did by reducing the active lines to 254 is not doing what you think it is. Windows 7 doesn't allow you to do that. The active lines/active horizontal size of the modeline must match the logical resolution, otherwise the modeline is ignored and the default timings will apply, that is why automatically the 60 Hz refresh is activated, it seems to be fixing the geometry but actually it's just picking another modeline. As you see the game runs at 110% so it's ignoring your timings.
--- End quote ---
Ohhh of course, I totally missed this.
--- Quote from: Calamity on September 06, 2014, 05:09:07 am ---This monitor is probably the most complicated monitor we have worked with, as we just noticed by the beginning of this thread. It behaves different depending on the vertical refresh, rather than just the horizontal frequency. For this reason, we had to divide the 15 kHz range in two subranges (50-59.96) (59.98-80). Maybe we need an extra subrange.
--- End quote ---
Based on my new testing I think you are correct.
----- NEW TESTS -----
I plugged in the new preset and ran through my groovymame test game list again.
The results at the link below. Note there are also links to screenshots in the right column:
groovymame tests 2 - custom preset
I left the original arcade_15_25_31 test results intact. Thought it might still be useful for comparison purposes as some of the settings had better results than the custom:
groovymame tests 1 - arcade_15_25_31
Similar to RetroACTIVE's results some things improved and some that worked with the arcade_15_25_31 developed issues. Pacman, loht and paperboy are the ones that come to mind that worked better in 15_25_31. ddonpach, though it had a little clipping at the top before was closer with the 15_25_31 setting than the custom.
Another really strange difference I noticed that was for games like msh and neogeo games like mslug... even though the 15_25_31 and custom presets appear to set the same modeline the 15_25_31 fills the screen much better with less black around it. I ran logs of msh from both (attached) for comparison, you can also see it in the screenshots.
8BitMonk:
I've been doing a little more testing to try and create some new preset subranges and fix up the problem resolutions but it looks like I'm going to need a little coaching.
I figured the easiest place to start would be with a another preset I knew worked (and that worked with certain games) so I took the 15khz preset from arcade_15_25_31 and added it (bold below) to the custom ones from Calamity.
crt_range0 15625-16200, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 192, 288, 448, 576
crt_range1 15625-15900, 50-59.96, 7.800, 4.700, 10.600, 0.190, 0.191, 1.018, 0, 0, 192, 248, 448, 496
crt_range2 15625-16240, 59.98-80, 3.000, 4.700, 7.700, 0.190, 0.191, 1.018, 0, 0, 192, 248, 448, 496
crt_range3 16000-17200, 58-80, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 0, 0, 249, 256, 498, 512
crt_range4 18300-18800, 50-58, 8.300, 2.750, 9.000, 0.190, 0.191, 1.018, 0, 0, 257, 280, 514, 560
crt_range5 18800-19000, 50-80, 2.187, 4.688, 6.719, 0.140, 0.191, 0.950, 0, 0, 281, 320, 0, 0
crt_range6 24000-29000, 50-80, 2.020, 2.820, 6.460, 0.890, 0.148, 1.373, 0, 0, 384, 400, 0, 0
crt_range7 30000-34000, 50-80, 0.636, 3.813, 1.906, 0.020, 0.106, 0.607, 0, 0, 448, 496, 0, 0
As I expected this fixed up loht (384x256@55hz), it selects range 0, takes up most of the screen with the right refresh rate. My confusion is that I expected pacman to select range0 as well since it seems to fall within the parameters, ie. the min/max progressive lines are 192/288 which pacman falls within, 60hz is also within the range. Instead it selects range5. If I comment out range5 it selects range0 and runs and looks good though it runs at 52.427hz and I'm not sure if this is an issue or not. Everything looks, sounds and plays good but it's not 60hz.
Before I do any further testing I'd like to get a quick overview of how groovymame selects the preset ranges, does it match the progressive line values, the horizontal refresh rate or a combination of both?
Calamity I'm hoping you might have time to explain the best way for me to test and troubleshoot this. I'm happy to do the legwork if you can get me going in the right direction.
Thanks!