Switchres: modeline generator engine

[bitbytebit]

All issues have been solved with this version, I'll keep testing...

One question I have about the doublescan vtotal amount, seems weird, I always get these .5 values to it and rounding up seemed to be bad and change the vertical refresh rate, seems like the linux DRM stuff rounds down or chops the decimal anyways, so should I just do that for something like this...


# transfrm  256x192@60.00 25.620Khz
Modeline "256x192x60.00" 9.223200 256 288 320 360 192 198 200 213.5 -HSync -VSync doublescan

You can either round up or chop, I prefer rounding up to avoid reducing the back porch. But always use integer elements if you want to properly predict the resulting vfreq, if you let Linux chop the values for you, your pre-calculated frequencies won't be accurate. So, what you have to do is convert to integers, and then, calculate your dotclock only once you have your definitive vvt and hht values.

So once you have vvt and hht, you can adjust dotclock so it fits your initial vfreq. Until now, you've been using granularity-free dotclocks, that's good for now, as it allows you to properly adjust to your initial vfreq whatever vvt and hht you have. However, that may not be true, and if it turns out that the dotclock has also a discrete nature, as it happens with Windows drivers, then if you want to be really accurate you have to deal with the problem of achieving a required vfreq out of three discrete values: dotclock, hht, vvt. That's why I made that interative loop, to test different combinations of discrete values for dotclock, hht, vvt, to see which one produced the closest vfreq. Using just 5 iterations, you can usually go as close as 0.02 Hz. But the disadvantage is that this method introduces additional verical padding, that even if it doesn't affect the picture at all, can colide with our brand new weighting system...

Cool, here's a diff that recalculates it and seems to work and get the integer vtotal and still the right vrefresh (seems this is only going to happen during doublescan from what I can tell)...

Also this fixes the padding value, I realized it needed a 2x since it was just one of the top/bottom values.

Code: [Select]


diff --git a/switchres b/switchres
index de15d1b..1417441 100755
--- a/switchres
+++ b/switchres
@@ -1216,7 +1216,7 @@ sub get_modeline($ $ $ @) {
        my $interlace = 1;
 
        my $VBlankLines = 0;
-       my $margen = 0;
+       my $margin = 0;
        my $VT = 0;
        my $HFreq = 0;
        my ($newDC, $newHh, $newHi, $newHf, $newHt);
@@ -1445,32 +1445,36 @@ sub get_modeline($ $ $ @) {
        if ($interlace == 2) {
                $VBlankLines += 0.5;
        }
-       $margen = (($VT * $interlace) - $OriginalHeight - ($VBlankLines * $interlace)) / 2;
-       if ($margen) {
+       $margin = (int($VT * $interlace) - $OriginalHeight - ($VBlankLines * $interlace)) / 2;
+       if ($margin) {
                $MODELINE_RESULT |= $VRES_PAD;
        }
 
-       $vb = $OriginalHeight + int(((($HFreq/1000)*$Mode[$ModeBase]{'VFrontPorch'}) * $interlace + $margen)+0.5);
+       $vb = $OriginalHeight + int(((($HFreq/1000)*$Mode[$ModeBase]{'VFrontPorch'}) * $interlace + $margin)+0.5);
        $vc = $vb + int(((($HFreq/1000)*$Mode[$ModeBase]{'VSyncPulse'}) * $interlace)+0.5);
 
+       # Total vertical lines
+       $vtotal   = int(($VT * $interlace)+0.5);
+
+       # Recalculate dotclock
+       $HFreq = $Refresh * ($vtotal/$interlace);
+       $DotClock = sprintf("%.6f", ($htotal * $HFreq)/1000000);
+
        if ($VERBOSE > 1) {
-               print "Modeline Calculation of " . sprintf("%.3f", $Refresh) . "Hz " .
+               print "Modeline Calculation of " . $DotClock . "Mhz " . sprintf("%.3f", $Refresh) . "Hz " .
                         sprintf("%.3f", $HFreq/1000) . "Khz " .
-                        $VT . " vtotal " . $VBlankLines . " vblank " . $margen . " vpad\n\n";
+                        $VT . " vtotal " . $VBlankLines . " vblank " . ($margin*2) . " vpad\n\n";
        }
 
-       # Total vertical lines
-       $vtotal   = ($VT * $interlace);
-
        # Modeline structure
-       my $label = sprintf("%.3f", ($Mode[$ModeBase]{'HfreqMin'}/1000)) . "Khz - " .
+       my $label = sprintf("%.3f", ($Mode[$ModeBase]{'HfreqMin'}/1000)) . "Khz --> " .
                        sprintf("%.3f", ($Mode[$ModeBase]{'HfreqMax'}/1000)) . "Khz";
        my %mline = ( 'name' => "$ModeName", 'pclock' => "$DotClock",
                        'hactive' => "$ha", 'hbegin' => "$hb", 'hend' => "$hc", 'htotal' => "$htotal",
                         'vactive' => "$va", 'vbegin' => "$vb", 'vend' => "$vc", 'vtotal' => "$vtotal",
                         'interlace' => '', 'doublescan' => '', 'hp' => '-HSync', 'vp' => '-VSync',
                        'hfreq' => "$HFreq", 'vfreq' => "$Refresh",
-                        'result' => "$MODELINE_RESULT", 'vpad' => $margen, 'hpad' => 0,
+                        'result' => "$MODELINE_RESULT", 'vpad' => ($margin*2), 'hpad' => 0,
                        'label' => "$label");
       
        # flags


I'm interested in creating a function to do your same figuring based upon dotclock values not being granular.  One thing I read somewhere, on why the cvt calculations always are in 250 aligned amounts, is because modern video cards they claim aren't often able to get more fine grained than that.  So it would be interesting for that, at least to see how that affects the line padding.  Also then I could test plugging in your table of ATI values and really see if my d9800 suddenly perfectly hits the vrefresh rates on the OSD, I'm not sure if it's an accurate calculation it's doing though so it'd be interesting since if it did suddenly show perfect values it'd prove both the need for the dotclock check and that the OSD is accurate. 

Also two other things I've been seeing.  One is that it seems that the Linux DRM stuff requires the vertical height, only active lines, to be a division of 8 or else it will cause mame to lock until forcibly killed off, just gets stuck in a black screen and then have to restart X cause the OpenGL/SDL layer is all messed up and fonts are weird (really small).  That's something that started happening on certain games after I started using the DRM stuff, and took a heck of a time to finally figure out that it was the height not being multiples of 8 and those were the games I was seeing this on.  So for now it seems to work and maybe be better anyways to align the height, but figured I should mention that since it's something different I've seen.

The second is about the certain games I see that are possibly the wrong resolutions, like mk dbz and any game that reports a 1.5 or greater aspect ratio, that always seems to indicate it'll be too wide.  I checked what the utilities like AVres do for these, and kind of figured out a way to make them work and seems to be what AVres does too.  For these games I have a hack, but it's not enabled by default, where we walk up the height of the active lines till the aspect is 1.3 again.   It seems to always equal what AVres does and actually makes games like dbz pretty close to perfect, then I also enable the 'unevenstretch' to make them utilize that screen size and at that they fit right since otherwise they are top/bottom boxed and seem a little wide I think (at least don't think they'd be letter boxed on an arcade machine unless were really on a 16:9 monitor, doubtful). These variables I use are $ASPECT_LARGE_HACK  and there's a _SMALL_HACK version which I'm less sure of but does make games like Golden Tee which are oddly boxed on top and bottom fill up the screen.  It's the opposite and has the less than 1.2 aspect ratio and for some reason gets big top/bottom right/left margins. 

So those are the two odd cases I see with the either too big or two small games, and always seems to follow aspect ratio even though there are plenty of course which work fine with smaller aspect ratios than 1.3 and seem like they were just meant to stretch and have non-square pixels (would be nice to know a way to figure out which are right and which are needing the hack).  I think the AVRes utility somewhat figures these things out, although not sure, the utility doesn't make a lot of great decisions from what I've experienced but this is one area it seems to somehow know something I don't about guessing how to get the games to fit right.  Also I don't like the use of unevenstretch and that bothers me I have to do that, I have figured out that giving DBZ a 400x288 resolution works too without stretch but to get there automatically from the default of 384x256 seems really a bit unpredictable since I don't see an easy way to have calculated that (this sort of seems like what I did with the raise the height till 1.3 aspect then multiply that times the original odd 1.5 aspect and it would maybe get that 400x288, yet I didn't fully like doing that and might have found it not to be 100% correct). 

[bitbytebit]

All issues have been solved with this version, I'll keep testing...

One question I have about the doublescan vtotal amount, seems weird, I always get these .5 values to it and rounding up seemed to be bad and change the vertical refresh rate, seems like the linux DRM stuff rounds down or chops the decimal anyways, so should I just do that for something like this...


# transfrm  256x192@60.00 25.620Khz
Modeline "256x192x60.00" 9.223200 256 288 320 360 192 198 200 213.5 -HSync -VSync doublescan

You can either round up or chop, I prefer rounding up to avoid reducing the back porch. But always use integer elements if you want to properly predict the resulting vfreq, if you let Linux chop the values for you, your pre-calculated frequencies won't be accurate. So, what you have to do is convert to integers, and then, calculate your dotclock only once you have your definitive vvt and hht values.

So once you have vvt and hht, you can adjust dotclock so it fits your initial vfreq. Until now, you've been using granularity-free dotclocks, that's good for now, as it allows you to properly adjust to your initial vfreq whatever vvt and hht you have. However, that may not be true, and if it turns out that the dotclock has also a discrete nature, as it happens with Windows drivers, then if you want to be really accurate you have to deal with the problem of achieving a required vfreq out of three discrete values: dotclock, hht, vvt. That's why I made that interative loop, to test different combinations of discrete values for dotclock, hht, vvt, to see which one produced the closest vfreq. Using just 5 iterations, you can usually go as close as 0.02 Hz. But the disadvantage is that this method introduces additional verical padding, that even if it doesn't affect the picture at all, can colide with our brand new weighting system...

I got it working I think using either a file of dotclocks like yours, but without the index numbers and only dotclocks, or a command line option to say align to some Hz value.  It's interesting, I don't see my OSD saying it's any different for any of the games except for 1 that now says 40Hz instead of 39.9Hz (it only goes out one decimal place on the OSD unfortunately).  So I can't say if the monitor is not exact or that this newer radeon has different clocks, could be working or not, I'm not sure how to tell.  I can push the dotclock increment up to about 10000 and force it to go up but then it's kinda bad cause the lines completely change and kills games like pacman for me at more than 312 lines.  I am starting to think that the increment doesn't matter in Linux and that the monitor is just off on measurement by a .10 value or less.  It seems pretty consistent on the amount it's always off of the calculated vertical refresh and what the xrandr output says is the value for it.  It's at least something you may want to look at and see if you can see anything interesting, and also now of course could be used in WIndows under these restrictions and be more exact there.

[Calamity]

I'm interested in creating a function to do your same figuring based upon dotclock values not being granular.  One thing I read somewhere, on why the cvt calculations always are in 250 aligned amounts, is because modern video cards they claim aren't often able to get more fine grained than that.  So it would be interesting for that, at least to see how that affects the line padding.  Also then I could test plugging in your table of ATI values and really see if my d9800 suddenly perfectly hits the vrefresh rates on the OSD, I'm not sure if it's an accurate calculation it's doing though so it'd be interesting since if it did suddenly show perfect values it'd prove both the need for the dotclock check and that the OSD is accurate.

It would be very interesting to see if we can get more exact dotclocks with Linux than what's possible in Windows, where the dotclock is stored using a BCD, for instance 6.640 MHz would be 06, 64, that's all the precision we have, so it helps to know beforehand what exact dotclock value will be produced out of that, in case 06, 63 or 06, 65 could be closer for our requested Vfreq. Your OSD can be very useful to check this, although the value shown only has one decimal I believe (or more?)

Also two other things I've been seeing.  One is that it seems that the Linux DRM stuff requires the vertical height, only active lines, to be a division of 8 or else it will cause mame to lock until forcibly killed off, just gets stuck in a black screen and then have to restart X cause the OpenGL/SDL layer is all messed up and fonts are weird (really small).  That's something that started happening on certain games after I started using the DRM stuff, and took a heck of a time to finally figure out that it was the height not being multiples of 8 and those were the games I was seeing this on.  So for now it seems to work and maybe be better anyways to align the height, but figured I should mention that since it's something different I've seen.

That's a very important finding, as some games have vertical heights like 239, so that will need to be checked to round all heights to the upper 8-multiple. Fortunately the virtualize function is already doing that when it's used.

The second is about the certain games I see that are possibly the wrong resolutions, like mk dbz and any game that reports a 1.5 or greater aspect ratio, that always seems to indicate it'll be too wide.  I checked what the utilities like AVres do for these, and kind of figured out a way to make them work and seems to be what AVres does too.  For these games I have a hack, but it's not enabled by default, where we walk up the height of the active lines till the aspect is 1.3 again.   It seems to always equal what AVres does and actually makes games like dbz pretty close to perfect, then I also enable the 'unevenstretch' to make them utilize that screen size and at that they fit right since otherwise they are top/bottom boxed and seem a little wide I think (at least don't think they'd be letter boxed on an arcade machine unless were really on a 16:9 monitor, doubtful). These variables I use are $ASPECT_LARGE_HACK  and there's a _SMALL_HACK version which I'm less sure of but does make games like Golden Tee which are oddly boxed on top and bottom fill up the screen.  It's the opposite and has the less than 1.2 aspect ratio and for some reason gets big top/bottom right/left margins. 

So those are the two odd cases I see with the either too big or two small games, and always seems to follow aspect ratio even though there are plenty of course which work fine with smaller aspect ratios than 1.3 and seem like they were just meant to stretch and have non-square pixels (would be nice to know a way to figure out which are right and which are needing the hack).  I think the AVRes utility somewhat figures these things out, although not sure, the utility doesn't make a lot of great decisions from what I've experienced but this is one area it seems to somehow know something I don't about guessing how to get the games to fit right.  Also I don't like the use of unevenstretch and that bothers me I have to do that, I have figured out that giving DBZ a 400x288 resolution works too without stretch but to get there automatically from the default of 384x256 seems really a bit unpredictable since I don't see an easy way to have calculated that (this sort of seems like what I did with the raise the height till 1.3 aspect then multiply that times the original odd 1.5 aspect and it would maybe get that 400x288, yet I didn't fully like doing that and might have found it not to be 100% correct). 

I've always considered this to be bad reported resolutions and haven't think much about this, apart from patching all of them some day, but after reading this I'm curious to have a closer look to this and see what's going on and if aspect checking can be used here.

Just for having a test list, I remember dbz, one of the newer golden axes, golden tee, any other one?
There was also that other issue with games that reported less xres than real, like thunder force.

[bitbytebit]

I'm interested in creating a function to do your same figuring based upon dotclock values not being granular.  One thing I read somewhere, on why the cvt calculations always are in 250 aligned amounts, is because modern video cards they claim aren't often able to get more fine grained than that.  So it would be interesting for that, at least to see how that affects the line padding.  Also then I could test plugging in your table of ATI values and really see if my d9800 suddenly perfectly hits the vrefresh rates on the OSD, I'm not sure if it's an accurate calculation it's doing though so it'd be interesting since if it did suddenly show perfect values it'd prove both the need for the dotclock check and that the OSD is accurate.

It would be very interesting to see if we can get more exact dotclocks with Linux than what's possible in Windows, where the dotclock is stored using a BCD, for instance 6.640 MHz would be 06, 64, that's all the precision we have, so it helps to know beforehand what exact dotclock value will be produced out of that, in case 06, 63 or 06, 65 could be closer for our requested Vfreq. Your OSD can be very useful to check this, although the value shown only has one decimal I believe (or more?)

Also two other things I've been seeing.  One is that it seems that the Linux DRM stuff requires the vertical height, only active lines, to be a division of 8 or else it will cause mame to lock until forcibly killed off, just gets stuck in a black screen and then have to restart X cause the OpenGL/SDL layer is all messed up and fonts are weird (really small).  That's something that started happening on certain games after I started using the DRM stuff, and took a heck of a time to finally figure out that it was the height not being multiples of 8 and those were the games I was seeing this on.  So for now it seems to work and maybe be better anyways to align the height, but figured I should mention that since it's something different I've seen.

That's a very important finding, as some games have vertical heights like 239, so that will need to be checked to round all heights to the upper 8-multiple. Fortunately the virtualize function is already doing that when it's used.

The second is about the certain games I see that are possibly the wrong resolutions, like mk dbz and any game that reports a 1.5 or greater aspect ratio, that always seems to indicate it'll be too wide.  I checked what the utilities like AVres do for these, and kind of figured out a way to make them work and seems to be what AVres does too.  For these games I have a hack, but it's not enabled by default, where we walk up the height of the active lines till the aspect is 1.3 again.   It seems to always equal what AVres does and actually makes games like dbz pretty close to perfect, then I also enable the 'unevenstretch' to make them utilize that screen size and at that they fit right since otherwise they are top/bottom boxed and seem a little wide I think (at least don't think they'd be letter boxed on an arcade machine unless were really on a 16:9 monitor, doubtful). These variables I use are $ASPECT_LARGE_HACK  and there's a _SMALL_HACK version which I'm less sure of but does make games like Golden Tee which are oddly boxed on top and bottom fill up the screen.  It's the opposite and has the less than 1.2 aspect ratio and for some reason gets big top/bottom right/left margins. 

So those are the two odd cases I see with the either too big or two small games, and always seems to follow aspect ratio even though there are plenty of course which work fine with smaller aspect ratios than 1.3 and seem like they were just meant to stretch and have non-square pixels (would be nice to know a way to figure out which are right and which are needing the hack).  I think the AVRes utility somewhat figures these things out, although not sure, the utility doesn't make a lot of great decisions from what I've experienced but this is one area it seems to somehow know something I don't about guessing how to get the games to fit right.  Also I don't like the use of unevenstretch and that bothers me I have to do that, I have figured out that giving DBZ a 400x288 resolution works too without stretch but to get there automatically from the default of 384x256 seems really a bit unpredictable since I don't see an easy way to have calculated that (this sort of seems like what I did with the raise the height till 1.3 aspect then multiply that times the original odd 1.5 aspect and it would maybe get that 400x288, yet I didn't fully like doing that and might have found it not to be 100% correct). 

I've always considered this to be bad reported resolutions and haven't think much about this, apart from patching all of them some day, but after reading this I'm curious to have a closer look to this and see what's going on and if aspect checking can be used here.

Just for having a test list, I remember dbz, one of the newer golden axes, golden tee, any other one?
There was also that other issue with games that reported less xres than real, like thunder force.

Yeah the OSD only does one decimal place unfortunately, and I really think it's .10 off always because now looking it's consistently that way on just about everything.

I wonder if it's a bug in the DRM layer that is causing the 8 line issue, isn't it normally only horizontal that really technically needs this and the lines don't really matter?  They might be doing something odd there, I saw some comments about something like 8 line alignment and the DRM people might have tried to force that or not realize they broke anything other than that alignment.

Interesting, I can fix the thunder force with my hacks then, seems to work, here's a diff to make them able to get enabled by the config file or command line.  Also the modeline generated after the fix is:

# tfrceac 304x224@60.02 15.306Khz
     Modeline "304x224x60.02" 5.999846 304 320 352 392 224 232 235 255 -HSync -VSync

It's the exact as the mobile gundam game, same issue, which is the one I compared to dbz as opposite of the issues it has.

Code: [Select]


diff --git a/switchres b/switchres
index 4cb3719..ceef492 100755
--- a/switchres
+++ b/switchres
@@ -192,6 +192,10 @@ sub main() {
                        $VECTORWIDTH = $value;
                } elsif ($key eq "vectorheight") {
                        $VECTORWIDTH = $value;
+               } elsif ($key eq "LargeAspectHack") {
+                       $ASPECT_LARGE_HACK = $value;
+               } elsif ($key eq "SmallAspectHack") {
+                       $ASPECT_SMALL_HACK = $value;
                } else {
                        print "Warning: unknown config option '$key' in $CONFIG_FILE\n";
                }
@@ -206,6 +210,8 @@ sub main() {
                print "  -getres <game>       Only calculate a mame games resolution then exit\n";
                print "  -nomrs               Don't use MAME -switchres SDL switching, directly use xrandr instead\n";
                print "  -ff                  Enable Frogger/Galaxian fix (if MAME is patched for it)\n";
+               print "  -sah                 Enable Small Aspect Hack, games reporting too small aspect or too narrow\n";
+               print "  -lah                 Enable Large Aspect Hack, games reporting too small aspect or too small vertically\n";
                print "  -redraw <value>      Enable Redraw fix auto or a value (if MAME is patched for it)\n";
                print "  -mon <monitor_type>  Type of Arcade Monitor\n";
                print "                       Supported monitors: $SUPPORTED_MONITORS\n";
@@ -360,6 +366,10 @@ sub main() {
                        $FROGGER_FIX = 1;       
                } elsif ($ARGV[$arg_num] =~ /^\-nomrs/) {
                        $USE_MAME_RES = 0;     
+               } elsif ($ARGV[$arg_num] =~ /^\-lah/) {
+                       $ASPECT_LARGE_HACK = 1;
+               } elsif ($ARGV[$arg_num] =~ /^\-sah/) {
+                       $ASPECT_SMALL_HACK = 1;
                } elsif ($ARGV[$arg_num] =~ /^\-dotclocksfile$/) {
                        if ($ARGV[$arg_num+1] ne "" && $ARGV[$arg_num+1] !~ /^-/) {
                                $arg_num++;



[Calamity]

I got it working I think using either a file of dotclocks like yours, but without the index numbers and only dotclocks, or a command line option to say align to some Hz value.  It's interesting, I don't see my OSD saying it's any different for any of the games except for 1 that now says 40Hz instead of 39.9Hz (it only goes out one decimal place on the OSD unfortunately).  So I can't say if the monitor is not exact or that this newer radeon has different clocks, could be working or not, I'm not sure how to tell.  I can push the dotclock increment up to about 10000 and force it to go up but then it's kinda bad cause the lines completely change and kills games like pacman for me at more than 312 lines.  I am starting to think that the increment doesn't matter in Linux and that the monitor is just off on measurement by a .10 value or less.  It seems pretty consistent on the amount it's always off of the calculated vertical refresh and what the xrandr output says is the value for it.  It's at least something you may want to look at and see if you can see anything interesting, and also now of course could be used in WIndows under these restrictions and be more exact there.

It's good to have that implemented at least for Windows use. However, it is perfectly possible that your OSD is not accurate. There are also some indirect ways to test it. One is patching Mame to show it's speed in Hz instead of percentages, with several decimals, then you vsync with no-throttle. I believe I posted a patch for doing this some pages ago, though I can confirm its semi-obsolote and needs updating for the newer versions. Instant speed measure will always be a bit erratic as it's measured using cpu's clock that has also it's own granularity, but if you wait enough your average speed will slowly converge to the real one, unless your system is randomly stealing cpu time from your process and Mame gets slowed for an instant, then that average can be corrupted (usual in Windows). I think there's also a way to make normal Mame post it's average speed on exit. I made an special program to measure video modes vfreq. Once you have some confirmed values, you can make calculations backwards and obtain the actual dotclock being used, and if it more or less matches to one you entered, then this stuff won't be necessary at all.

[Calamity]

Interesting, I can fix the thunder force with my hacks then, seems to work, here's a diff to make them able to get enabled by the config file or command line.  Also the modeline generated after the fix is:

# tfrceac 304x224@60.02 15.306Khz
     Modeline "304x224x60.02" 5.999846 304 320 352 392 224 232 235 255 -HSync -VSync

It's the exact as the mobile gundam game, same issue, which is the one I compared to dbz as opposite of the issues it has.

That's great, I remember Bonanza Bros, Puzzle Action and those also having some issue.

[bitbytebit]

I got it working I think using either a file of dotclocks like yours, but without the index numbers and only dotclocks, or a command line option to say align to some Hz value.  It's interesting, I don't see my OSD saying it's any different for any of the games except for 1 that now says 40Hz instead of 39.9Hz (it only goes out one decimal place on the OSD unfortunately).  So I can't say if the monitor is not exact or that this newer radeon has different clocks, could be working or not, I'm not sure how to tell.  I can push the dotclock increment up to about 10000 and force it to go up but then it's kinda bad cause the lines completely change and kills games like pacman for me at more than 312 lines.  I am starting to think that the increment doesn't matter in Linux and that the monitor is just off on measurement by a .10 value or less.  It seems pretty consistent on the amount it's always off of the calculated vertical refresh and what the xrandr output says is the value for it.  It's at least something you may want to look at and see if you can see anything interesting, and also now of course could be used in WIndows under these restrictions and be more exact there.

It's good to have that implemented at least for Windows use. However, it is perfectly possible that your OSD is not accurate. There are also some indirect ways to test it. One is patching Mame to show it's speed in Hz instead of percentages, with several decimals, then you vsync with no-throttle. I believe I posted a patch for doing this some pages ago, though I can confirm its semi-obsolote and needs updating for the newer versions. Instant speed measure will always be a bit erratic as it's measured using cpu's clock that has also it's own granularity, but if you wait enough your average speed will slowly converge to the real one, unless your system is randomly stealing cpu time from your process and Mame gets slowed for an instant, then that average can be corrupted (usual in Windows). I think there's also a way to make normal Mame post it's average speed on exit. I made an special program to measure video modes vfreq. Once you have some confirmed values, you can make calculations backwards and obtain the actual dotclock being used, an-sdlvideofpsd if it more or less matches to one you entered, then this stuff won't be necessary at all.

This option -sdlvideofps for SDL mame I think does that, and interestingly shows a slight difference I think but I'm still looking at that.

Yeah the Small Aspect hack works for those, although I don't fully like it because it also catches other games that don't need it like super mario and from what I can tell degrades it slightly at 320x240 instead of the 254x240 it wants.  The Large Aspect hack seems to always work better than any game reporting a large aspect ratio, so it might be somewhat good.  I just can't figure out yet how to tell the games that have the lower aspect ratio which need to be wider and the ones that are fine, not sure if somehow mame may have more info inside of it to help.

[bitbytebit]

It's looking quite odd actually when using that SDL fps output.  Seems that your dotclock values do somewhat get the games closer, sometimes the first value is exact then the others are just slightly lower.  Without it sometimes the first value is exact but lower than it still.  Weirdly when I use an alignment of 10 it takes forever but can get just about everything to run at the perfect vertical refresh.  The problem is it seems to add more lines than otherwise, and pacman become wide again and there's a slight top/bottom margin on other games.  So I'm not sure what it means yet, possibly in Linux we can really use any dotclock and the function is just really getting the exact dotclock needed to run it and vertical lines.  At the same time it seems to be adding too many lines and would be nice to avoid that, but I'm not sure if that's impossible and it's a tradeoff.  Otherwise things run pretty much at a .03 or so precision, without the dotclock checks or alignment, they are close but usually 99.9% or something like that.  The value of 250 does seem benign and sometimes makes things run a little closer, and your values do too, still not sure which are more exact.

[Calamity]

This option -sdlvideofps for SDL mame I think does that, and interestingly shows a slight difference I think but I'm still looking at that.

Great, I didn't know about that option.

Yeah the Small Aspect hack works for those, although I don't fully like it because it also catches other games that don't need it like super mario and from what I can tell degrades it slightly at 320x240 instead of the 254x240 it wants.  The Large Aspect hack seems to always work better than any game reporting a large aspect ratio, so it might be somewhat good.  I just can't figure out yet how to tell the games that have the lower aspect ratio which need to be wider and the ones that are fine, not sure if somehow mame may have more info inside of it to help.

I see. I think I know what you mean with AVres managing that stuff, are you using the 'proportional' option in that program? BTW, I heard it was proposed to AVres programmer by Elaphe, a folk from the Spanish forums, as a way compensate for non-square pixel aspect of some games. I believe it's kind of repairing those other games too, but not sure if it was aimed for that. However, even if it can be an useful option for people with difficult access to monitor adjustments, and definitely worth having available, I feel that unless necessary, it goes against the philosophy of achieving the real original arcade resolution for each game (some might say our virtualization stuff also does)... as I understand it, in the analog world 4:3 aspect accounts for the shape of the target monitor, not the resolution itself, so we should not do 320/224 = 1.43 and say our aspect ratio is above 4:3, as there were tons of games using this resolution that are genuine 4:3 games, so when the PCB was plugged the guy was supposed to adjust vertical size to the borders of the screen separating scanlines a bit, and it becomes obvious that it was the expected adjustment when you see that explosions and round stuff look like circles and lot ellipses when doing that.

[Calamity]

Otherwise things run pretty much at a .03 or so precision, without the dotclock checks or alignment, they are close but usually 99.9% or something like that.  The value of 250 does seem benign and sometimes makes things run a little closer, and your values do too, still not sure which are more exact.

If you can already predict your resulting vfreq with 0.03 precision without the use of the table then there's no need for using it at all, so you can keep your code simple.

There's something, however, that I'm wondering... when those extra lines are added, does your picture get any different, maybe with more vertical margins? That's what I meant when I asked if your monitor was autoadjusting, as usually you don't see any difference when adding more lines as vertical size is constant until you manually adjust it.

[bitbytebit]

Otherwise things run pretty much at a .03 or so precision, without the dotclock checks or alignment, they are close but usually 99.9% or something like that.  The value of 250 does seem benign and sometimes makes things run a little closer, and your values do too, still not sure which are more exact.

If you can already predict your resulting vfreq with 0.03 precision without the use of the table then there's no need for using it at all, so you can keep your code simple.

There's something, however, that I'm wondering... when those extra lines are added, does your picture get any different, maybe with more vertical margins? That's what I meant when I asked if your monitor was autoadjusting, as usually you don't see any difference when adding more lines as vertical size is constant until you manually adjust it.

Yeah I guess it seems to do pretty well then, interesting, not exact but much more than in Windows I guess and anything closer I guess would be a bit picky (and gets more lines I guess)...

It's weird because basically with pacman it will get wide and still touch the top/bottom evenly, other games putting more lines will squish them down and leave a margin.  Then there's a few of the lower resolution games like food fight, that very rarely but hardly ever come up really skinny but reloading them makes them fine again.  On super mario it's always got about an inch of space on the sides but once in a while, every 20 loads, it'll be perfect and touching the sides of the screen.  So some games rarely get super skinny like they are vertical, some have margins mostly but  once in awhile are perfectly fitting.  It's odd, the pacman thing is extreme and I know exactly how to prevent it now and what causes it.  The others are a mystery but so rare it doesn't really bother me but I am guessing it may be a slight limit issue of lines or the horizontal frequency perhaps. 

[bitbytebit]

I ported the core modeline generator part and the general structure of switchres to C, it's a trimmed down of just the main modeline generation code right now and only takes the height width refresh as args just like other modeline generators do.  This is helpful because with this code we could easily put it into the Linux kernel, it already has CVT in there so this could be an alternative.  Also of course it's easier to deal with in Windows without worrying about Perl, a lot slimmer in resource usage and the code is a lot cleaner cause perl is really weird about variables (they can be anything and this precision math is bad in that setup).  It actually seems a lot easier to write in C because it was simple to pass everything in structures and the math just worked like it should with there actually being a round function and other math stuff there.

So play with this possibly and see if you can find bugs in the modeline generation, there must be some, but it seems to recreate all the basic modelines I have tried same as switchres so far.  Right now it's only set hardcoded with the CGA monitor settings, and not really too advanced in how it'll deal with the multiple ranges cause I'm still thinking about that.  It's probably a good display though of the modeline generator though trimmed down and should stay that way because I've separated off just that stuff into a separate file and plan on keep the functions pretty much like they are and do the extra stuff I left out in other places.

I figure this can be the 1.00 branch and go from there, with the perl version still following for now till I move the functionality completely into this.  It's interesting since we should be able to link to and do xrandr stuff native in the future and leave it out when compiling for Windows, maybe someday figure out a way to patch this into mame and just have it do the work from there, at least in Linux it would be a useful thing for the -switchres argument to do.

[Calamity]

Wow it's great to have this in C! It will be easier for Windows users and we could eventually plug the dynamic modeline functionallity into it for people using patched drivers.I'm going to try to compile and do some testing.

[bitbytebit]

Wow it's great to have this in C! It will be easier for Windows users and we could eventually plug the dynamic modeline functionallity into it for people using patched drivers.I'm going to try to compile and do some testing.

Here's an update, I added all the monitor types and now takes a --monitor <type> arg.  There's something odd going on where for some reason on the d9800 and any multi range monitor I am not getting the same results as the perl version.  On all the CGA/h9110 monitors I get the same modelines as the perl version though, so it's definitely a bit strange.  Also this fixes doublescan support, weights things similar to the perl version and prints out verbose info with -v sort of.

I realized that it really would be best to convert it to C, and actually besides some busy work on those string things and config file reading which I mostly have already anyways in other code I've written, it's hopefully going to make this easier to deal with the calculation stuff.  Also definitely was wanting to get away from a Perl dependency, and all the other issues with perl, but it's a great way to prototype and start things.

[bitbytebit]

Wow it's great to have this in C! It will be easier for Windows users and we could eventually plug the dynamic modeline functionallity into it for people using patched drivers.I'm going to try to compile and do some testing.

Here's an update, I added all the monitor types and now takes a --monitor <type> arg.  There's something odd going on where for some reason on the d9800 and any multi range monitor I am not getting the same results as the perl version.  On all the CGA/h9110 monitors I get the same modelines as the perl version though, so it's definitely a bit strange.  Also this fixes doublescan support, weights things similar to the perl version and prints out verbose info with -v sort of.

I realized that it really would be best to convert it to C, and actually besides some busy work on those string things and config file reading which I mostly have already anyways in other code I've written, it's hopefully going to make this easier to deal with the calculation stuff.  Also definitely was wanting to get away from a Perl dependency, and all the other issues with perl, but it's a great way to prototype and start things.

I found the bug, hfreq calculation was messed up, this version should now match things properly from what I can tell so far.

Update: More bugs fixed with virtualize function and added minimum yres parameter again to command line for doublescan, also now actually will virtualize too, that was badly broken from some copy/paste errors .

[Calamity]

I've finally compiled the new C version, it works pretty well for what I'm seeing. (I tried to compile before but 'version.h' was not included in the package I think)

However, I'm again having this issue with 512x480@60 mode not respecting vfreq:

(version 1.00c)

Code: [Select]

switchres 512 480 60 --monitor h9110 -v -v -v
[] on h9110 Monitor 512x480@60.000 Resolution
Setup monitor limits min=184x112 max=0x576
Using interlace
Lowered horizontal frequency to  16.670 vfreq 63.870
# 15.625Khz -> 16.670Khz: ( | Hfreq Change | Vref Change | Interlace | )
# [21] 512x480@63.87 16.7019Khz
     "512x480x63.87" 14.029624 512 608 712 840 480 482 488 523 -HSync -VSync interlace

I'm also seeing the same with the perl version (0.28)

Code: [Select]

Default Mode: 641x480@60
Monitor Limits: 184x112 min res 576 max yres
Interlacing: 480 lines.
Lowered hfreq 31.196Khz to 16.670Khz VRefresh 60.00Hz to 63.87Hz
Modeline Calculation of 11.490931Mhz 63.870Hz 16.702Khz 261.5 vtotal 21.5 vblank 0 vpad

# 15.625Khz --> 16.670Khz: ( | Vertical refresh raised | Horizontal frequency lowered | Interlaced | )
# [12] - 512x480@63.87 16.702Khz
     Modeline "512x480x63.87" 11.490931 512 536 592 688 480 482 487 523 -HSync -VSync interlace

#  512x480@63.87 16.702Khz
     Modeline "512x480x63.87" 11.490931 512 536 592 688 480 482 487 523 -HSync -VSync interlace
I'll keep testing...

[Calamity]

Here's an update, I added all the monitor types and now takes a --monitor <type> arg.  There's something odd going on where for some reason on the d9800 and any multi range monitor I am not getting the same results as the perl version.  On all the CGA/h9110 monitors I get the same modelines as the perl version though, so it's definitely a bit strange.  Also this fixes doublescan support, weights things similar to the perl version and prints out verbose info with -v sort of.

I realized that it really would be best to convert it to C, and actually besides some busy work on those string things and config file reading which I mostly have already anyways in other code I've written, it's hopefully going to make this easier to deal with the calculation stuff.  Also definitely was wanting to get away from a Perl dependency, and all the other issues with perl, but it's a great way to prototype and start things.

Definitely a C version will make things easier in Windows. I like learning all this stuff that's new for me, I was amazed at how powerful Perl seems to deal with strings and xml, it was a lot of boring work for me to do that in Basic. However it can be a bit complicated for an average Windows user as me. I'm not a serious programmer after all, just for hobby, and though I've finished some projects with Masm32 and PowerBasic, never seriously touched C, but for reading code and ripping stuff for Masm32, etc. I'm happy that someone with your coding skills has focused development on this stuff, that was really needed for proper emulation.

[Calamity]

Interesting: some games affected by bad reported resolutions are from the drivers segas32.c and segac2.c, in MAWS you can read that their resolutions were fixed at some point to this new size, that at least for segac2.c games I'm almost sure is not correct.

[bitbytebit]

I've finally compiled the new C version, it works pretty well for what I'm seeing. (I tried to compile before but 'version.h' was not included in the package I think)

However, I'm again having this issue with 512x480@60 mode not respecting vfreq:

(version 1.00c)

Code: [Select]

switchres 512 480 60 --monitor h9110 -v -v -v
[] on h9110 Monitor 512x480@60.000 Resolution
Setup monitor limits min=184x112 max=0x576
Using interlace
Lowered horizontal frequency to  16.670 vfreq 63.870
# 15.625Khz -> 16.670Khz: ( | Hfreq Change | Vref Change | Interlace | )
# [21] 512x480@63.87 16.7019Khz
     "512x480x63.87" 14.029624 512 608 712 840 480 482 488 523 -HSync -VSync interlace

I'm also seeing the same with the perl version (0.28)

Code: [Select]

Default Mode: 641x480@60
Monitor Limits: 184x112 min res 576 max yres
Interlacing: 480 lines.
Lowered hfreq 31.196Khz to 16.670Khz VRefresh 60.00Hz to 63.87Hz
Modeline Calculation of 11.490931Mhz 63.870Hz 16.702Khz 261.5 vtotal 21.5 vblank 0 vpad

# 15.625Khz --> 16.670Khz: ( | Vertical refresh raised | Horizontal frequency lowered | Interlaced | )
# [12] - 512x480@63.87 16.702Khz
     Modeline "512x480x63.87" 11.490931 512 536 592 688 480 482 487 523 -HSync -VSync interlace

#  512x480@63.87 16.702Khz
     Modeline "512x480x63.87" 11.490931 512 536 592 688 480 482 487 523 -HSync -VSync interlace
I'll keep testing...

It's hitting this code right here...

Code: [Select]


        /* Minimum horizontal frequency */
        if (mode->hfreq < monitor->HfreqMin) {
                mode->hfreq = monitor->HfreqMin;
                mode->result |= RESULT_HFREQ_CHANGE;
                if (verbose > 1)
                        fprintf(stderr, "Decreased horizontal frequency to %.3f\n",
                                mode->hfreq/1000);
        } else if (mode->hfreq > monitor->HfreqMax) {
                if (mode->vactive > monitor->ActiveLinesLimit &&
                     monitor->interlace && interlace == 1)
                {
                        interlace = 2;
                        mode->interlace = 1;
                        ResVirtualize(mode, monitor);
                        mode->result |= RESULT_INTERLACE | RESULT_VIRTUALIZE;
                } else {
                        mode->hfreq = monitor->HfreqMax;
                        VBlankLines = round(mode->hfreq * monitor->VerticalBlank);
                        mode->vfreq = mode->hfreq / (mode->vactive / interlace + VBlankLines);
                        mode->result |= RESULT_HFREQ_CHANGE;
                        if (verbose > 1)
                                fprintf(stderr, "Lowered horizontal frequency to  %.3f vfreq %.3f\n",
                                        mode->hfreq/1000, mode->vfreq);
                }
        }



Which is originally this...

Code: [Select]



  IF hfreq < HfreqMin THEN
    hfreq = HfreqMin
  ELSEIF hfreq > HfreqMax THEN
    IF yres > ActiveLinesLimit THEN
      ResVirtualize ( xres, yres, vfreq, hfreq )
      interlace = 2
      result = result OR %VirtualizedRes
    ELSE
      hfreq = HfreqMax
      VBlankLines = ROUND ( hfreq * VerticalBlank, 0 )
      vfreq = hfreq / ( yres / interlace + VBlankLines )
      result = result OR %BadVfreq
    END IF
  END IF



Is there a way to get it to keep the correct vertical frequency in that case?  I'm not sure but suspecting it's hitting the limit of the hfreq max and when it lowers it then the vertical frequency has to go up?

[bitbytebit]

Here's an update, I added all the monitor types and now takes a --monitor <type> arg.  There's something odd going on where for some reason on the d9800 and any multi range monitor I am not getting the same results as the perl version.  On all the CGA/h9110 monitors I get the same modelines as the perl version though, so it's definitely a bit strange.  Also this fixes doublescan support, weights things similar to the perl version and prints out verbose info with -v sort of.

I realized that it really would be best to convert it to C, and actually besides some busy work on those string things and config file reading which I mostly have already anyways in other code I've written, it's hopefully going to make this easier to deal with the calculation stuff.  Also definitely was wanting to get away from a Perl dependency, and all the other issues with perl, but it's a great way to prototype and start things.

Definitely a C version will make things easier in Windows. I like learning all this stuff that's new for me, I was amazed at how powerful Perl seems to deal with strings and xml, it was a lot of boring work for me to do that in Basic. However it can be a bit complicated for an average Windows user as me. I'm not a serious programmer after all, just for hobby, and though I've finished some projects with Masm32 and PowerBasic, never seriously touched C, but for reading code and ripping stuff for Masm32, etc. I'm happy that someone with your coding skills has focused development on this stuff, that was really needed for proper emulation.

Perl is nice for strings, but pays a price in how much overhead it uses and also everything in perl is a string and that's a problem with math like you do .  That one function to find the dotclock, I realized it didn't work right in perl because your comparing numbers like .0002 and in Perl it actually can't do that unless you do a real odd hack of checking it like an actual string instead.  Plus rounding in Perl goes towards the even number always or something odd like that, so it's not real rounding.  Lots of things, some of the little bugs in C so far I've had come up were from having things back to normal math and the Perl thing I did no longer did it right.  I've fortunately spent years writing C programs, did a lot of kernel programming on a video capture card driver in Linux  (ivtv one for the Hauppauge PVR cards), I was the author of most of that driver and reverse engineered a lot of how to work with the firmware, have wrote a custom video encoder/decoder using the ffmpeg API too.  So I'm glad to have this to work on because I really like it when I can actually write things in C and I'm interested in the way I can pass structures easily around the functions instead of in Perl I was having to do some terrible stuff.  The XML stuff of course really can be ripped from lrmc because I had to alter that anyways and it should be pretty much the same just for one game and grab it from a memory buffer instead of file.  Config files fortunately I've got a parser I wrote for a program that is simply the same format I used for switchres already so should be backward compatible, I'm hoping that's not going to be too difficult just to move into it. 

The version.h file is generated by the version.sh script, but it's a unix bash script and so wouldn't run of course in Windows unless running in Cygwin to compile.  That'll probably be the best way since it's how I'll be compiling it, but of course for Windows I'll be able to make a binary release easily too so won't matter much how it was compiled (definitely nice about windows how that works).  I'm going to have to make a dependency on the libxml stuff anyways (which in perl for switchres I was just raw reading the XML my self, because I had used the perl XML stuff in an early version of genres before lrmc wrote out the .ini files and didn't like it too much cause oddly in XML it's hard to tell some things like when they have 2 display sections for multiscreen games I had to do something different to know there were 2 in Perl and C, Perl it was way more hackish I think, will find out I guess since in C I don't really want to rewrite an XML parser .

[bitbytebit]

Here's a snapshot of the C version, now able to use mame for game resolution information from the XML output again, read .ini files properly for the resolution, utilize the switchres.conf file agian and some extra command line options added.  

So now can play around with it and compare games easier, and by itself hopefully is a nice modeline generator utilizing mame if given a game name.  Now basically if you give it the game name it spits out the info, or resolution, config file should be the same syntax for the most part of useful options.  I still haven't gotten the ability to feed in config lines for monitor ranges but should be able to do that next.

Also I have a precompiled Windows binary and needed .dll files in a .7z package included too so it doesn't have to be compiled for Windows, since needs Cygwin for that and libxml2 development packages for the mame XML output parsing.  

[Calamity]

Is there a way to get it to keep the correct vertical frequency in that case?  I'm not sure but suspecting it's hitting the limit of the hfreq max and when it lowers it then the vertical frequency has to go up?

I think I've repaired it by placing this:

   /* Horizontal frequency */
   mode->hfreq = mode->vfreq * mode->vactive /
         (interlace * (1.0 - mode->vfreq * monitor->VerticalBlank));

... below /* check vertical active lines */ block, as it was originally. That formula uses interlace value, so if you place it before interlace is decided it will fail.

[bitbytebit]

Is there a way to get it to keep the correct vertical frequency in that case?  I'm not sure but suspecting it's hitting the limit of the hfreq max and when it lowers it then the vertical frequency has to go up?

I think I've repaired it by placing this:

   /* Horizontal frequency */
   mode->hfreq = mode->vfreq * mode->vactive /
         (interlace * (1.0 - mode->vfreq * monitor->VerticalBlank));

... below /* check vertical active lines */ block, as it was originally. That formula uses interlace value, so if you place it before interlace is decided it will fail.

Great, now it works right and I see how not to calculate that till later.  I also found another place I calculated it again and shouldn't have .  

I have a new version in C, command line args have changed slightly and this pretty much fully works in Linux at running the games now in mame and using xrandr too.  I'd say this one is pretty much useful and fully works for running mame games in Linux with Xrandr or a modeline generator of course.  It's missing all the extra features right now like running other emulators, writing out the modelines generated to a file, or reading in a list of resolutions to limit itself to.  Mostly busy work there, so hopefully can get all that back in then it'll be good or better than the perl version and it can be dropped.

So try this one, has a windows binary again included, and see what you can find.

Also I noticed a 1 line difference in some of the vertical values, the front porch and syncpulse I think, which I'm guessing might be good or bad since the in perl it might have been doing the rounding or other math wrong.  Interesting at least, since I suspected Perl might not have handled all the rounding right for stuff like that, but interested if you see the same thing there and can tell which one is doing it correctly.

[Calamity]

Hi bitbytebit,

For some reason I'm having trouble when passing parameters to this new version, with width heigh refresh it's working ok but can't pass a rom name to it, or monitor model, even if in Mame folder.

By the way, the included dlls are only for using libxml2 or needed for something else?

[bitbytebit]

Hi bitbytebit,

For some reason I'm having trouble when passing parameters to this new version, with width heigh refresh it's working ok but can't pass a rom name to it, or monitor model, even if in Mame folder.

By the way, the included dlls are only for using libxml2 or needed for something else?

Are you using --montor with two dashes, thats one thing that has changed.  The args need two dashes except -v now.

[bitbytebit]

Hi bitbytebit,

For some reason I'm having trouble when passing parameters to this new version, with width heigh refresh it's working ok but can't pass a rom name to it, or monitor model, even if in Mame folder.

By the way, the included dlls are only for using libxml2 or needed for something else?

Are you using --montor with two dashes, thats one thing that has changed.  The args need two dashes except -v
now.

Also the xml library/dll is needed for it now, it's linked to it for the mame output.  Im not sure bit in windows right now you might need to have cygwin and be in a shell.  I thonk the way I run mame may be unix specific currently, need to look at that I guess.

[Calamity]

This is what it's prompting:

Code: [Select]

C:\Emuladores\Mame v0.131>switchres 1942
cygwin warning:
  MS-DOS style path detected: c:\etc\switchres.conf
  Preferred POSIX equivalent is: /cygdrive/c/etc/switchres.conf
  CYGWIN environment variable option "nodosfilewarning" turns off this warning.
  Consult the user's guide for more details about POSIX paths:
    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Unknown ROM for mame and mess 1942
SwitchRes version v1.00 r30 [447aae4] by Chris Kennedy (C) 2010
Ported from code by Calamity to calculate modelines.

Build Date:   Sun Nov 21 12:23:02 CST 2010
Compiler:     GCC 4.3.4 20090804 (release) 1
Build System: i686 unknown unknown Cygwin

Usage: switchres <gamerom>
Usage: switchres <width> <height> <refresh>
Usage: switchres --calc <gamerom>

  --calc                  Calculate modeline and exit
  --mon  <type>           Type of monitor [cga ega vga multi ntsc pal h9110 d920
0 d9800]
  --ymin <height>         Minimum height to use
  --nodoublescan          Video card can't doublescan
  --nointerlace           Video card can't interlace
  --novsync               Weight for x/y instead of vertical refresh

Could not find height width or refresh rate to use.

C:\Emuladores\Mame v0.131>
I've also tried with Cygwin, although I have no experience with this, it prompts:
bash: switchres.exe: command not found

[bitbytebit]

In cygwin you may need to type ./switchres.exe since it's not in the PATH in linux the cwd is not usually on the path. 

Ill look closer when I get home, path for the config may ony work of in your home directoy in cygwin too for now.  I did get the custom monitor config option working again, looks like I'll need to do some testing in windows later to run mame right.  In cygwin you'll need a mame.exe in /usr/local/bin/ too.

[Calamity]

It does work now in Cygwin with ./switchres.exe and mame.exe in /usr/local/bin.

[bitbytebit]

It does work now in Cygwin with ./switchres.exe and mame.exe in /usr/local/bin.

There's some weird thing where I guess that popen doesn't work in cygwin programs when executed on the normal Windows cmd shell.  It's strange, and looks like one of those oddities that maybe in Windows I'll just have to redirect output to a file and read that into the XML stuff.  Seems silly just to get the output of a program, was wanting to avoid that but I guess at least in Linux it'll not have to.  Did you compile switchres before with a Windows native compiler, if so what did you use and how did you do it?   

I did update the Perl version and it should have the same fix for the obeying of the vertical resolution too.

[Calamity]

There's some weird thing where I guess that popen doesn't work in cygwin programs when executed on the normal Windows cmd shell.  It's strange, and looks like one of those oddities that maybe in Windows I'll just have to redirect output to a file and read that into the XML stuff.  Seems silly just to get the output of a program, was wanting to avoid that but I guess at least in Linux it'll not have to.  Did you compile switchres before with a Windows native compiler, if so what did you use and how did you do it?   

I did update the Perl version and it should have the same fix for the obeying of the vertical resolution too.

I don't know if it's the same problem, but when I tried to get Mame xml from inside my code I wasn't able to just redirect output when invoking Mame exec, I had to make a batch to do it (embarrassing) like this:

@echo off
if exist %1 %1 -listxml > Mame.xml

... and then read that file, otherwise it would never get it.

Before libxml2 was included, I managed to compile Switchres easily with MinGW, the same compiler I use for Mame, just ripping the build line from your makefile. I've tried to compile new versions with libxml2 by trying to get the actual build line following the logic of your Makefile, but it always complains about not finding -lxml2 (I've dowloaded libxml2 but it's obvious I didn't install it properly).

[Calamity]

VeS is trying the new distribution, he is finding similar issues as before using patched kernel and stuff, here is the result of his testing:

1.- With AVGA 9250, it loads everything until it reaches drm, when it gets there the picture disappears and does not go on loading X.

2.- With ATI Radeon 9250, just the same.

3.- With AVGA (set up to load a game with switchres -mon h9110 automatically when loading x without advmenu) the game does not get loaded using arcade monitor. But if we plug a PC monitor, it says it's out of range but when the game is loaded it shows on the screen.

4.- With ATI Radeon 9250, just the same.

5.- With AVGA, if set with a normal monitor, we have a normal picture, but if we try to load x, it does not work.

Could it be a not recognizing monitor's EDID issue?

[bitbytebit]

There's some weird thing where I guess that popen doesn't work in cygwin programs when executed on the normal Windows cmd shell.  It's strange, and looks like one of those oddities that maybe in Windows I'll just have to redirect output to a file and read that into the XML stuff.  Seems silly just to get the output of a program, was wanting to avoid that but I guess at least in Linux it'll not have to.  Did you compile switchres before with a Windows native compiler, if so what did you use and how did you do it?   

I did update the Perl version and it should have the same fix for the obeying of the vertical resolution too.

I don't know if it's the same problem, but when I tried to get Mame xml from inside my code I wasn't able to just redirect output when invoking Mame exec, I had to make a batch to do it (embarrassing) like this:

@echo off
if exist %1 %1 -listxml > Mame.xml

... and then read that file, otherwise it would never get it.

Before libxml2 was included, I managed to compile Switchres easily with MinGW, the same compiler I use for Mame, just ripping the build line from your makefile. I've tried to compile new versions with libxml2 by trying to get the actual build line following the logic of your Makefile, but it always complains about not finding -lxml2 (I've dowloaded libxml2 but it's obvious I didn't install it properly).

I figured it out for the xml information, I had to fork and exec mame, use freopen for stdout to a file, then read that file into libxml2.  Sort of nasty but basically using disk instead of memory to hold that small amount of XML for a game.  I guess all the calls through cygwin to easier to use and popen type execution of programs expect to use /bin/bash the unix command line interpreter.  So it has to be done I guess at a lower level, just glad it now should work since was definitely a strange mystery.  

If using minGW I suspect I'll need to have another -D define in the makefile or use -D__WIN32__ basically now, since it uses that (gotten from the Unix uname command and checks for the Cygwin OS to set that).  Figuring out the libxml2 issue should hopefully make all that work I would guess, although probably now the executable I'm building in cygwin should work fine, it runs on the dos command line for me now.  

I did find this libxml2 version but not sure if it works...

http://www.zlatkovic.com/libxml.en.html

Seems to have a tree of multiple packages you need to download to compile it.  I might start trying to use mingw, if all that works may be better than Cygwin I suspect since it won't need the whole cygwin.dll stuff.

I'll have a new version with the windows compile soon that works on dos command lines hopefully soon, the windows computer is busy right now, I need to get one setup dedicated to compiling stuff I guess eventually.

[bitbytebit]

VeS is trying the new distribution, he is finding similar issues as before using patched kernel and stuff, here is the result of his testing:

1.- With AVGA 9250, it loads everything until it reaches drm, when it gets there the picture disappears and does not go on loading X.

2.- With ATI Radeon 9250, just the same.

3.- With AVGA (set up to load a game with switchres -mon h9110 automatically when loading x without advmenu) the game does not get loaded using arcade monitor. But if we plug a PC monitor, it says it's out of range but when the game is loaded it shows on the screen.

4.- With ATI Radeon 9250, just the same.

5.- With AVGA, if set with a normal monitor, we have a normal picture, but if we try to load x, it does not work.

Could it be a not recognizing monitor's EDID issue?

Is the video=640x480c argument in grub.cfg?  That sounds like it may not be, which is necessary to allow it to kick into arcade mode. 

Also besides that, which will work for normal Radeon cards, the other issue is the ArcadeVGA cards do not work with the Linux DRM code and Radeon KMS kernel modules.  Since they have a 'custom' bios and the ATI kernel developers don't know about how it works, they seem to not have supported them.  The screen will be all blurry when they do load, but it requires an extra patch and isn't worth it because it's useless and probably bad for the monitor anyways.  A work around of course would be to flash the BIOS of an AVGA with the normal one, but don't expect that to be a great option for people.  I have been wanting to do something, try to get the kernel developers to fix it, but I suspect they won't care much about getting the card to work since it's closed proprietary on what exactly is done in the BIOS different.  I also suspect the Arcade VGA Andy guy may not really want the information out anyways  and for it to work in Linux, since it's aimed at Windows users. 

So make sure the grub.cfg has that command line in it, like this...
menuentry 'Gentoo Linux 2.6.34-r1 x86_64' --class gentoo --class gnu-linux --class gnu --class os {
        recordfail
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        search --no-floppy --fs-uuid --set 9024ef37-9e8b-4502-a2a0-54a883fdd45e
        linux   /kernel-genkernel-x86_64-2.6.34-gentoo-r1_Digit root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sdc3 video=640x480c
        initrd  /initramfs-genkernel-x86_64-2.6.34-gentoo-r1_Digit
}

With the other kernel of course, but it needs to be on that line with 'linux /kernel.....'

The 'c' character in it tells it to use arcade mode.

[bitbytebit]

VeS is trying the new distribution, he is finding similar issues as before using patched kernel and stuff, here is the result of his testing:

1.- With AVGA 9250, it loads everything until it reaches drm, when it gets there the picture disappears and does not go on loading X.

2.- With ATI Radeon 9250, just the same.

3.- With AVGA (set up to load a game with switchres -mon h9110 automatically when loading x without advmenu) the game does not get loaded using arcade monitor. But if we plug a PC monitor, it says it's out of range but when the game is loaded it shows on the screen.

4.- With ATI Radeon 9250, just the same.

5.- With AVGA, if set with a normal monitor, we have a normal picture, but if we try to load x, it does not work.

Could it be a not recognizing monitor's EDID issue?

This is what I use on mine, it also takes the output name (which somewhat is guessable, can be VGA or DVI, but it's not always so easy till checking the logs to know what to peg as the arcade monitor one). 

video=DVI-I-1:640x480c

So that allows the other output to not do arcade resolutions, so normal monitors will work on the other outputs.

[Calamity]

Also besides that, which will work for normal Radeon cards, the other issue is the ArcadeVGA cards do not work with the Linux DRM code and Radeon KMS kernel modules.  Since they have a 'custom' bios and the ATI kernel developers don't know about how it works, they seem to not have supported them.  The screen will be all blurry when they do load, but it requires an extra patch and isn't worth it because it's useless and probably bad for the monitor anyways.  A work around of course would be to flash the BIOS of an AVGA with the normal one, but don't expect that to be a great option for people.  I have been wanting to do something, try to get the kernel developers to fix it, but I suspect they won't care much about getting the card to work since it's closed proprietary on what exactly is done in the BIOS different.  I also suspect the Arcade VGA Andy guy may not really want the information out anyways  and for it to work in Linux, since it's aimed at Windows users.  

Wouldn't be enough to change or ignore '761295520' string check (or better adding a check for '628573322') in Radeon drivers? I believe old AVGA Bios is not so different after all, just regular bios with some intelligent patches on it.

I'll check the other stuff with VeS, btw.

[bitbytebit]

Also besides that, which will work for normal Radeon cards, the other issue is the ArcadeVGA cards do not work with the Linux DRM code and Radeon KMS kernel modules.  Since they have a 'custom' bios and the ATI kernel developers don't know about how it works, they seem to not have supported them.  The screen will be all blurry when they do load, but it requires an extra patch and isn't worth it because it's useless and probably bad for the monitor anyways.  A work around of course would be to flash the BIOS of an AVGA with the normal one, but don't expect that to be a great option for people.  I have been wanting to do something, try to get the kernel developers to fix it, but I suspect they won't care much about getting the card to work since it's closed proprietary on what exactly is done in the BIOS different.  I also suspect the Arcade VGA Andy guy may not really want the information out anyways  and for it to work in Linux, since it's aimed at Windows users.  

Wouldn't be enough to change or ignore '761295520' string check (or better adding a check for '628573322') in Radeon drivers? I believe old AVGA Bios is not so different after all, just regular bios with some intelligent patches on it.

I'll check the other stuff with VeS, btw.

Yeah I tried to ignore it/add it.  Had a patch for it, but the thing was it booted up all blurry when ignoring that string. 

This is what I did to allow it to actually not have a small kernel oops because once it doesn't see the ATI bios signature, it returns NULL and doesn't check and tries to access things that aren't there.  This adds a check for that and recognizes the different ATI bios signature.  Would be interesting to see if it works on the older cards, at least the AVGA3000 did not do well at all and only that default 640x480 would show and yet it was way off on the Vertical Refresh too so I suspect the card was being programmed by the kernel all wrong.

Code: [Select]

diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index 8e421f6..e7bce7e 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -1250,7 +1250,10 @@ struct atom_context *atom_parse(struct card_info *card, void *bios)
        }
        if (strncmp
            (CSTR(ATOM_ATI_MAGIC_PTR), ATOM_ATI_MAGIC,
-            strlen(ATOM_ATI_MAGIC))) {
+            strlen(ATOM_ATI_MAGIC)) &&
+             strncmp
+               (CSTR(ATOM_ATI_MAGIC_PTR), ATOM_AVGA_MAGIC,
+                strlen(ATOM_AVGA_MAGIC))) {
                printk(KERN_INFO "Invalid ATI magic.\n");
                kfree(ctx);
                return NULL;
diff --git a/drivers/gpu/drm/radeon/atom.h b/drivers/gpu/drm/radeon/atom.h
index a589a55..8adce5c 100644
--- a/drivers/gpu/drm/radeon/atom.h
+++ b/drivers/gpu/drm/radeon/atom.h
@@ -31,6 +31,7 @@
 #define ATOM_BIOS_MAGIC                0xAA55
 #define ATOM_ATI_MAGIC_PTR     0x30
 #define ATOM_ATI_MAGIC         " 761295520"
+#define ATOM_AVGA_MAGIC                " 618573322"
 #define ATOM_ROM_TABLE_PTR     0x48
 
 #define ATOM_ROM_MAGIC         "ATOM"
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
index 8adfedf..6e12bb4 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -530,6 +530,8 @@ int radeon_atombios_init(struct radeon_device *rdev)
        atom_card_info->pll_write = cail_pll_write;
 
        rdev->mode_info.atom_context = atom_parse(atom_card_info, rdev->bios);
+       if (!rdev->mode_info.atom_context)
+               return -ENOMEM;
        mutex_init(&rdev->mode_info.atom_context->mutex);
        radeon_atom_initialize_bios_scratch_regs(rdev->ddev);
        atom_allocate_fb_scratch(rdev->mode_info.atom_context);



[Calamity]

Yeah I tried to ignore it/add it.  Had a patch for it, but the thing was it booted up all blurry when ignoring that string. 

This is what I did to allow it to actually not have a small kernel oops because once it doesn't see the ATI bios signature, it returns NULL and doesn't check and tries to access things that aren't there.  This adds a check for that and recognizes the different ATI bios signature.  Would be interesting to see if it works on the older cards, at least the AVGA3000 did not do well at all and only that default 640x480 would show and yet it was way off on the Vertical Refresh too so I suspect the card was being programmed by the kernel all wrong.

That might work with older AVGAs, I'll tell VeS to use it.

[ves]

Hi, tonight makes better evidence, however let you know that if you post without the xorg.conf and the pc monitor recognizes the edid and I load the game on the pc monitor letting it look good, then change the cable to arcade monitor and looks but out of sync, so I think that 1 error may come from the EDID of the card.

After I realized that changing the grub video=640x480c I put video=640x480@60ie load the console and I can see as I write, but out of sync.
I have also tried to put grub in the video = VGA-0 / 1: o video = DVI-0 / 1, but the same happens (though I have to try better.)

Here the settings I put mine.

Grub video = 640x480c

/etc/modprobe.d/radeon.conf

kernel arcade 2.6.37-rc1 (could be that it compiled this?)

Xorg.conf

Code: [Select]

Section "ServerLayout"
        Identifier     "Arcade Cabinet"
        Screen      0  "Screen0" 0 0
        Screen      1  "Screen1" RightOf "Screen0"
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
        Option          "BlankTime"     "0"
        Option          "StandbyTime"   "0"
        Option          "SuspendTime"   "0"
        Option          "OffTime"       "0"
        Option          "NoPM"          "True"
EndSection

Section "ServerFlags"
Option "DefaultServerLayout" "Arcade Cabinet"
        Option "AllowMouseOpenFail" "true"
Option "DontZap" "off"
Option    "DontZoom" "on"
        Option      "AIGLX" "on"
EndSection

Section "Extensions"
        Option      "Composite" "Enable"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "auto"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5 6 7"
EndSection

# This is an arcade monitor
Section "Monitor"
        Identifier   "DVI-0"
        VendorName   "Wells Gardner"
        ModelName    "D9800"

Option "DPMS" "false"

        #HorizSync       15.25-40.00
        #VertRefresh     40.00-85.00
HorizSync   14 - 16
VertRefresh 50 - 60
Option          "Primary"       "True"

Option "DefaultModes" "False"
UseModes "ArcadeModes"
EndSection

# This is a flat panel computer monitor
Section "Monitor"
        Identifier   "VGA-0"
        VendorName   "Lilo"
        ModelName    "Lilo"

Option "DPMS" "true"
EndSection

Section "Device"
        Identifier  "Card0"
        Driver      "radeon"
        VendorName  "ATI Technologies Inc"
        BoardName   "Unknown Board"
        BusID       "PCI:1:0:0"

#Option     "EXAVSync"       "yes"
Option     "EnablePageFlip" "on"

Option     "ModeDebug"      "true"

Option      "ForceMinDotClock"    "3"

Option     "monitor-DVI-0" "DVI-0"
EndSection

Section "Device"
        Identifier  "Card1"
        Driver      "ati"
        VendorName  "ATI Technologies Inc"
        BoardName   "Unknown Board"
        BusID       "PCI:16:0:0"

Option     "EnablePageFlip" "on"

Option     "ModeDebug"      "true"

Option      "monitor-VGA-0" "VGA-0"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "DVI-0"
        DefaultDepth    24
        SubSection "Display"
                Viewport   0 0
                Depth     8
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     16
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection

Section "Screen"
        Identifier "Screen1"
        Device     "Card1"
        Monitor    "VGA-0"
        DefaultDepth    24
        SubSection "Display"
                Viewport   0 0
                Depth     8
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     16
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection

Section "Modes"
Identifier "ArcadeModes"
#  641x480@60.00 31.500Khz
#Modeline "641x480" 25.200000 641 656 752 800 480 491 493 525 -HSync -VSync
        #Modeline "640x480@60.1Hz 15.6KHz (60Hz)" 12.990 640 664 728 832 480 482 487 521 interlace -hsync -vsync
        Modeline "641x480@60.1Hz 15.6KHz (60Hz)" 12.990 640 664 728 832 480 482 487 521 interlace -hsync -vsync

EndSection



The latest patch for the kernel, which version do you use? has given me errors when applied.

patch-p1 <avga.diff
patching file drivers/gpu/drm/radeon/atom.c
Hunk #1 FAILED at 1250.
1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/radeon/atom.c.rej
patching file drivers/gpu/drm/radeon/atom.h
Hunk #1 FAILED at 31.
1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/radeon/atom.h.rej
patching file drivers/gpu/drm/radeon/radeon_device.c
Hunk #1 FAILED at 530.
1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/radeon/radeon_device.c.rej


That you use your card for your arcade monitor? the new avga3000 would be more advisable?




Greetings.

[Calamity]

Hi VeS,

That you use your card for your arcade monitor? the new avga3000 would be more advisable?

He says that patch didn't work with AVGA3000, but maybe (hopefully) we can make it work with our AVGA9250.