It could be other things but what I find happening its that its not picking the correct resolution. I used to run an ArcadeVGA setup and had most games working at their native resolutions so I'm pretty sure the monitor can handle most of what I need to throw at it.
Just post here a log of a random game that produces a blank screen, by doing this:
groovymame.exe romname -v -md 4 >romname.txt
I'll have a look at it before we go any further. When you have your system up and running we'll start with the monitor specs.
Hi RetroACTIVE,
You seem to be using 'magic' resolutions. Switch your video options to -video d3d inside mame.ini.
Before you test anything else: go back to -video ddraw. Go into display properties/advanced/monitors and uncheck the option "Hide modes this monitor can't display". Reboot and try again.
Also, use Arcade_OSD to navigate and test the 1234x resolutions individually.
I was thinking a bit more about this and I don't believe this particular monitor actually reports its capabilities.... in fact I'm pretty sure it doesn't.
I was thinking a bit more about this and I don't believe this particular monitor actually reports its capabilities.... in fact I'm pretty sure it doesn't.
Yeah it was just to be sure, because I've only seen the blank screen issue once, and it was because Windows was filtering some modes. If Arcade_OSD, which uses DirectDraw BTW, can show those modes, then MAME should.
So if the magic resolutions don't work in your system (I'd pay just to know why in the world they don't), you'll need to get rid of them, otherwise GroovyMAME will insist on picking them. Edit ReslList.txt, delete those resolutions and run VMMaker again.
By know you can just try that way. As soon as you want to use Hyperspin you'll need to trim your resolution list to something around 80 resolutions, using the TotalModes option in vmmaker.ini.
Hopefully HS 2 will fix this issue and we'll free to use as many resolutions as we want.
Does the fit problem with mk have something to do with the one you had before when using magic resolutions or are they different issues?
It would be of help to see both logs of mk with and without forcing 60 Hz. I guess it's making it jump from an interval to another and that will help us start finding your monitor limits.
BTW, mk's real refresh is 54.82 Hz, indeed.
I believe these are the same fit issues regardless of magic resolution at this point.
Yeah I'm not sure what my monitor is doing with the 54.82 Hz refresh rate. Even though that is correct, it certainly appears to be problematic.
I would love a block diagram or picture of the various pieces of Groovy/VMMaker/SwitchRes/Driver so I can get a better understanding as to what the interfaces are and how modes are determined and how the gmame chooses. I feel a little in the dark and truly hope I'm not coming across as ignorant.
almost... it fits but the screen is bowed like ( ) and it doesn't look like the resolution is right... not pixelated enough (no visible scan lines).
Yeah, the modeline scoring system is moving that video mode to the 31 KHz range instead of the 18-19 KHz that's what I intended. I'll look for a solution.
15750, 50.00, 6.72, 8.67, 7.27, 0.128, 0.444, 0.825
2 7 13
15750, 60.11, 6.72, 8.67, 7.27, 0.064, 0.444, 0.825
1 7 13
24827, 55.61, 3.04, 3.04, 3.80, 0.282, 0.322, 1.260
7 8 31.28
31469, 59.94, 0.64, 3.81, 1.91, 0.318, 0.064, 1.048
20 2 33
37880, 60.32, 1.00, 3.20, 2.20, 0.030, 0.110, 0.610
1 4 23
so... gmame chooses the resolution that is closest to the native resolution of the game but it doesn't consider the Vfreq in that algorithm? It seems like its setting the refresh rate to 54.82 and the monitor handles it fine (other than the fact it doesn't fit properly).
I'm confused as to why it would pick that frequency if its not listed in Arcade_OSD table of modes?
I went into Arcade_OSD selected 400x256@60 mode line. I adjusted the values according to the log file and bingo! I was able to get the screen to match what I'm seeing in mk.
QuoteI went into Arcade_OSD selected 400x256@60 mode line. I adjusted the values according to the log file and bingo! I was able to get the screen to match what I'm seeing in mk.
That's good. So, once you reproduced the issue, did you try tweaking the vertical geometry to see if something improves? I'd try with the vertical centering adjustment to see if you find some values which work. Actually at this point I'd like to see a picture of it, I'm not sure how much it's cropped, whether it's a matter of a few lines or more.
I actually didn't mess with the vertical settings one bit. I'll go back and check to be sure.
Just a note... messing with the porch settings really didn't pull the pic in enough... when I was tweaking it it really didn't snap into place until I messed with the dot clock setting.
Just a note... messing with the porch settings really didn't pull the pic in enough... when I was tweaking it it really didn't snap into place until I messed with the dot clock setting.
You mean the vertical porches don't you? But did you just use the vertical centering or you tried increasing each porch individually, increasing the total number of lines by doing so? What I'd do is to keep vfreq locked at 54.7 and increase the vertical front porch.
Hi RetroACTIVE,
The process is:
1-> Unlock Vfreq
2-> Enter modeline values, including DotClock. Vfreq should become 54.7
3-> Lock Vfreq
4-> Tweak geometry, porches, etc. Vfreq should keep close to 54.7 despite the changes.
I assume you're accepting the changes before leaving the modeline submenu, by pressing "1" (testing the mode)?
Now Scramble and Galaxian are using the wrong resolution... higher res is selected:
SwitchRes v0.013: [scramble] (1) vertical (256x224@60.61)->(400x256@60.61)->(800x512@60.61)
On the paperboy 512x384 settings... specifically the H settings, how are these translated into the monitor_specs line? V settings seem to make sense to me but H settings seem way out there to me... Is it a units issue?
On the paperboy 512x384 settings... specifically the H settings, how are these translated into the monitor_specs line? V settings seem to make sense to me but H settings seem way out there to me... Is it a units issue?
Ok, did you need to change the vertical part to make it fit the screen or just adjusted it horizontally?
Both needed to be adjusted.
Both needed to be adjusted.
Please be more precise. Was the vertical part overscanned or just shifted up/down, or both, how much, etc. :)
(I can just use the values you got, don't worry, it's just to be sure).
... so you need to find the right horizontal porch values for the 15 KHz range (monitor_specs0). At this point you should have learned how to do this ;)
I'll be helping anyway... ;D
- I'm assuming you added the line to mame.ini
- Check there's no duplicated label for monitor_specs0
- Check some log to see that your monitor_specs0 are actually read (or attach it here).
I'll be with your issue today, your latest results really puzzled me...
There are several odd things in your report:
- You said "So here is the modeline as it is selected by the game:" so I understand you copied the full modeline data produced by GM into Arcade_OSD's 256x224@60 video mode and then took the photos. The odd bit is that the modeline shows hfreq = 15.243 even if we limited hfreq by means of monitor_specs0 to a minimum of 15.625, so something is wrong here. It would help if at this point you add the same monitor_specs into vmmaker.ini to recalculate the resolutions and reboot. That will produce modelines that are already closer to the ones calculated by GM.
- Instead of editing the horizontal porches in order to correct horizontal amplitude so the picture fits the screen (as I suggested), you tried the seemingly wrong idea of tweaking the vertical porches instead, but contrary to the logic *it did work*. Considering that horizontal timings among both modes are almost the same, that jump in horizontal geometry can't only be explained if your monitor is somewhat "correcting" the horizontal amplitude by itself based on hfreq.
So, make sure you adjust the right modeline in Arcade_OSD, this should be in the range of 15.6 - 15.7 KHz if the monitor_specs0 line is being considered. Then get the horizontal porches for it. Keeping inside that hfreq range (15.6-15.7) should ensure these porch values will still be valid when used by GM, as it'll be calculating within those ranges. Let the vertical values alone by now (keep the ones we had before: 0.190, 0.191, 1.018).
I've attached a new VMMaker's beta that fixes the bug you were seeing. It's already setup with your monitor specs (notice that now it uses the same format as GroovyMAME).
Now, you'll need to redo all the steps, right to the state shown on your third pic. Once you're there (59.981 Hz), unlock vfreq and start decreasing the dotclock step by step, so vfreq gets equal or below 59.941. Let me know if you find the sudden jump I'm talking about.
Decreasing the vfreq didn't cause it to jump to another mode... It just immediately produced the over scan.
I need to go back and check, but generally to get it to go below 59.941Hz the best I can do is get it adjusted to the settings you see above, otherwise the image pops it into the center of the screen and the margins are really large. Then when I try to adjust the porch values, it pops back out beyond the edges.
Hi RetroACTIVE, it's good that it works...
Try modifying the limits slightly until you reach the point where each game goes to its right settings:
monitor_specs0 15625-15900, 40-59.96, 7.800, 4.700, 10.600, 0.190, 0.191, 1.018, 0, 0, 248, 448
monitor_specs1 15625-15900, 59.98-80, 3.000, 4.700, 7.700, 0.190, 0.191, 1.018, 0, 0, 248, 448
Again... try toki, snowbros, bublblobl (< 60 Hz) ; then goldnaxe (60 Hz)
Paste here your ModeList.txt and Modeline.txt files so I can see why you're missing those desktop modes.
Just post here a log of a random game that produces a blank screen, by doing this:
groovymame.exe romname -v -md 4 >romname.txt
I'll have a look at it before we go any further. When you have your system up and running we'll start with the monitor specs.
Hey Cal... I've been busy and haven't had a chance to get back to this... Did you get a chance to look at my attachments?
Thanks :)
Hi RetroACTIVE, yes I looked at your results. My conclusion is that the monitor_specs are already fine, but I need to fix GroovyMAME's modeline scoring system. If you have a look at your log, the right modeline is actually calculated in range 2, but GM is still picking the one from range 1 because it doesn't notice the second one is any better. That needs to get fixed.
Hey Cal... I've been busy and haven't had a chance to get back to this... Did you get a chance to look at my attachments?
Thanks :)
Hi RetroACTIVE, yes I looked at your results. My conclusion is that the monitor_specs are already fine, but I need to fix GroovyMAME's modeline scoring system. If you have a look at your log, the right modeline is actually calculated in range 2, but GM is still picking the one from range 1 because it doesn't notice the second one is any better. That needs to get fixed.
Any idea if this is the same issue with Tempest and other 640x480 games?
Hi RetroACTIVE, yes I looked at your results. My conclusion is that the monitor_specs are already fine, but I need to fix GroovyMAME's modeline scoring system. If you have a look at your log, the right modeline is actually calculated in range 2, but GM is still picking the one from range 1 because it doesn't notice the second one is any better. That needs to get fixed.
Ok cool thanks :cheers:
Hi RetroACTIVE, yes I looked at your results. My conclusion is that the monitor_specs are already fine, but I need to fix GroovyMAME's modeline scoring system. If you have a look at your log, the right modeline is actually calculated in range 2, but GM is still picking the one from range 1 because it doesn't notice the second one is any better. That needs to get fixed.
That's good RetroACTIVE,
I'm *right now* in the process of coding the new patch that should fix, among other things, the issue mentioned here:QuoteHi RetroACTIVE, yes I looked at your results. My conclusion is that the monitor_specs are already fine, but I need to fix GroovyMAME's modeline scoring system. If you have a look at your log, the right modeline is actually calculated in range 2, but GM is still picking the one from range 1 because it doesn't notice the second one is any better. That needs to get fixed.
It will take me one ore two weeks at least, please be patient :)
Not sure if there would be a difference between a straight up ATI vs. the ArcadeVGA. I think there might but I would check with Calamity.
I've not yet had a chance to check the latest version of GM against my setup yet. I'm excited because I think it has addressed my issues :)
I have the same monitor, but I'm using a ArcadeVGA as a video card. I'm having some issues with games like dkong and pacman running at like 88%. Looking at the output it's not picking the right resolution. I included my mame.ini and dkong output.
I'm just starting out, so I haven't played with anything yet. Wanted to check in before I did.
Thanks!
I have the same monitor, but I'm using a ArcadeVGA as a video card. I'm having some issues with games like dkong and pacman running at like 88%. Looking at the output it's not picking the right resolution. I included my mame.ini and dkong output.
I'm just starting out, so I haven't played with anything yet. Wanted to check in before I did.
Thanks!
Hi Banacek,
It's picking the right resolution indeed, 400x256, it's only that this resolution has a refresh rate of 52 Hz, that's where the slowdown comes from. Try enabling -triplebuffering for that game, that will keep it at 100% speed regardless the refresh.
There's another resolution marked as 352x256@60, have you tried forcing that resolution?
Well, that makes sense now. Let's try with these settings:
monitor_specs0 15625-15900, 40-59.97, 7.800, 4.700, 10.600, 0.190, 0.191, 1.018, 0, 0, 248, 448
monitor_specs1 15625-15900, 60.00-80, 3.000, 4.700, 7.700, 0.190, 0.191, 1.018, 0, 0, 248, 448
monitor_specs2 16000-17200, 58-80, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 0, 0, 256, 448
monitor_specs3 18300-18800, 40-58, 8.300, 2.750, 9.000, 0.190, 0.191, 1.018, 0, 0, 280, 448
monitor_specs4 18800-19000, 40-80, 2.187, 4.688, 6.719, 0.140, 0.191, 0.950, 0, 0, 320, 448
monitor_specs5 24000-29000, 40-80, 2.020, 2.820, 6.460, 0.890, 0.148, 1.373, 0, 0, 384, 576
monitor_specs6 30000-34000, 40-80, 0.636, 3.813, 1.906, 0.020, 0.106, 0.607, 0, 0, 496, 768
monitor_specs7 34001-38000, 40-80, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 600, 768
Now the 15 Khz range is divided in two ranges depending on vfreq, the limit is 59.97 Hz, let's see how it works.
Try toki, snowbros, bublblobl (< 60 Hz)
Then try goldnaxe (60 Hz)
Calamity, any plans on adding Betson to the monitor types in the ini files?
Retroactive, would you mind sharing your current setup? I'd like to mimic what you have. I can set up a Dropbox folder if you need to drop any files in.
Let me know...
DeLuSioNaL29
Game | | Native MAME Res | | GM (Betson Test) | | F11 Game speed | | GM (D9800 50Hz custom) | | F11 Game speed |
Aero Fighters | 320x224 | 2560x320 | 100% | 2560x240 | 100% |
Bomb Jack | 256x224 | 2560x256 | 100% | 2560x256 | 100% |
Caveman Ninja | 256x240 | 2560x240 | 100% | 2560x240 | 100% |
Centipede/Millipede | 256x240 | 2560x800 | 84% | 2560x464 | 100% |
Circus Charlie | 256x224 | 2560x256 | 100% | 2560x256 | 100% |
Do Don Pachi | 320x240 | 2560x800 | 68% | 2560x464 | 100% |
Do Don Pachi Dai-Ou-Jou v101 | 448x224 | 2560x448 | 100% | 2560x448 | 100% |
Mad Planets | 256x240 | 2560x800 | 80% | 2560x464 | 100% |
Q*Bert | 256x240 | 2560x800 | 80% | 2560x464 | 100% |
Raiden Fighters | 320x240 | 2560x800 | 70% | 2560x464 | 100% |
Raiden Fighters 2 | 320x240 | 2560x800 | 70% | 2560x464 | 100% |
Raiden Fighters Jet | 320x240 | 2560x800 | 70% | 2560x464 | 100% |
Rampage | 512x480 | 2560x800 | 100% | 2560x464 | 100% |
Satan's Hollow | 512x480 | 2560x800 | 80% | 2560x464 | 100% |
Space Invaders '95 | 320x224 | 2560x320 | 100% | 2560x320 | 100% |
Super Space Invaders | 320x224 | 2560x320 | 100% | 2560x320 | 100% |
Spy Hunter | 480x480 | 2560x800 | 80% | 2560x464 | 100% |
Tapper | 512x480 | 2560x800 | 100% | 2560x464 | 100% |
Toki | 256x224 | 2560x240 | 100% | 2560x240 | 100% |
Zookeeper | 256x256 | 2560x264 | 100% | 2560x256 | 100% |
(progressive_lines_max + hfreq_max * vertical_blank) * vfreq_min > hfreq_max
Code: [Select](progressive_lines_max + hfreq_max * vertical_blank) * vfreq_min > hfreq_max
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.
Should I select D9800 for Monitor type in VMMaker or Custom?
I've got a new version of my presets I will post tonight, the values have changed as I've done more testing. There are also ini files that go along with them. The Windows version of Groovymame has some bugs that the ini files account for.Sweet! I can't wait to give them a try! Thank you! I have to say it does look pretty awesome. I've almost got my Betson OSD dialed in. My problem as you mentioned, I have messed with these settings to match other set ups. Too bad there isn't a reset to default option.
Hey AMD, yep grab the latest driver, vmmaker and arcade osd files and you'll notice inside the vmmaker_arcade_osd_1.4 folder is a file named ReslList - super.txt with instructions at the top of it for enabling super resolutions
I see cleanstretch as a setting that is under Core Switchres. Currently it is set to 0.
Do I simply add these lines somewhere? If so which heading?
Look in the log file for the game to get the modeline it's setting, should look something like this:
2560x256_60 15.65KHz 54.71Hz" 52.07 2560 2664 2912 3328 256 262 265 286 -hsync -vsync
groovymame came out that fixed mistakenly selecting the wrong presetsWhich version had this error? I am running GM 155. Thanks
Quotegroovymame came out that fixed mistakenly selecting the wrong presetsWhich version had this error? I am running GM 155. Thanks
- Finally proper support for "super" resolutions (Windows & Linux):
- Fix for modeline scoring to properly select the best available "super" resolution.
- Fix for blank UI due to wrong scaling when in rotated mode and using "super" resolutions.
- Fix for vector games that didn't show when using "super" resolutions.
Before I started I calibrated my monitor at 800x600 using a monitor calibration tool while in factory mode
Make sure you're using the Wells presetsSo, I need to delete my presets in GroovyMame's .ini and change the Monitor type from "Custom" to D9800?
Betson 9400/9800 preset with minor edit. Had to lower range 0 to 192 and range 1 280 to include certain games:
crt_range0 15250-18000, 40-80, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 0, 0, 192, 288, 448, 576
crt_range1 18001-19000, 40-80, 2.187, 4.688, 6.719, 0.140, 0.191, 0.950, 0, 0, 280, 320, 0, 0
crt_range2 20501-29000, 40-80, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 0, 0, 320, 384, 0, 0
crt_range3 29001-32000, 40-80, 0.636, 3.813, 1.906, 0.318, 0.064, 1.048, 0, 0, 384, 480, 0, 0
crt_range4 32001-34000, 40-80, 0.636, 3.813, 1.906, 0.020, 0.106, 0.607, 0, 0, 480, 576, 0, 0
crt_range5 34001-38000, 40-80, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 576, 600, 0, 0
Should I leave Monitor Type as Custom and add those?
You should consider using VMMaker 2.0 (even if you stick with old drivers). This way you can simply copy and paste current GroovyMAME crt_ranges, no need for separate configurations any more.I think that's what I have? File is dated December 2015. I'm using all the latest EmuDrivers, etc. Good to hear that moving forward I can simply copy and past the current ranges.
monitor "kt-2914", "Betson-Kortek KT-2914", "4:3"
crt_range0 15250-18000, 40-80, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 0, 0, 192, 288, 448, 576
crt_range1 18001-19000, 40-80, 2.187, 4.688, 6.719, 0.140, 0.191, 0.950, 0, 0, 280, 320, 0, 0
crt_range2 20501-29000, 40-80, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 0, 0, 320, 384, 0, 0
crt_range3 29001-32000, 40-80, 0.636, 3.813, 1.906, 0.318, 0.064, 1.048, 0, 0, 384, 480, 0, 0
crt_range4 32001-34000, 40-80, 0.636, 3.813, 1.906, 0.020, 0.106, 0.607, 0, 0, 480, 576, 0, 0
crt_range5 34001-38000, 40-80, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 576, 600, 0, 0
...Does anyone have a copy of the Betson OSD Groups PDF (https://drive.google.com/file/d/0B7dTwhKHukfDbklsSlp3S1JIYW8/view?usp=sharing) they could share with me? I don't have access to download it from Google Drive.
Below is a link to my mapping PDF that shows each group that I found. I'm not exactly sure of the determining factor for each group, it's not something as simple as 'all games with a horizontal frequecy of x', it appears to be a combination of the H/V frequencies. Maybe after looking at my PDF Calamity will be able to identify the exact determining factor.
Download Betson OSD Groups PDF (https://drive.google.com/file/d/0B7dTwhKHukfDbklsSlp3S1JIYW8/view?usp=sharing)
In the upper right are my OSD settings, the top row are my initial settings in case I needed to go back and the one underneath shows adjustments I made. On the left under the OSD Group letter is a list of 12 boxes where I wrote the H/V frequecies contained in the group and down below under each game I've put a number in parenthesis after the game show corresponds.
...
from http://forum.arcadecontrols.com/index.php/topic,117489.msg1558930.html#msg1558930
monitor "kt-2914", "Betson-Kortek KT-2914", "4:3"
crt_range0 15250-18000, 40-80, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 0, 0, 192, 288, 448, 576
crt_range1 18001-19000, 40-80, 2.187, 4.688, 6.719, 0.140, 0.191, 0.950, 0, 0, 280, 320, 0, 0
crt_range2 20501-29000, 40-80, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 0, 0, 320, 384, 0, 0
crt_range3 29001-32000, 40-80, 0.636, 3.813, 1.906, 0.318, 0.064, 1.048, 0, 0, 384, 480, 0, 0
crt_range4 32001-34000, 40-80, 0.636, 3.813, 1.906, 0.020, 0.106, 0.607, 0, 0, 480, 576, 0, 0
crt_range5 34001-38000, 40-80, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 576, 600, 0, 0
My man.. I think this might be it?
Betson_OSD_Groups.pdf (attached)
https://ufile.io/c7ehgvdr (uploaded a copy here too)
Side note.. my Betson/Kortek has been out of commission for years in a spare room.. I recently got it repaired and back in action!
At the moment i'm using groovyarcade iso with generic arcade monitor settings.
Are these the currently 'best' settings I should be using for this monitor?Quotefrom http://forum.arcadecontrols.com/index.php/topic,117489.msg1558930.html#msg1558930
monitor "kt-2914", "Betson-Kortek KT-2914", "4:3"
crt_range0 15250-18000, 40-80, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 0, 0, 192, 288, 448, 576
crt_range1 18001-19000, 40-80, 2.187, 4.688, 6.719, 0.140, 0.191, 0.950, 0, 0, 280, 320, 0, 0
crt_range2 20501-29000, 40-80, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 0, 0, 320, 384, 0, 0
crt_range3 29001-32000, 40-80, 0.636, 3.813, 1.906, 0.318, 0.064, 1.048, 0, 0, 384, 480, 0, 0
crt_range4 32001-34000, 40-80, 0.636, 3.813, 1.906, 0.020, 0.106, 0.607, 0, 0, 480, 576, 0, 0
crt_range5 34001-38000, 40-80, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 576, 600, 0, 0
After much tweaking I went back to using 8bit's old presets. Both the D9800 setting and the minor tweak by 8bit cause lots of what I call "slithering" with vertical games. Its when a portion of the screen sort of twitches. I find using 8bits older presets that this problem is almost completely gone with most vertical games. If I knew more about tweaking the presets I would probably have to customize my own. Seems these monitors are finicky. No two are the same. I will say that going into the defaults and adjusting at 800x600 has helped with the overall geometry.
Hey AMD,
I experienced this on my monitor as well, not sure what causes it, it's almost a rippling effect through a portion of the screen. It's not as noticeable when playing but very noticeable on the title screen and especially if it goes through lettering. I found that I could eliminate it for most games by playing with the geometry, ie. slightly moving the screen left or right or slightly reducing the vertical or horizontal sizing.
Can you share your mame.ini and switchres.conf for the betson? Thanks!
[InvaderJim@myComputer mame]$ diff mame.20220111.original.ini mame.20220115.superModes.ini
271c271
< aspect auto
---
> aspect 4:3
299c299
< monitor generic_15
---
> monitor custom
321,326c321,326
< crt_range0 auto
< crt_range1 auto
< crt_range2 auto
< crt_range3 auto
< crt_range4 auto
< crt_range5 auto
---
> crt_range0 15250-18000, 40.00-80.00, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 0, 0, 192, 288, 448, 576
> crt_range1 18001-19000, 40.00-80.00, 2.187, 4.688, 6.719, 0.140, 0.191, 0.950, 0, 0, 280, 320, 0, 0
> crt_range2 20501-29000, 40.00-80.00, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 0, 0, 320, 384, 0, 0
> crt_range3 29001-32000, 40.00-80.00, 0.636, 3.813, 1.906, 0.318, 0.064, 1.048, 0, 0, 384, 480, 0, 0
> crt_range4 32001-34000, 40.00-80.00, 0.636, 3.813, 1.906, 0.020, 0.106, 0.607, 0, 0, 480, 576, 0, 0
> crt_range5 34001-38000, 40.00-80.00, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 576, 600, 0, 0
518a519,520
>
> orientation horizontal