Switchres: modeline generator engine

[Calamity]

That list still has to reside somewhere, and I'd bet it's in the registry and not just in ram..

Yes, possibly, I don't really know. Anyway, even PowerStrip needs to restart Windows in order to add new video modes, afaik, so probably it's just a Windows limitation.

[MonkeyJug]

I'd be most grateful if you could at least find the time to look into this, as i am at my wits end trying to get the vertical roll to hold properly.

At the minute, i'm forced to run the vga via the jpac (jumpered both 15&31), but this is defeating the whole purpose of having a tri-sync monitor...

Hi MonkeyJug, I've been having a look at your monitor's manual, it's interesting as it claims to accept negative/positive and separate/composite sync, so in theory it should be syncing with the separate sync signal in Linux. You may have tested this already, but would be interesting to try using positive vsync polarity instead of the negative by default, to see if that makes any difference. Yo can do that by adding a custom monitor_specs line in GroovyMame.ini, like this one:

monitor_specs 15625-16200,50-60,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288,448

hsync / vsync polarities are the zero values by the end of the line, second zero is vsync, turn that to 1 and test with that.

(by doing this you will actually use a single hfreq range, so multisync capabilities will not be used but in case that works then it will be possible to fix your monitor definition).
 

BINGO!!

Wow, Calamity, you are a genius!  thank you so much for saving my sanity!

for the first time in a week, i can finally relax!  it has been a very frustrating time!

i added the line in the mame.ini and it didn't work at first, then i began experimenting.  i then tried changing the h-sync to 1 and it snapped straight into place as soon as i launched a game.  obviously the front end was rolling, but at least we are finally getting somewhere!

0,0 = rolling screen (as before)
0,1 = rolling screen (as before)
1,0 =  perfect sync, although the screen was about 3 inches left of center
1,1 - perfect sync, although the screen was about 1 cm right of center

getting there...

[bitbytebit]

I'd be most grateful if you could at least find the time to look into this, as i am at my wits end trying to get the vertical roll to hold properly.

At the minute, i'm forced to run the vga via the jpac (jumpered both 15&31), but this is defeating the whole purpose of having a tri-sync monitor...

Hi MonkeyJug, I've been having a look at your monitor's manual, it's interesting as it claims to accept negative/positive and separate/composite sync, so in theory it should be syncing with the separate sync signal in Linux. You may have tested this already, but would be interesting to try using positive vsync polarity instead of the negative by default, to see if that makes any difference. Yo can do that by adding a custom monitor_specs line in GroovyMame.ini, like this one:

monitor_specs 15625-16200,50-60,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288,448

hsync / vsync polarities are the zero values by the end of the line, second zero is vsync, turn that to 1 and test with that.

(by doing this you will actually use a single hfreq range, so multisync capabilities will not be used but in case that works then it will be possible to fix your monitor definition).
 

BINGO!!

Wow, Calamity, you are a genius!  thank you so much for saving my sanity!

for the first time in a week, i can finally relax!  it has been a very frustrating time!

i added the line in the mame.ini and it didn't work at first, then i began experimenting.  i then tried changing the h-sync to 1 and it snapped straight into place as soon as i launched a game.  obviously the front end was rolling, but at least we are finally getting somewhere!

0,0 = rolling screen (as before)
0,1 = rolling screen (as before)
1,0 =  perfect sync, although the screen was about 3 inches left of center
1,1 - perfect sync, although the screen was about 1 cm right of center

getting there...

I'll add that change for the polarities to the m3192 monitor type in groovymame, hopefully it allows then for the monitor to be trisync and possibly have better porch values too.  It's all betting on the d9200 having the same values as it does, or at least close.  Otherwise there might have to be more testing for each range, or more digging into the actual monitor specs.  Also hopefully this setup can fit some other trisync monitor definitions too, would guess it should be similar.  

Hopefully this weekend I'll have time to figure out the gasetup interface for more monitor types, and the modeline generation with switchres to add the extra monitor types too.

Update: Next ISO version of Groovy Arcade Linux will have a separate "MultiSync Monitor" menu item in the video setup section.  This will contain the monitor type for this (m3192) monitor and also the previous m2929 monitor someone else had (that did 30-50Khz).  That menu has more room now to add these different multiple freq types, may need to eventually split it up into manufacturers or some other categories, when there are enough to fill it up.

Update 2: I'm uploading new ISO images with this change right now, so will have an option for your monitor to try, labeled m3192 (under the MultiSync monitor type submenu of the video setup monitor type menu.

[MonkeyJug]

Update 2: I'm uploading new ISO images with this change right now, so will have an option for your monitor to try, labeled m3192 (under the MultiSync monitor type submenu of the video setup monitor type menu.

Fantastic stuff, it's half-past six in the morning and i'm not at work but i'm still going to get up just to try this...

I will post back with a verdict.

[Calamity]

0,0 = rolling screen (as before)
0,1 = rolling screen (as before)
1,0 =  perfect sync, although the screen was about 3 inches left of center
1,1 - perfect sync, although the screen was about 1 cm right of center

Great! This is important since in Windows I've always assumed negative sync was ok. Fortunately, there you can fix it by checking the composite sync option in CCC, but the whole thing was intended to avoid the need of CCC being installed. So I'll need to add the polarity support to VMMaker, till now I was reluctant to do so as it probably made necessary to add extra registry keys and more testing.

[Calamity]

Hi bitbytebit,

I'm looking a bit deeper in the triplebuffer subject since you asked about the other day. I'm wondering which is the default behaviour you have now in GroovyMame when using custom modelines (hacked drivers), not AVGA3000. I mean, if the target vfreq is not achieved, as it happens with pacman on a standard arcade monitor, will it default to throttle + triplebuffer or will it still enable vsync? In my experience it's been working as the second one, so vsync + soundsync does the trick and you can enjoy smooth gameplay even if somewhat slowed down. Of course someone might prefer the other way in order to run with the original speed and bear with scroll hiccups. I was wondering about this after reading the new setup for AVGA3000.

[bitbytebit]

Hi bitbytebit,

I'm looking a bit deeper in the triplebuffer subject since you asked about the other day. I'm wondering which is the default behaviour you have now in GroovyMame when using custom modelines (hacked drivers), not AVGA3000. I mean, if the target vfreq is not achieved, as it happens with pacman on a standard arcade monitor, will it default to throttle + triplebuffer or will it still enable vsync? In my experience it's been working as the second one, so vsync + soundsync does the trick and you can enjoy smooth gameplay even if somewhat slowed down. Of course someone might prefer the other way in order to run with the original speed and bear with scroll hiccups. I was wondering about this after reading the new setup for AVGA3000.

It's currently using tripple buffer without throttle or vsync.  I plan on changing that, to what your saying, it's the next thing actually I've been planning on doing this week.  Hopefully tonight or tomorrow I'll be able to get that to be more flexible so that it can default to the vsync and soundsync, but if desired (like if tripplebuffer is set) then it'll go that route. 

So does tripplebuffer without throttle or vsync really not work with the current groovymame code, or go full speed.  From what I can tell the ArcadeVGA report is that it worked that way actually, my system setup I tested it on would not be one to judge it by.  So I'm curious that it might actually work that way so it'd be another possible option?    Would it be best to have it just always use vsync and if the user picks tripplebuffer manually would that solve the too slow/fast speed issues? (if they want that). 

[Calamity]

It's currently using tripple buffer without throttle or vsync.  I plan on changing that, to what your saying, it's the next thing actually I've been planning on doing this week.  Hopefully tonight or tomorrow I'll be able to get that to be more flexible so that it can default to the vsync and soundsync, but if desired (like if tripplebuffer is set) then it'll go that route. 

So does tripplebuffer without throttle or vsync really not work with the current groovymame code, or go full speed.  From what I can tell the ArcadeVGA report is that it worked that way actually, my system setup I tested it on would not be one to judge it by.  So I'm curious that it might actually work that way so it'd be another possible option?    Would it be best to have it just always use vsync and if the user picks tripplebuffer manually would that solve the too slow/fast speed issues? (if they want that). 

Well, at least in theory, with the current patch, triplebuffer would need throttle to avoid going full speed, *unless* you disabled multithreading (so it would be as your test). I hadn't thought about that until you mentioned the other day. That's because if vsync is not set, the draw procedure still occurs in the window thread, as triplebuffer is not one of the conditions we check for doing it the other way. So the wait for vsync occurs before flipping but the main thread doesn't wait. BTW, I think this is the way triplebuffer should have always worked. (more on this later)

[bitbytebit]

It's currently using tripple buffer without throttle or vsync.  I plan on changing that, to what your saying, it's the next thing actually I've been planning on doing this week.  Hopefully tonight or tomorrow I'll be able to get that to be more flexible so that it can default to the vsync and soundsync, but if desired (like if tripplebuffer is set) then it'll go that route.  

So does tripplebuffer without throttle or vsync really not work with the current groovymame code, or go full speed.  From what I can tell the ArcadeVGA report is that it worked that way actually, my system setup I tested it on would not be one to judge it by.  So I'm curious that it might actually work that way so it'd be another possible option?    Would it be best to have it just always use vsync and if the user picks tripplebuffer manually would that solve the too slow/fast speed issues? (if they want that).  

Well, at least in theory, with the current patch, triplebuffer would need throttle to avoid going full speed, *unless* you disabled multithreading (so it would be as your test). I hadn't thought about that until you mentioned the other day. That's because if vsync is not set, the draw procedure still occurs in the window thread, as triplebuffer is not one of the conditions we check for doing it the other way. So the wait for vsync occurs before flipping but the main thread doesn't wait. BTW, I think this is the way triplebuffer should have always worked. (more on this later)

Interesting, I've got changes I just made that might be mostly what your saying is the best options.  Basically using vsync unless triple buffer is set, and in every single case like when refresh rates aren't exact.  Turn on soundsync if set only when needed with non-perfect refresh rates or custom modes (where we can't trust them 100% every time).  

So should possibly vsync be toggled on too with triplebuffer just to make it behave, or would that be bad? Or possibly use throttle with it? At least to try and use multithreading, since right now groovymame expects to always use multithreading.


Update:

Basically this is what I've got right now as the changes...

Code: [Select]


@@ -854,19 +849,43 @@ bool switchres_modeline_setup(running_machine &machine)
                        options.set_value(WINOPTION_FILTER, true, OPTION_PRIORITY_MAXIMUM, error_string);
                }
 
-                // Fallback to triplebuffer and soundsync if we have to
                 if (machine.switchRes.modeLine->result & RESULT_VFREQ_CHANGE) {
-                        mame_printf_verbose("SwitchRes: Setting Option -triplebuffer\n");
-                       options.set_value(WINOPTION_TRIPLEBUFFER, true, OPTION_PRIORITY_MAXIMUM, error_string);
-                        mame_printf_verbose("SwitchRes: Setting Option -nothrottle\n");
-                       options.set_value(OPTION_THROTTLE, false, OPTION_PRIORITY_MAXIMUM, error_string);
-                        mame_printf_verbose("SwitchRes: Setting Option -norefreshspeed\n");
-                       options.set_value(OPTION_REFRESHSPEED, false, OPTION_PRIORITY_MAXIMUM, error_string);
-                       mame_printf_verbose("SwitchRes: Setting Option -nowaitvsync\n");
-                       options.set_value(WINOPTION_WAITVSYNC, false, OPTION_PRIORITY_MAXIMUM, error_string);
+                       if (options.triplebuffer()) {
+                               // Fallback to triplebuffer and soundsync if user wants to
+                               mame_printf_verbose("SwitchRes: Setting Option -nothrottle\n");
+                               options.set_value(OPTION_THROTTLE, false, OPTION_PRIORITY_MAXIMUM, error_string);
+                               mame_printf_verbose("SwitchRes: Setting Option -norefreshspeed\n");
+                               options.set_value(OPTION_REFRESHSPEED, false, OPTION_PRIORITY_MAXIMUM, error_string);
+                               mame_printf_verbose("SwitchRes: Setting Option -nowaitvsync\n");
+                               options.set_value(WINOPTION_WAITVSYNC, false, OPTION_PRIORITY_MAXIMUM, error_string);
+                       } else {
+                               // Might not run full speed, so soundsync probably needed
+                               mame_printf_verbose("SwitchRes: Setting Option -nothrottle\n");
+                               machine.options().set_value(OPTION_THROTTLE, false, OPTION_PRIORITY_MAXIMUM, error_string);
+                               mame_printf_verbose("SwitchRes: Setting Option -waitvsync\n");
+                               options.set_value(WINOPTION_WAITVSYNC, true, OPTION_PRIORITY_MAXIMUM, error_string);
+                               mame_printf_verbose("SwitchRes: Setting Option -refreshspeed\n");
+                               machine.options().set_value(OPTION_REFRESHSPEED, true, OPTION_PRIORITY_MAXIMUM, error_string);
+                       }
+
+                       if (machine.options().soundsync()) {
+                               mame_printf_verbose("SwitchRes: Setting Option -soundsync\n");
+                               switchRes->cs.soundsync = 1;
+                               } else {
+                               mame_printf_verbose("SwitchRes: Setting Option -nosoundsync\n");
+                               switchRes->cs.soundsync = 0;
+                       }
                 } else {
+                               mame_printf_verbose("SwitchRes: Setting Option -notriplebuffer\n");
+                       options.set_value(WINOPTION_TRIPLEBUFFER, false, OPTION_PRIORITY_MAXIMUM, error_string);
+                       mame_printf_verbose("SwitchRes: Setting Option -nothrottle\n");
+                       machine.options().set_value(OPTION_THROTTLE, false, OPTION_PRIORITY_MAXIMUM, error_string);
                        mame_printf_verbose("SwitchRes: Setting Option -waitvsync\n");
                        options.set_value(WINOPTION_WAITVSYNC, true, OPTION_PRIORITY_MAXIMUM, error_string);
+                       mame_printf_verbose("SwitchRes: Setting Option -refreshspeed\n");
+                       machine.options().set_value(OPTION_REFRESHSPEED, true, OPTION_PRIORITY_MAXIMUM, error_string);
+                       mame_printf_verbose("SwitchRes: Setting Option -nosoundsync\n");
+                       machine.switchRes.cs.soundsync = 0;
                }
 
                 // Force resolution



[Calamity]

So should possibly vsync be toggled on too with triplebuffer just to make it behave, or would that be bad? Or possibly use throttle with it? At least to try and use multithreading, since right now groovymame expects to always use multithreading.

Triplebuffer already waits for vsync, so adding waitvsync to it would only make both threads work together and avoid the need of throttle, by means of our patch. But that's not the way it's intended to work, as I understand it. Triplebuffer is meant to wait in a different thread indeed, just as waitvsync was doing before our patch, so the main thread can go on with the next frame. But due to poor design (imho), instead of using a special thread for scheduling the flip, it just uses the window thread, that is the same one that should be receiving new input, blocking it, thus causing bad input lag (this is my own explanation, according to my tests, I'm open to any correction).

Notice that, when used this way, with multithreading on, triplebuffer does NOT adjust game speed to our refresh rate. It only removes tearing. So what happens is that the screen is updated at the actual videocard's refresh rate, while the game speed is independent from that (that's why we need to use throttle), so if the emulator renders frames more quickly than the refresh rate some of them will be skipped, causing scroll hiccups.

So, in order to keep the triplebuffer concept, independent of waitvsync, I think it should be used alone with throttle on.

[continues...]

[bitbytebit]

So should possibly vsync be toggled on too with triplebuffer just to make it behave, or would that be bad? Or possibly use throttle with it? At least to try and use multithreading, since right now groovymame expects to always use multithreading.

Triplebuffer already waits for vsync, so adding waitvsync to it would only make both threads work together and avoid the need of throttle, by means of our patch. But that's not the way it's intended to work, as I understand it. Triplebuffer is meant to wait in a different thread indeed, just as waitvsync was doing before our patch, so the main thread can go on with the next frame. But due to poor design (imho), instead of using a special thread for scheduling the flip, it just uses the window thread, that is the same one that should be receiving new input, blocking it, thus causing bad input lag (this is my own explanation, according to my tests, I'm open to any correction).

Notice that, when used this way, with multithreading on, triplebuffer does NOT adjust game speed to our refresh rate. It only removes tearing. So what happens is that the screen is updated at the actual videocard's refresh rate, while the game speed is independent from that (that's why we need to use throttle), so if the emulator renders frames more quickly than the refresh rate some of them will be skipped, causing scroll hiccups.

So, in order to keep the triplebuffer concept, independent of waitvsync, I think it should be used alone with throttle on.

[continues...]

Cool, I put a check in and if triplebuffer and multithreading are set it uses throttle, else if only triplebuffer it doesn't.  New builds are up with this change now.

[Calamity]

We can benefit from the fact that in Windows, there are to different options for vsync that at the moment do just the same: syncrefresh and waitvsync. We could actually use 'syncrefresh' as the active option instead of triplebuffer, to force sync to video card refresh, in any situation. And 'waitvsync' apart, as an option. Here is just a suggested logic that might cover all situations probably, anyway just let me know what you think.

IF syncrefresh
  ; Force sync to videocard refresh with all the features on, whatever the refresh is
  throttle 0
  waitvsync 1
  triplebuffer 0
  soundsync 1

ELSE
  ; Let groovymame decide

  IF RESULT_VFREQ_CHANGE
    ; Enable throttle in case we don't match the right refresh. Optional: triplebuffer, soundsync
    throttle 1
    waitvsync 0
    triplebuffer (0|1)
    soundsync (0|1)

  ELSE
    ; Enable waitvsync in case we match the right refresh. Optional: triplebuffer, soundsync
    throttle 0
    waitvsync 1
    triplebuffer (0|1)
    soundsync (0|1)

Options with (0|1) would pick their values from command line / ini. The idea is that just by enabling one single option (syncrefresh), any user would have a bulletproof setup that avoided tearing, scroll hiccups, audio stuttering and input lag all together. Then, by disabling syncrefresh, a more custom setup would be possible.

The only catch with this setup is, possibly, LCDs. As they are fixed to 60 Hz, we would need to calculate every modeline with 60 Hz, otherwise there are ugly artifacts.

EDIT: I modified the options a bit, now I think are better. Also, this assumes multithreading is ON.

[MonkeyJug]

Update 2: I'm uploading new ISO images with this change right now, so will have an option for your monitor to try, labeled m3192 (under the MultiSync monitor type submenu of the video setup monitor type menu.

Fantastic stuff, it's half-past six in the morning and i'm not at work but i'm still going to get up just to try this...

I will post back with a verdict.

first of all, i really appreciate everything you 2 guys are doing here.  it's outstanding work.  i don't think it will be too long before groovymame is the mame of choice for most people.  i'd never heard of it until a couple of weeks ago and now i can't imagine using anything else...

anyway, i installed the new iso in my cab.  setup was fine, and i selected the m3192 monitor and it synced as soon as the frontend loaded.  fantastic!
the screen looked beautiful in 640x480p.  i adjusted the h/v size until it filled the screen...  i immediately tried a few tekkens, which run natively at that resolution and they looked splendid.

then i tried some low-res games.  alcon and tiger heli.  i remember these games wouldn't run faster than about 88%, but they both ran beautifully at 100% with this linux version.

there is one problem however now.  the low-res games need ALOT of adjustment in terms of v/h size & position.  track & field (trackfld) was in about 3 inches at each side and a few of the vertical shooters were very skinny.  i had to do lots of adjustments between pretty much every game i tried.  obviously, when i adjusted them to fit the screen horizontally, this had the knock-on effect of putting the front end out once i exited back to it.  when back at the frontend, the edges of the screen were then out in so much that it made finding games difficult because the first 10-15 letters of the titles were off the left side of the screen.  mostly, games were centered on the screen, but were just off, being either too skinny or too short/tall.

i'm not sure what needs to happen to address this issue.

on a postive note, games like esp.ra.de and ketsui look absolutely stunning, once manually adjusted for height.

donpachi still gives a hint of 'flicker' and i'm not sure what is causing this...

all in all, a very postive experience.  now if bitbytebit can work on getting the adjustments needed to be less than i am currently doing, it's looking very nice indeed!  i'm not sure what is involved in doing this, whether it is porch adjustment, or some other variable, but i'll be interested in hearing what you guys have to say about this...

regards, and thanks again!

[bitbytebit]

Update 2: I'm uploading new ISO images with this change right now, so will have an option for your monitor to try, labeled m3192 (under the MultiSync monitor type submenu of the video setup monitor type menu.

Fantastic stuff, it's half-past six in the morning and i'm not at work but i'm still going to get up just to try this...

I will post back with a verdict.

first of all, i really appreciate everything you 2 guys are doing here.  it's outstanding work.  i don't think it will be too long before groovymame is the mame of choice for most people.  i'd never heard of it until a couple of weeks ago and now i can't imagine using anything else...

anyway, i installed the new iso in my cab.  setup was fine, and i selected the m3192 monitor and it synced as soon as the frontend loaded.  fantastic!
the screen looked beautiful in 640x480p.  i adjusted the h/v size until it filled the screen...  i immediately tried a few tekkens, which run natively at that resolution and they looked splendid.

then i tried some low-res games.  alcon and tiger heli.  i remember these games wouldn't run faster than about 88%, but they both ran beautifully at 100% with this linux version.

there is one problem however now.  the low-res games need ALOT of adjustment in terms of v/h size & position.  track & field (trackfld) was in about 3 inches at each side and a few of the vertical shooters were very skinny.  i had to do lots of adjustments between pretty much every game i tried.  obviously, when i adjusted them to fit the screen horizontally, this had the knock-on effect of putting the front end out once i exited back to it.  when back at the frontend, the edges of the screen were then out in so much that it made finding games difficult because the first 10-15 letters of the titles were off the left side of the screen.  mostly, games were centered on the screen, but were just off, being either too skinny or too short/tall.

i'm not sure what needs to happen to address this issue.

on a postive note, games like esp.ra.de and ketsui look absolutely stunning, once manually adjusted for height.

donpachi still gives a hint of 'flicker' and i'm not sure what is causing this...

all in all, a very postive experience.  now if bitbytebit can work on getting the adjustments needed to be less than i am currently doing, it's looking very nice indeed!  i'm not sure what is involved in doing this, whether it is porch adjustment, or some other variable, but i'll be interested in hearing what you guys have to say about this...

regards, and thanks again!

Cool, yeah it's basically the front/back porch values and sync pulse values then that are wrong.  Calamity might have more ideas how to get those values, or what would be better.  I guess the d9200 values aren't close enough.  Basically all the adjustments are no longer needed if the values for the porches are correct.  I'll also try to research more online to find those values possibly, also perhaps if you can contact support for the monitor and ask them for those porch and sync pulse specs, that might be a good route to take.

Update:

Also I'm thinking maybe that first setting with just the hsync postive might be better.  Fortunately with the install, once installed, you can update groovymame now pretty easy so changes I made  to the monitor definitions will be pushed onto your system through running "sudo emerge -av groovymame", which will incrementally download updates to groovymame for you. 

Running this command will get you each monitor range setting...

switchres --calc pacman --monitor m3192 --showmrange -v -v --emulator groovymame

So from there, like before but using those values, you can try each range (change game name above for game you want, see which range it picks, and then use that range in the mame.ini config for that test). 

Basically the ranges are these...
MonitorLimits 15250.00-16500.00,40.00-80.00,2.187,4.688,6.719,0.190,0.191,1.018,1,1,288.0,448
MonitorLimits 23900.00-24420.00,40.00-80.00,2.910,3.000,4.440,0.451,0.164,1.048,1,1,384.0,768
MonitorLimits 31000.00-32000.00,40.00-80.00,0.636,3.813,1.906,0.318,0.064,1.048,1,1,576.0,768

Calamity might have more ideas from what your seeing what to change with the porch values etc, at least try them each with the sync altered though to see if that makes a big difference.

[Calamity]

Try editing the range for low resolutions, values into [] are front and back horizontal porches.

- front porch: right border
- back porch: left border

(they can't be zero)

MonitorLimits 15250.00-16500.00,40.00-80.00,[2.187],4.688,[6.719],0.190,0.191,1.018,1,1,288.0,448

Try reducing those values. Probably also the sync pulse (the one between those), until you loose sync. Start by trying the ones from the next range. You'll see how the borders shrink. It's a trial and error process.

[Calamity]

CRT_EmuDriver based on Catalyst 6.5 for Windows XP64 is finally ready!

  - It should provide support for old Radeon and ArcadeVGA cards (9200/9250) in Windows XP64.
  - All the usual hacks included (up to 120 video modes and support 320x and 400x progressive resolutions).

The packages include new version 1.3 of VMMaker, that has beta support for multisync monitors. I've used the same monitor definitions from GroovyMame (notice positive polarities are not supported yet).

More info here (Spanish):

http://postback.geedorah.com/foros/viewtopic.php?id=1424

Here are the files:

crt_emudriver_6.5_1.2_x64_multisync.rar
http://www.megaupload.com/?d=IUWXNJ4R

crt_emudriver_6.5_1.2_xp32_multisync.rar
http://www.megaupload.com/?d=LXE6IIDK

crt_emudriver_9.3_1.2_x64_multisync.rar
http://www.megaupload.com/?d=XI8LIRJD

crt_emudriver_9.3_1.2_xp32_multisync.rar
http://www.megaupload.com/?d=LAYG0YYF

[MonkeyJug]

Tried running the switchres command with trackfld, and its uses the 15khz range.

Then tried inserting the 15khz monitorlimits line at the end of the mame.ini, but didnt notice any difference when adjusting either of the porches... I double checked everything was typed correctly.  I adjusted the both values by -3.0 and there was no difference.

Been doing a bit of hunting online. Supposedly it's a waste of time emailing wei-ya as all they do is send a generic response about how they dont disclose their intellectual property information...

However, i have discovered that my monitor is likely an M3129DF-72, which is supposedly identical to a billabs BL27C90T or a Makvision 29" Tri-sync.

Not sure if you are able to easily loacate the porch/pulse values for either of those and i could try them my side...

[bitbytebit]

Oh I meant in the mame.ini use monitor_specs and then from there the values, switchres isn't used, the config option I gave was the switchres one so might have been confusing.  You can also use the cmdline with groovymame and give it -monitor_specs too, so can make changes quicker that way.

Also the monitor_specs option is in mame.ini as auto by default, so adding it again at the end wont work.  So using the command line is best, and probably the changes you were making didnt get actvated/used. 

Tried running the switchres command with trackfld, and its uses the 15khz range.

Then tried inserting the 15khz monitorlimits line at the end of the mame.ini, but didnt notice any difference when adjusting either of the porches... I double checked everything was typed correctly.  I adjusted the both values by -3.0 and there was no difference.

Been doing a bit of hunting online. Supposedly it's a waste of time emailing wei-ya as all they do is send a generic response about how they dont disclose their intellectual property information...

However, i have discovered that my monitor is likely an M3129DF-72, which is supposedly identical to a billabs BL27C90T or a Makvision 29" Tri-sync.

Not sure if you are able to easily loacate the porch/pulse values for either of those and i could try them my side...

[Calamity]

MonkeyJug,

Maybe the easiest way to find your monitor's porch values is using Arcade_OSD in Windows. Grab the new VMMaker 1.3 and edit the ini with this options:

MonitorType = "CUSTOM"
monitor_specs_0 = "15250.00-16500.00,40.00-80.00,2.187,4.688,6.719,0.190,0.191,1.018,1,1,288.0,448"
monitor_specs_1 = "23900.00-24420.00,40.00-80.00,2.910,3.000,4.440,0.451,0.164,1.048,1,1,384.0,768"
monitor_specs_2 = "31000.00-32000.00,40.00-80.00,0.636,3.813,1.906,0.318,0.064,1.048,1,1,576.0,768"

This way you'll define the three ranges for your monitor. Now run VMMaker to calculate and install the modelines, and restart. Then run Arcade_OSD and edit the different resolutions. Try getting one or more resolutions within each range (check the hfreq value as a guide).

Go into "Horizontal Geometry" and play with the porch sizes, until you get a good adjustment of the horizontal amplitude and centering. Then write down the porch values that best fit your monitor and let us know. You can also find the right length of the pulse sync you need (try reducing it until you loose sync). Notice that the widest the horizontal resolution you use when doing this, the more accurate the values you'll get. So better use 400x224 than 256x224.

[bitbytebit]

I just made a change that will allow more than one custom monitor range, changed the monitor_specs option in groovymame to have the 0-7 appended to it similar to the resolution and other args mame can use...

-monitor_specs0      Add custom monitor specs, format: 15250.00-15700.00,49.50-65.00,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288.0,448
-monitor_specs1      Add custom monitor specs
-monitor_specs2      Add custom monitor specs
-monitor_specs3      Add custom monitor specs
-monitor_specs4      Add custom monitor specs
-monitor_specs5      Add custom monitor specs
-monitor_specs6      Add custom monitor specs
-monitor_specs7      Add custom monitor specs

So now the monitor specs option can be a lot more flexible and matches what the VMMaker is doing, there can be up to 8 ranges since this covers the d9800 which probably is the most extreme case of ranges needed.


To use this in groovy arcade Linux right now, after installed, you just run an update to groovymame (need networking setup) like...

sudo emerge -av groovymame

And it should download and recompile with this change, and also the old -monitor_specs argument won't work anymore and must have 0 at the end if it to do the same thing.  I'll update the patch and windows builds here in a bit, but it's in the git repository right now.

[Calamity]

8 ranges? I thought the maximum was 6 for D9800, my definitions are probably outdated then...

It's great you added that too, now it will be very flexible and versatile for testing new monitors.

[bitbytebit]

8 ranges? I thought the maximum was 6 for D9800, my definitions are probably outdated then...

It's great you added that too, now it will be very flexible and versatile for testing new monitors.

I didn't check, it at least that will give it even more just in case someone wants to really explore the in between ranges like around 20khz and 29khz where I have basically blocked out the range since those areas don't act right.

[MonkeyJug]

MonkeyJug,

Maybe the easiest way to find your monitor's porch values is using Arcade_OSD in Windows. Grab the new VMMaker 1.3 and edit the ini with this options:

MonitorType = "CUSTOM"
monitor_specs_0 = "15250.00-16500.00,40.00-80.00,2.187,4.688,6.719,0.190,0.191,1.018,1,1,288.0,448"
monitor_specs_1 = "23900.00-24420.00,40.00-80.00,2.910,3.000,4.440,0.451,0.164,1.048,1,1,384.0,768"
monitor_specs_2 = "31000.00-32000.00,40.00-80.00,0.636,3.813,1.906,0.318,0.064,1.048,1,1,576.0,768"

This way you'll define the three ranges for your monitor. Now run VMMaker to calculate and install the modelines, and restart. Then run Arcade_OSD and edit the different resolutions. Try getting one or more resolutions within each range (check the hfreq value as a guide).

Go into "Horizontal Geometry" and play with the porch sizes, until you get a good adjustment of the horizontal amplitude and centering. Then write down the porch values that best fit your monitor and let us know. You can also find the right length of the pulse sync you need (try reducing it until you loose sync). Notice that the widest the horizontal resolution you use when doing this, the more accurate the values you'll get. So better use 400x224 than 256x224.

i'm trying to do this, but the options for 'edit modeline' and 'horizontal geometry' are greyed out and can't be selected...

any ideas what i'm doing wrong?

[Calamity]

i'm trying to do this, but the options for 'edit modeline' and 'horizontal geometry' are greyed out and can't be selected...

any ideas what i'm doing wrong?

Are you using my hacked drivers? Check if ArcadeOSD finds them (green caption at init). You will only be able to edit the video modes that are "custom" (the ones that are not grayed). Also, make sure you're arcade monitor is plugged as your primary device (no multi-monitor support yet).

[MonkeyJug]

i'm trying to do this, but the options for 'edit modeline' and 'horizontal geometry' are greyed out and can't be selected...

any ideas what i'm doing wrong?

Are you using my hacked drivers? Check if ArcadeOSD finds them (green caption at init). You will only be able to edit the video modes that are "custom" (the ones that are not grayed). Also, make sure you're arcade monitor is plugged as your primary device (no multi-monitor support yet).

hmmmm, all resolutions are showing as 'native'...

i've tried every possible combination of h/v-sync, composite sync, different cables...  can't get arcade_osd to show any custom modelines.

when arcade_osd starts, it says 'crt-emudriver found' in green, but all 120 resolutions are showing as native...

[Calamity]

hmmmm, all resolutions are showing as 'native'...

i've tried every possible combination of h/v-sync, composite sync, different cables...  can't get arcade_osd to show any custom modelines.

when arcade_osd starts, it says 'crt-emudriver found' in green, but all 120 resolutions are showing as native...

Oh, really strange 

I've attached a test version that does not gray the options for native modes. You'll be able to get into the options with this one. I'm interested to know if you see the options full of zero values (for the modes that are suposed to be custom, like 320x224, 384x256 and such), that would mean there's a problem reading the registry modelines.

[MonkeyJug]

hmmmm, all resolutions are showing as 'native'...

i've tried every possible combination of h/v-sync, composite sync, different cables...  can't get arcade_osd to show any custom modelines.

when arcade_osd starts, it says 'crt-emudriver found' in green, but all 120 resolutions are showing as native...

Oh, really strange 

I've attached a test version that does not gray the options for native modes. You'll be able to get into the options with this one. I'm interested to know if you see the options full of zero values (for the modes that are suposed to be custom, like 320x224, 384x256 and such), that would mean there's a problem reading the registry modelines.

this one now allows me to edit the modelines, (even though they are still greyed out and showing as native).

and yes, in edit mode, every single modeline is full of zeros.

[Calamity]

this one now allows me to edit the modelines, (even though they are still greyed out and showing as native).

and yes, in edit mode, every single modeline is full of zeros.

Ugly stuff... I've attached a new one that changes a flag when accessing registry, it might help but I doubt it'll make any difference. I'll need to do a version that actually logs error messages...

[MonkeyJug]

well, it's game over for me...

monitor finally said enough is enough!

i updated groovymame via the sudo command, then rebooted.

edited the new mame.ini and changed the first 3 monitor_spec auto values to the 3 ranges listed above, in preparation for a bit of tweaking.  tried to launch a game, and it just displayed a black screen and i noticed a 'whining' sound from which i couldn't exit.

rebooted and all of a sudden the display is absolutely massive and very, very dark.  my monitor is finished!!

wouldn't mind, but getting a tri-sync monitor in the uk is impossible nowadays...

[Calamity]

Oh ---steaming pile of meadow muffin---!! That's the worse thing we can hear... I'm so sorry about that man. Hopefully it'll be possible to repair it.

It's strange as you have already tested with those ranges for sure. Any idea of what game or resolution caused the disaster?

In theory CRTs are protected and should not break because of wrong frequencies, though I've heard stories of Pentranic monitors breaking because of that...

[MonkeyJug]

i'm not sure what happened really.  maybe i had a typo in the monitor_specs line.  ah well, not sure if it can be repaired, and to be honest, i'm not even sure i would want to - that monitor has been nothing but a curse for me!!

i had a quick look on ebay and saw this:

http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=170609373052&ssPageName=STRK:MEWAX:IT

i'd get it if i thought it would be easier on my sanity than the m31 was!

any of you guys got any experience with this monitor?

[Calamity]

MonkeyJug, I've no experience with that monitor, anyway it looks good and new. It's nearly impossible to get a multisync monitor down here in Spain too and it's so expensive to send or import them... I should have done it when they were available.

bitbytebit, the new groovymame 12j has the resolution option broken or something. Have a look at the ddonpach log.

There's something strange too with the aspect ratio thing. If you see the old logs (h and j) they look exactly the same, but h has correct aspect ratio, while j is wide-screen. This is confusing. Hopefully in some days I'll make a deeper testing of many games. Also assuming a 0.02 Hz difference as "Vfreq Change" and go for the throttle route seems too conservative to me, we won't get se accurate in Windows most of the time.

[bitbytebit]

MonkeyJug, I've no experience with that monitor, anyway it looks good and new. It's nearly impossible to get a multisync monitor down here in Spain too and it's so expensive to send or import them... I should have done it when they were available.

bitbytebit, the new groovymame 12j has the resolution option broken or something. Have a look at the ddonpach log.

There's something strange too with the aspect ratio thing. If you see the old logs (h and j) they look exactly the same, but h has correct aspect ratio, while j is wide-screen. This is confusing. Hopefully in some days I'll make a deeper testing of many games. Also assuming a 0.02 Hz difference as "Vfreq Change" and go for the throttle route seems too conservative to me, we won't get se accurate in Windows most of the time.

Yeah, I chose .02 Hz since in Linux that was easy to achieve but guessing not in Windows.  What do you think would be best to have for that, I changed it to .10 but not sure if that's still too small or too much?

Ah I see what I did, I was consolidating the method I used to save the original resolution argument to check against for future use (since we set the resolution argument ourselves with our desired modelines resolution unless it's already set, so we know who set it exactly).  I am fixing that, should have another version updated soon to fix it, thanks for finding that, quite a nasty bug actually.

Update:  Ok, 012m is uploaded, see if it still has issues with setting the .ini file.  Also now the .ini resolution setting should for the most part override the games resolution even for vertical games.   Seems my logic was checking that before the vertical calculations were done, now it is done afterwards and completely lets you choose the resolution that is calculated even if the game is a vertical or double screen one.

[Calamity]

Testing 012m. Please have a look at this log. It's filling a 512x512 modeline with the wrong height/width values.
The resolution option seems fixed however.

I'm also seeing that the -resolution command line param is used in an odd way. See the log of rtype2, I'm asking it to run at -resolution 800x600 and it virtualizes that when it should only pass the param without processing it.
Update: I'm seeing you it's because I have it set to "cga", so it's probably doing the right thing.

BTW I'm testing on a laptop with nVidia card, the custom modelines are fake ones I put in the registry just for testing, but that should not be a problem.

[bitbytebit]

Testing 012m. Please have a look at this log. It's filling a 512x512 modeline with the wrong height/width values.
The resolution option seems fixed however.

I'm also seeing that the -resolution command line param is used in an odd way. See the log of rtype2, I'm asking it to run at -resolution 800x600 and it virtualizes that when it should only pass the param without processing it.
Update: I'm seeing you it's because I have it set to "cga", so it's probably doing the right thing.

BTW I'm testing on a laptop with nVidia card, the custom modelines are fake ones I put in the registry just for testing, but that should not be a problem.

Seems like it's constrained by having those few custom modelines available, so does't look very hopeful for it to be able to do the right thing at  all actually and it's trying to use 512x512 but that is too small so it looks to fail at calculating to that resolution.  From what I can tell it's a rare case where it tried twice to adjust to the resolution and fails both times, I'm still trying to figure out exactly what should be done though in that case.  I'm a bit confused exactly what is totally happening there, but is this probably a rare case or even with a full setup of modelines do you think it's having some issues similar too?

[Calamity]

Well, I've done lots of tests with all imaginable combinations, in order to check how to triplebuffer properly. I've seen that using DDBLT_ASYNC and DDFLIP_DONOTWAIT params does not help at all and the Flip function still waits and does not return inmediately, so there's no way to make truly asynchronous vsync flipping by just using the DirectDraw api. It would be possible to implement it by doing our own flipping thread but that would involve major changes to the Mame source, so I'd forget that.

We can still have a sort of asynchronous flipping by using the multithreading mechanism built in Mame, just as it is now: sending the draw function through the PostMessage route to the window thread when triplebuffer is on. That method has two problems: input lag (as we block the window thread) and slowed down throttle.

We can do nothing about the input lag problem due to triplebuffer, unless we implemented the flipping thread thing so it would be as lagless as our syncrefresh option.

The second problem has driven me nuts until I found the cause. In theory, multithreading + throttle + triplebuffer should run 100% even if the refresh rate is, say 80% of the game speed, as both threads are independent. But I noticed this was not true, so if throttle was disabled the game runs full speed (as you said) but when adding throttle the speed goes down to 80% (or whatever the refresh rate is). It turns out the cause is Mame's lock mechanism, so there was a hidden wait due to osd_lock_acquire that only happens when throttle is enabled. So we need to do this additional patch to the winwindow_video_window_update:

      // only block if we're throttled
      //if (window->machine().video().throttled() || timeGetTime() - last_update_time > 250)
      //   osd_lock_acquire(window->render_lock);
      //else
         got_lock = osd_lock_try(window->render_lock);

... that basically skips the blitting in case the last frame is still being drawn, thus achieving a truly asynchronous flipping. This allows me to run 'contra' here at 100% even if the refresh I have is around 54 Hz. Of course some frames are skipped in the way, so the scroll is not the smoothest possible, but there's no tearing at all and the game is quite enjoyable apart from that. Then you have the option to enable syncrefresh + soundsync and have the game perfectly smooth but slowed down to 90% of it's speed.

(Possibly it's safer to only remove the 'window->machine().video().throttled()' from the condition as there may be a good reason for the 'timeGetTime() - last_update_time > 250' part.)

Also, this option is great for 3d games as tekken where the syncrefresh option is making them run slower than possible. Unfortunately with the logic I suggested those games are usually forced to vsync as their refresh matches the modeline's vfreq but it would be nice to be able to disable syncrefresh in these cases and do throttle + triplebuffer, so I can see my logic doesn't work for these cases or at least needs some improvement.

[bent98]

Ok, I just ran DXDiag and Ddraw is enable and passes all three tests.
I also verified I have a whole load of modelines active. Not sue if its 120  but it looks like it.

BTW also the sound seems to stutter like its not in sync with refresh.

[Calamity]

Yeah, fortunately your modelines are available so the driver looks ok. There's something odd with mode selection, please try with latest groovymame just to see if it makes any difference and that bug is already solved, your logs say your using v0.012m. Well what happens is groovymame is acting as if you had a cga monitor, even if it says D9800 in your logs, so it's calculating only with it's lower range and not using the higher resolutions available. Probably bitbytebit will know what the issue may be. Try deleting any monitor_specs line you have in groovymame.ini just in case, this could have been caused since the last change when those ranges where added.

[bent98]

I am usinging the latest groovymame. Version n. not m

[bent98]

mayne its a bug in the n version that doesnt show correct version but it is n