GroovyMAME/GroovyUME 0.149 SwitchRes v0.014b

[rCadeGaming]

Yeah, I'm just too picky about my geometry.  For example, GroovyMAME doesn't know where health bars are.  GroovyMAME doesn't know that my TV can't fit all 256 lines of R-Type on the screen, and that you can just shift it up a little to see the HUD at the bottom, because there's nothing critical at the top.

[Edit: Originally wrote 288 lines of R-Type, was a typo]

I wouldn't say you need hundreds of modelines.  In most cases you can set them up on a hardware driver basis, and individual game adjustments aren't needed. 

Even if you use the automatic mode most of the time, I think it's pretty critical to be able to go manual in special cases as you say.

An idea when raw modeline support will be added?  If the capability of using generated timing values is already there, wouldn't it be fairly simple to bypass the formulas and use values from the ini file?  You could implement that first before taking the time to add it to the UI.

Advanced users wouldn't need any error handling either.  If the modeline is bad, let it crash.  If we're creating these modelines, we can verify they're working ahead of time.

I'm just saying it could be made functional for advanced users who really need it, before you have to do all the work of prettying it up for general users.

Let me know if there's anything I can do to help this along.

[pyrojoe]

Hey Calamity,

You've done such a wonderful job on Groovymame! Congratulations on creating something that makes so many people happy.
 


I've recently switched my winxp setup to an Arch installation and am having a bit of an issue.

I'm using the 'ms2930' monitor preset and when I try to run dkong I'm getting the following as output:

SwitchRes: [dkong] (1) vertical (224x256@60.61)->(400x256@57.12)
SwitchRes: ProgressiveLinesMax 768 out of range
SwitchRes: Error in monitor range (ignoring): 31000-32000, 50-65, 0.330, 3.580, 1.750, 0.316, 0.063, 1.137, 0, 0, 576, 768, 0, 0

I got a better screen while I was running windows.  I'm probably missing something simple, but can't find it. Any suggestions?

Nevermind, I think I got it figured out.  Thanks anyway!

[cack01]

Hi Calamity

I am still testing and I have found quite a few games with slowdowns.  Refresh related slow downs.  I saw you mentioned the syncrefresh option earlier.  I enabled it in my ini and it did not have any effect.  It seems the only way to run a lot of games is if modelines is disabled.  Any ideas or things I should test.  See the attached log for an idea of what is going on (Michael Jackson's moonwalker)

Thanks for the help

[krick]

I am still testing and I have found quite a few games with slowdowns.  Refresh related slow downs. 

It might be configuration related.  You should always post your basic setup specs when asking for help...

- CPU (type and speed)
- Video card setup (Radeon + CRT_EmuDriver, Nvida + Soft15KHz, ArcadeVGA2, ArcadeVGA3000, etc...)
- Monitor type (low res arcade (15KHz), tri-sync arcade, TV, PC CRT, PC LCD, etc...)
- Operating system (Win XP 32bit, Win XP 64bit, Win 7 32bit, Win7 64bit, Linux, etc...)
- GroovyMAME version (be specific. also indicate if it is 32 or 64 bit and if you compiled it yourself)
- anything "weird" about your configuration that you think might be relevant

[cack01]

It might be configuration related.  You should always post your basic setup specs when asking for help........

Sorry about that. 

XP 64
Intel i5 @ 2.8ghz
ArcadeVGA 3000
GM 0.147u3 64bit
Have tried with -syncrefresh set to 0 & 1 in the GM ini.

Pretty much has to be configuration/new GM version as these games will all play fine when modelines is turned off in GM 0.147u3.  Pre GM 0.147 I would just have to put the *.exe in the directory set monitor to generic and off I go.  There are a lot more settings now, so I just trying to troubleshoot and see what works best with the AVGA 3000.

[Calamity]

I wouldn't say you need hundreds of modelines.  In most cases you can set them up on a hardware driver basis, and individual game adjustments aren't needed.

More than five hundred, indeed . A different story as that many of them belong to non-so-relevant games.

Even if you use the automatic mode most of the time, I think it's pretty critical to be able to go manual in special cases as you say.

An idea when raw modeline support will be added?  If the capability of using generated timing values is already there, wouldn't it be fairly simple to bypass the formulas and use values from the ini file?  You could implement that first before taking the time to add it to the UI.

Advanced users wouldn't need any error handling either.  If the modeline is bad, let it crash.  If we're creating these modelines, we can verify they're working ahead of time.

Well, it should be ready for the next release, that's for sure. At the moment my priority #1 is updating VMMaker to the new crt_range format, then I'll focus on next release.

By now, you can safely use GM with your own modes, as any other version of MAME, just make sure to have the -powerstrip option disabled. You need to have the -modeline option enabled anyway otherwise the -frame_delay option won't work.

Also, you'll need to disable the -lock_system_modes option, as your modes will be detected as 'system' modes, as opposed to 'custom' modes that are the ones we create for the Catalyst cards.

Finally, maybe you need to enable -refresh_dont_care, depending on how you labelled the refresh rate values of your modes.

[rCadeGaming]

More than five hundred, indeed . A different story as that many of them belong to non-so-relevant games.

Do you mean 500 variations including timing variations, or 500 resolutions that are all different in terms of basic active height and width?

An idea when raw modeline support will be added?

Well, it should be ready for the next release, that's for sure.

You are a god.   

I was thinking I would have to program my front-end to adjust the timing values in the driver or something, right before launching the game.

By now, you can safely use GM with your own modes, as any other version of MAME, just make sure to have the -powerstrip option disabled. You need to have the -modeline option enabled anyway otherwise the -frame_delay option won't work.

Also, you'll need to disable the -lock_system_modes option, as your modes will be detected as 'system' modes, as opposed to 'custom' modes that are the ones we create for the Catalyst cards.

Finally, maybe you need to enable -refresh_dont_care, depending on how you labelled the refresh rate values of your modes.

You mean manually switching to my modeline, then starting the game?  I can wait for next version.

[Calamity]

Sorry about that. 

XP 64
Intel i5 @ 2.8ghz
ArcadeVGA 3000
GM 0.147u3 64bit
Have tried with -syncrefresh set to 0 & 1 in the GM ini.

Pretty much has to be configuration/new GM version as these games will all play fine when modelines is turned off in GM 0.147u3.  Pre GM 0.147 I would just have to put the *.exe in the directory set monitor to generic and off I go.  There are a lot more settings now, so I just trying to troubleshoot and see what works best with the AVGA 3000.

Hi crack01,

That's odd because your log looks perfectly fine. The only interesting bit is that it's performing a resolution switch while in the game, but that's the expected behaviour. So, what are you seeing exactly? A slowdown? By refresh related slowdown I mean that the game shows a solid slowdown, not variable, of say 92% or whatever. If you get a variable rate then that's something different. Well for a refresh related slowdowns, you can either modify the refresh (you can use ArcadePerfect for your AVGA 3000) or enable -triplebuffer for that particular game (let's say that -triplebuffer is the opposite to -syncrefresh in this context). If, as you said, switching -modeline off fixes the issue, please attach a log here of the same game with -modeline off so I can compare.

[Calamity]

Do you mean 500 variations including timing variations, or 500 resolutions that are all different in terms of basic active height and width?

Timing variations of course.

I was thinking I would have to program my front-end to adjust the timing values in the driver or something, right before launching the game.

You mean manually switching to my modeline, then starting the game?  I can wait for next version.

Well, definitely you're going to have to figure out some automated method to pass the modelines to GroovyMAME through .ini or command line, is that what you mean?

[rCadeGaming]

Timing variations of course.

Ok, you're just saying it's a lot of timing variations to set up.  I though you were referring to running over the nVidia 31 custom res limit. 

Most resolutions should fit inside a common one, like running 384x224 centered in 392x240 and adjusting the border into the overscan.  As long as I have unlimited timing variations, I'm good.

Well, definitely you're going to do figure out some automated method to pass the modelines to GroovyMAME through .ini or command line, is that what you mean?

I meant my front-end would have a manually defined record of the the timing values for each game.  The game would be set up in MAME to switch to the right resolution, but the front end would edit the graphics driver to adjust the timing values for the selected game just before launching MAME. 

It would have been an enormous pain in the ass.  I don't even know if I'd be able to make adjustment to the driver that would take effect before restarting.  I hadn't begun working on it yet.

What do you mean I'll need an automated method to pass the modelines to GroovyMAME?  Once raw modeline support is added, can't I just manually type them into the individual hardware driver or game's .ini?

I could have the front-end pass them when launching through command line too, but it would be good to be able to store them in the .ini's.

[cack01]

Hi crack01,

That's odd because your log looks perfectly fine. The only interesting bit is that it's performing a resolution switch while in the game, but that's the expected behaviour. So, what are you seeing exactly? A slowdown? By refresh related slowdown I mean that the game shows a solid slowdown, not variable, of say 92% or whatever. If you get a variable rate then that's something different. Well for a refresh related slowdowns, you can either modify the refresh (you can use ArcadePerfect for your AVGA 3000) or enable -triplebuffer for that particular game (let's say that -triplebuffer is the opposite to -syncrefresh in this context). If, as you said, switching -modeline off fixes the issue, please attach a log here of the same game with -modeline off so I can compare.

Thanks for the continued help.  Slow down is constant and usually about 76%.  I am attaching three logs:

Modelines on: Slow Down
Modeline off: Good
Modeline On & Triple Buffer On: Good

Triple buffer seems to fix it although I have no idea what it does and if/why we use it. 

Thoughts?

[Calamity]

Thanks for the continued help.  Slow down is constant and usually about 76%.  I am attaching three logs:

Modelines on: Slow Down
Modeline off: Good
Modeline On & Triple Buffer On: Good

Triple buffer seems to fix it although I have no idea what it does and if/why we use it. 

Thoughts?

Are you by any chance using the new -frame_delay option? Make sure it's disabled if you're seeing speed issues.

I really need to see your compared logs of the same game with -modeline on/off, both with -syncrefresh (leave apart the -triplebuffer by now). That should point to one direction or other.

[kourampies]

I tried to run GroovyMAME 147, and Im having slowdowns on all games, regardless of the actual amount of resources they need.

All games? Or just a few of them? Vertical games? Slowdowns can be either CPU related, or refresh rate related (check your monitor settings, generic_15 is very conservative, try arcade_15). Try disabling -syncrefresh from command-line to find the answer, or... go into Game Information and check if the game is running at its native refresh or if it's been reduced to meet your monitor specs,

etc.

arcade_15 did the trick... 100% speed and perfect sync. now on to understand the new modelines syntax and get my old settings back

[Calamity]

arcade_15 did the trick... 100% speed and perfect sync. now on to understand the new modelines syntax and get my old settings back

That's a relief

The new crt_range syntax is quite simple indeed, it's only that such a long row of numbers looks scary, basically you're telling GM (for example): I want progressive modelines from 192 to 288 lines, and interlaced modelines from 448 to 576 lines. Whatever that falls outside that is out of range for me.

[retrorepair]

Just noticed I've lost 24/31khz resolutions using the MS2930 preset, I guess this is down to VMMaker not being up to speed with GM yet? Or did the old VMMaker not have that preset?

[Calamity]

Ok, you're just saying it's a lot of timing variations to set up.  I though you were referring to running over the nVidia 31 custom res limit. 

Most resolutions should fit inside a common one, like running 384x224 centered in 392x240 and adjusting the border into the overscan.  As long as I have unlimited timing variations, I'm good.

Even just counting the different resolutions (ignoring refresh variations),  it's quite beyond the NVidia 31 custom res limit, especially if you consider implemeting the MESS side, I'm pretty sure of this, so you'll have to make compromises here and there, however it's not too bad as long as you can have virtually any refresh rate that you want. Furthermore, by doing a clever use of the border sizes, as you're suggesting, you can simulate having many more resolutions, that's a huge lot of work but if properly done it should be perfect.

I meant my front-end would have a manually defined record of the the timing values for each game.  The game would be set up in MAME to switch to the right resolution, but the front end would edit the graphics driver to adjust the timing values for the selected game just before launching MAME. 

It would have been an enormous pain in the ass.  I don't even know if I'd be able to make adjustment to the driver that would take effect before restarting.  I hadn't begun working on it yet.

That's similar to how the SwitchRes app works (before it was integrated in MAME), but unfortunately that wouldn't work for NVidia, because their drivers only seem to read custom video definitions on boot , according to my tests, so you can't edit them dynamically unless you use a third party app like Powerstrip. ATI drivers on the other hand can reload the new timings at any point without rebooting, this is a gift from the gods, that's the main difference with NVidia and why GM is targeted to ATI cards.

What do you mean I'll need an automated method to pass the modelines to GroovyMAME?  Once raw modeline support is added, can't I just manually type them into the individual hardware driver or game's .ini?

I could have the front-end pass them when launching through command line too, but it would be good to be able to store them in the .ini's.

Of course the new option should pick the modelines directly from driver o game's ini, I just meant that it is a lot of work creating all those inis by hand, but anyway what's important now is to add this functionality, and let users find the best way for them to use it.

[Rochabian]

Hi Calamity

Is it possible to have a Nec XM29 Plus preset with next release?
I've used values that you've posted on another thread with VMMaker and it works quite well

Can it be added???

Thanks

[rCadeGaming]

Even just counting the different resolutions (ignoring refresh variations),  it's quite beyond the NVidia 31 custom res limit, especially if you consider implemeting the MESS side

Nope, no MESS for me.  I'm sticking with real hardware wherever possible.  This is easy for console games, and I'm thinking of picking up a couple PCB's now.

by doing a clever use of the border sizes, as you're suggesting, you can simulate having many more resolutions, that's a huge lot of work but if properly done it should be perfect.

It's been working great so far!  Yes, it's a lot of work but I enjoy tinkering. 

All this being said, I won't hesitate to get an ATI card if I run out of options, or find something I need that the nVidia won't do.

That's similar to how the SwitchRes app works (before it was integrated in MAME), but unfortunately that wouldn't work for NVidia, because their drivers only seem to read custom video definitions on boot , according to my tests, so you can't edit them dynamically unless you use a third party app like Powerstrip.

Ok, so GM's -powerstrip option will allow it to work with a nVidia card as you said.

If GM can control settings through Powerstrip, couldn't I program my front-end to do the same though?  I won't need to with GroovyMAME, but I may need to set timing values before launching a PC game.

Of course the new option should pick the modelines directly from driver o game's ini

I figured, but... Sweet! 

anyway what's important now is to add this functionality, and let users find the best way for them to use it.

I'm sure you could eventually do all kinds of convenient things in the UI, like pressing a button to import from Powerstrip, or adjusting individual values on a form similar to Powerstrip's advanced timing options window.  I'd be happy with just .ini editing.

[cack01]

Thanks for the continued help.  Slow down is constant and usually about 76%.  I am attaching three logs:

Modelines on: Slow Down
Modeline off: Good
Modeline On & Triple Buffer On: Good

Triple buffer seems to fix it although I have no idea what it does and if/why we use it. 

Thoughts?

Are you by any chance using the new -frame_delay option? Make sure it's disabled if you're seeing speed issues.

I really need to see your compared logs of the same game with -modeline on/off, both with -syncrefresh (leave apart the -triplebuffer by now). That should point to one direction or other.

sorry, I thought I attached them. See below.

[Calamity]

Hi cack01,

I *think* I've found the source of mwalk's slowdown. It seems there's a dramatic speed decrease for this game among versions 0.146 and 0.147, I mean the official versions, not GM. For testing this you need to press F10 in order to run the game unthrottled. For 0.146, I get a speed of around 250%, but for 0.147 it hardly gets 120%. Testing this on a P4 3.0 GHz.

120% unthrottled is an average, so its quite sure that at some points, the emulation speed doesn't reach 100%. When you v-sync a game that originally can't keep a solid 100% speed, the resulting speed can suddendly fall much below.

Looking through the whatsnew.txt, you can see there has been a lot of work on the Sega drivers, so maybe that's where the issue comes from.

As a fact, I have a testing build of GM here based on version 146u4 with the new Switchres patch 0.14, that's the version I used to develop the new patch before moving to the new compiling environment. Well, this build runs mwalk much faster than v0.147u3. So the new patch is not to blame, it seems.

I can notice the slowdowns here during mwalk's music passages. Now, if you told me you're getting 250% speed unthrottled then we should look at something else.

Only reason you can run those games at 100% when disabling the -modeline option is that by doing that, you're bypassing the whole options setting routines, so the -syncrefresh option is not applied (you'll sure notice the tearing). Better use the -triplebuffer option for those games, that one at least will remove tearing.

[Endprodukt]

Tempest is still not working for me. Suggestions?  I also don't understand fully how to use the new lines or at least how to find out what progressive and interlaced ranges make sense for my monitor. Can someone help out?

Gesendet von meinem HTC Desire HD A9191 mit Tapatalk 2

[Calamity]

Tempest is still not working for me. Suggestions?  I also don't understand fully how to use the new lines or at least how to find out what progressive and interlaced ranges make sense for my monitor. Can someone help out?

Tempest is working fine here, check your roms. I need to use roms named tempest1, tempest2 or tempest3. The rom named as just tempest is missing some files, probably I need to update.

What monitor are you using?

[Endprodukt]

It's basicly the successor of the hantarex polo... Its from the same manufacturer that bought hantarex (called 'monitor') based in Florence. I have my custom modeline, I just need to know how to use the new lines.

Gesendet von meinem HTC Desire HD A9191 mit Tapatalk 2

[Calamity]

It's basicly the successor of the hantarex polo... Its from the same manufacturer that bought hantarex (called 'monitor') based in Florence. I have my custom modeline, I just need to know how to use the new lines.

Is that dual-sync?

For the crt_range, check this, just above:

http://forum.arcadecontrols.com/index.php/topic,128879.msg1319002.html#msg1319002

[Endprodukt]

No, it's extended 15khz. I know what the new lines are doing, I just don't know how to find out what's good/bad for my monitor.

I tested all tempest versions and they all do the same: First a blue screen, then yellow flicker, then black... that's basicly it. No report of broken or missing roms.

[Calamity]

No, it's extended 15khz. I know what the new lines are doing, I just don't know how to find out what's good/bad for my monitor.

192, 288, 448, 576

I tested all tempest versions and they all do the same: First a blue screen, then yellow flicker, then black... that's basicly it. No report of broken or missing roms.

Did you create the fresh mame.ini? Magic resolutions? DirectDraw/D3D? Log?

[Endprodukt]

Fresh mame.ini: Yes. Magic resolutions: Yes. I'm using d3d with a HD4350. Would love to post a logfile but can't seem to save it... I know I have to use the -v command, but how do I save the log? Sorry for the noobish question.

[Calamity]

Fresh mame.ini: Yes. Magic resolutions: Yes. I'm using d3d with a HD4350. Would love to post a logfile but can't seem to save it... I know I have to use the -v command, but how do I save the log? Sorry for the noobish question.

groovymame.exe romname -v >romname.txt

Also, make sure you don't have any hlsl stuff enabled (not only in mame.ini I mean).

[Endprodukt]

thanks, here's the log. I'm not even shure what hlsl is. Is it disabled by default in the new mame.ini... were else should it be deactivated!?

[Calamity]

thanks, here's the log. I'm not even shure what hlsl is. Is it disabled by default in the new mame.ini... were else should it be deactivated!?

Thanks!

Try running tempest from command line adding the option -prescale 1

[Endprodukt]

I actually only had to delete an old ini I had for tempest... it screwed something up. Works now... thanks

[Calamity]

I actually only had to delete an old ini I had for tempest... it screwed something up. Works now... thanks

 

[maxpontello]

@Calamity

I've tested the new Groovymame with Bubble Bobble and noticed a strange behavour. It seems that the correct modeline required by the game is the following:

Modeline "256x224_60 15.63KHz 59.19Hz" 5.25 256 272 296 336 224 235 238 264   -hsync -vsync

I've exactly this in my modelines but when the game starts the image results shifted towards left (it goes out of screen, while at the right border there's a black columns). So i decided to modify it manually:

Modeline "256x224_60 15.63KHz 59.19Hz" 5.25 256 266 290 336 224 235 238 264   -hsync -vsync

I shifted (i think) image 6 pixel towards right.

When i launch the game the result is the same ad before. Analyzing the log, which i attach, it seems that the emu decides to ignore my modified modeline and generate the usual one on the fly. Is there a way to make it use the modifed one or a better way to shift the image so it doesn't go outside the screen?

Here is the complete log.

Thanks, Max

[Calamity]

Hi maxpontello,

Yes, GM overrides the installed modelines because it recalculates them on the fly. By now, the way to adjust geometry is by editing the crt_range options, for shifting the picture to the right you need to reduce the horizontal front porch. This will affect all modes.

[maxpontello]

Hi maxpontello,

Yes, GM overrides the installed modelines because it recalculates them on the fly. By now, the way to adjust geometry is by editing the crt_range options, for shifting the picture to the right you need to reduce the horizontal front porch. This will affect all modes.

Ok. So if my monitor range actually is 15625.00-16500.00,49.50-65.00,2.000,4.700,8.000,0.064,0.192,1.024,0,0,192,288,448,576 then i should change the 2.000 value, right? And by what value? Do i have to change the H-Back Porch too? Thanks Dude

[Calamity]

Try 1.8 for instance. The back porch affects the left border. Another approach is: launch Arcade_OSD, set the resolution you use for bublbobl as you have adjusted it, then enter the horizontal geometry menu and copy the values there (front and back porches), then use those into the crt_range line.

[emuola]

Sorry to ask this noob question again, but I want to be sure, I wont break my shiny new M3129. Also As there's now a preset for my m3129, I'm really not sure how much info I should put into mame.ini anymore  The correct way to use just vga (every game gets scaled to vga resolution) is the following?

In switchres.conf

Code: [Select]

threads=1
ff=1
monitor=m3129
aspect=4:3

But what about mame.ini? Do I use the line from monitor specs -thread?

Code: [Select]

...
monitor_specs0 31000.00-32000.00, 55-65, 0.33, 3.58, 1.75, 0.316, 0.063, 1.137, 0, 0, 576, 768
monitor_specs1 auto
monitor_specs2 auto
monitor_specs3 auto
monitor_specs4 auto
monitor_specs5 auto
monitor_specs6 auto
monitor_specs7 auto
...

Is this correct?

And what if I ever want to use the unscaled 15Khz modes also?

[Calamity]

Hi emuola,

I assume your using the GM v0.147u3, Linux and the Wei-Ya M3129. Please refresh my memory: why would you want to only use the 31kHz range if yours is a tri-sync monitor? You probably had a reason, it's just that I can't remember now.

Anyway, leave alone the switchres.conf

You only need to create a fresh mame.ini (the options you posted are out of date), then edit the option 'monitor' with:

Code: [Select]

monitor m3129
Now, this sets GM to use the three ranges (15-24-31), with GM's default settings for M3129. If you just want to use the 31 kHz range, and your custom settings, do the following (still in mame.ini):

Code: [Select]

monitor custom
crt_specs0 31000.00-32000.00, 55-65, 0.33, 3.58, 1.75, 0.316, 0.063, 1.137, 0, 0, 480, 512, 0, 0
If you wanted to enable the three ranges, but setting the 31 kHz range with your custom settings, do this:

Code: [Select]

monitor custom
crt_specs0 15250-16500, 40-80, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 1, 1, 224, 288, 448, 576
crt_specs1 23900-24420, 40-80, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 1, 1, 320, 384, 0, 0
crt_specs2 31000-32000, 55-65, 0.33, 3.58, 1.75, 0.316, 0.063, 1.137, 0, 0, 480, 512, 0, 0

[maxpontello]

Try 1.8 for instance. The back porch affects the left border. Another approach is: launch Arcade_OSD, set the resolution you use for bublbobl as you have adjusted it, then enter the horizontal geometry menu and copy the values there (front and back porches), then use those into the crt_range line.

I've followed your advices, settin 1.20 and now che image is centered But now i realize that either left  or right border go slightly out from monitor limit. I've set the monitor H amplitude on the base of Neo Geo resolution, so 320x224. Using a lesser resolution like Bubble Booble one, which is 256x224, shouldn't  the image be inside the screen, with left and right black border?

Thanks

Max

[emuola]

Hi emuola,

I assume your using the GM v0.147u3, Linux and the Wei-Ya M3129. Please refresh my memory: why would you want to only use the 31kHz range if yours is a tri-sync monitor? You probably had a reason, it's just that I can't remember now.

Anyway, leave alone the switchres.conf

You only need to create a fresh mame.ini (the options you posted are out of date), then edit the option 'monitor' with:

Code: [Select]

monitor m3129
Now, this sets GM to use the three ranges (15-24-31), with GM's default settings for M3129. If you just want to use the 31 kHz range, and your custom settings, do the following (still in mame.ini):

Code: [Select]

monitor custom
crt_specs0 31000.00-32000.00, 55-65, 0.33, 3.58, 1.75, 0.316, 0.063, 1.137, 0, 0, 480, 512, 0, 0
If you wanted to enable the three ranges, but setting the 31 kHz range with your custom settings, do this:

Code: [Select]

monitor custom
crt_specs0 15250-16500, 40-80, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 1, 1, 224, 288, 448, 576
crt_specs1 23900-24420, 40-80, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 1, 1, 320, 384, 0, 0
crt_specs2 31000-32000, 55-65, 0.33, 3.58, 1.75, 0.316, 0.063, 1.137, 0, 0, 480, 512, 0, 0

Thanks Calamity once again for explaining me stuff I don't understand I was planning to do 31Khz only, so that I don't have to fiddle with modelines (to be able to adjust the picture size/position etc). This is what I was told when I first asked about the kind of a monitor to buy. But if GA now has the automated modelines for m3129, I'll be really happy to try out all the "modes".

Cool