Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up --- Bug Reports --- Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Switchres: modeline generator engine  (Read 152150 times)

0 Members and 1 Guest are viewing this topic.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .21)
« Reply #160 on: November 13, 2010, 07:22:31 pm »
I've attached some graphics made with our monitor's data that may help to visualize this stuff. I like your idea of weighting the amount of vertical padding. Hopefully tomorrow I'll have some time to look at your code.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .21)
« Reply #161 on: November 14, 2010, 03:23:21 am »
I've attached some graphics made with our monitor's data that may help to visualize this stuff. I like your idea of weighting the amount of vertical padding. Hopefully tomorrow I'll have some time to look at your code.

Great, wow that's a lot of information, I really like the range of vertical refresh rates and horizontal frequencies pages.  

I just basically pushed all the information about the game, height width modeline etc, into a single hash structure to help consolidate it and work with it.  I'm planning on doing the same thing to the modeline itself and store extra data like the result codes and make it hang off the game structure when attached/chosen as the best, and have individual ones before that.  This will allow comparing any of the parameters of a modeline quickly without splitting it apart to do calculations or checking height width, or comparing the weights and result info (and can actually store the results per modeline easier that way.  Seems like the thing to do for being able to really check all modelines for different things, and will make things a lot more logical and compact, easier to see what the code is doing and know exactly what variables do and where they come from (since all basically a single structure that relate to each other).

I also added a maximum height and width per monitor type, at least for now since that helps pick the best max for a vector game and keep things a bit sane and limit things like the minimum ones do from going out of possible ranges per monitor type.  Of course sounds like per mode range there will eventually be something and might even replace these.

And lrmc is completely removed, since it seems we don't need it really now and might as well go forward without the extra confusing stuff/code (and the newer structure changes and some other things it actually would require a lot of hacks to work with lrmc, might as well drop it now).
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .22a)
« Reply #162 on: November 14, 2010, 03:40:26 pm »
I've added doublescan support to my initial code (though I can't test it in Windows). You were right, the only change needed is to set 'interlace' to 0.5, and it seems to work. Also now the vertical porches and sync are calculated properly, to work for different monitors. I've added a condition at the beginning to decide if we doublescan or not, and I like it as it gives some kind of simetry to the lower and upper limits managing.

Code: [Select]
FUNCTION ModelineCreate ( BYVAL xres AS LONG, BYVAL yres AS LONG, BYVAL vfreq AS SINGLE, BYVAL rotation AS LONG, index AS LONG ) AS LONG

  LOCAL i, j, result, DotClockIdx AS LONG
  LOCAL hhh, hhi, hhf, hht, newHhh, newHhi, newHhf, newHht, vvv, vvi, vvf, vvt, vIncr, vfreqLabel AS LONG
  LOCAL hfreq, interlace, Dotclock, DotclockReq, vvtIni, VBlankLines, margen, diff, newDiff, newVfreq, hfreqReal, vfreqReal AS SINGLE

  INCR interlace

  IF xres < XresMin THEN xres = XresMin : result = result OR %SimilarRes
  IF yres < YresMin THEN
    IF yres > ActiveLinesLimit / 2 THEN
     ResVirtualize ( xres, yres, vfreq, hfreq )
     interlace = 2
     result = result OR %VirtualizedRes
    ELSE
     interlace = 0.5
     result = result OR %DoubleScan
    END IF
  END IF

  IF rotation = 1 THEN VerticalToHorizontal ( xres, yres )

  IF vfreq < VfreqMin THEN
    IF vfreq * 2 <= VfreqMax THEN
      vfreq = vfreq * 2
      result = result OR %DoubleVfreq
    ELSE
      vfreq = VfreqMin
    END IF
  ELSEIF vfreq > VfreqMax THEN
     vfreq = VfreqMax
  END IF

  IF yres > ActiveLinesLimit AND Rotation = 0 THEN
    interlace = 2
    result = result OR %InterlacedRes
    IF yres < VirtualLinesLimit THEN ResVirtualize ( xres, yres, vfreq, hfreq ) : result = result OR %VirtualizedRes
  END IF

  hfreq = vfreq * yres / ( interlace * ( 1 - vfreq * VerticalBlank ) )

  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

  vvtIni = ROUND ( hfreq / vfreq, 0 ) + IIF ( interlace = 2, 0.5, 0 )
  WHILE vfreq * vvtIni < HfreqMin - HfreqTolerance
    INCR vvtIni
  WEND

  FOR i = 0 TO Iterations
    hfreq = vfreq * ( vvtIni + i )
    IF hfreq <= HfreqMax + HfreqTolerance THEN
      ModelineGetLineParams ( hfreq, xres, newHhh, newHhi, newHhf, newHht )
      DotClockReq = hfreq * newHht
      ARRAY SCAN DotClockTable(), >= DotClockReq, TO j
      IF ABS ( DotClockTable( j - 1 ) - DotClockReq ) < ABS ( DotclockTable( j ) - DotClockReq ) THEN DECR j
      newVfreq = DotClockTable ( j ) / ( ( vvtIni + i ) * newHht )
      newDiff = ABS ( newVfreq - vfreq )
      IF newDiff < Diff OR Diff = 0 THEN
        hhh = newHhh : hhi = newHhi : hhf = NewHhf : hht = NewHht
        Diff = newDiff
        vIncr = i
        DotClockIdx = j
      END IF
    END IF
  NEXT

  VBlankLines = INT ( hfreq * VerticalBlank ) + IIF ( interlace = 2, 0.5, 0 )
  vvv = yres
  vvt = ( vvtIni + vIncr ) * interlace
  margen = ( vvt - vvv - VBlankLines * interlace ) / 2
  vvi = vvv + ROUND ( hfreq * VFrontPorch * interlace + margen, 0 )
  vvf = vvi + ROUND ( hfreq * VSyncPulse * interlace, 0 )

  DotClock = DotClockIdx * 10
  hfreqReal = DotClockTable ( DotClockIdx ) / hht
  vfreqReal = hfreqReal / vvt * interlace
  vfreqLabel = ROUND ( vfreqReal, 0 )

  MODE(index).x = hhh
  MODE(index).y = vvv
  MODE(index).vfreq = vfreqReal

  MODE(index).Xlabel = hhh
  MODE(index).Ylabel = vvv
  MODE(index).Vlabel = vfreqLabel

  Mdln(index).dotclockReal = DotClockTable ( DotClockIdx )
  Mdln(index).dotclock = DotClock
  Mdln(index).hhh = hhh
  Mdln(index).hhi = hhi
  Mdln(index).hhf = hhf
  Mdln(index).hht = hht
  Mdln(index).vvv = vvv
  Mdln(index).vvi = vvi
  Mdln(index).vvf = vvf
  Mdln(index).vvt = vvt
  Mdln(index).interlace = interlace

  FUNCTION = result

END FUNCTION

EDIT: I've set 'margen' as single to allow better accuracy before final rounding.
In order to get the exact same modelines for H9100 I was producing before I have to set the following:

   VFrontPorch = 64
   VSyncPulse = 160
   VBackPorch = 1056

That way I have 2.5 lines for sync so when we interlace it becomes 5 lines. When I set your monitor data it seems to produce similar modelines to yours, except for the vertical front porch that tends to be 1 line bigger, I believe it's due to different rounding.

« Last Edit: November 14, 2010, 05:04:06 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .22a)
« Reply #163 on: November 15, 2010, 12:32:55 am »
I've added doublescan support to my initial code (though I can't test it in Windows). You were right, the only change needed is to set 'interlace' to 0.5, and it seems to work. Also now the vertical porches and sync are calculated properly, to work for different monitors. I've added a condition at the beginning to decide if we doublescan or not, and I like it as it gives some kind of simetry to the lower and upper limits managing.

Code: [Select]
FUNCTION ModelineCreate ( BYVAL xres AS LONG, BYVAL yres AS LONG, BYVAL vfreq AS SINGLE, BYVAL rotation AS LONG, index AS LONG ) AS LONG

  LOCAL i, j, result, DotClockIdx AS LONG
  LOCAL hhh, hhi, hhf, hht, newHhh, newHhi, newHhf, newHht, vvv, vvi, vvf, vvt, vIncr, vfreqLabel AS LONG
  LOCAL hfreq, interlace, Dotclock, DotclockReq, vvtIni, VBlankLines, margen, diff, newDiff, newVfreq, hfreqReal, vfreqReal AS SINGLE

  INCR interlace

  IF xres < XresMin THEN xres = XresMin : result = result OR %SimilarRes
  IF yres < YresMin THEN
    IF yres > ActiveLinesLimit / 2 THEN
     ResVirtualize ( xres, yres, vfreq, hfreq )
     interlace = 2
     result = result OR %VirtualizedRes
    ELSE
     interlace = 0.5
     result = result OR %DoubleScan
    END IF
  END IF

  IF rotation = 1 THEN VerticalToHorizontal ( xres, yres )

  IF vfreq < VfreqMin THEN
    IF vfreq * 2 <= VfreqMax THEN
      vfreq = vfreq * 2
      result = result OR %DoubleVfreq
    ELSE
      vfreq = VfreqMin
    END IF
  ELSEIF vfreq > VfreqMax THEN
     vfreq = VfreqMax
  END IF

  IF yres > ActiveLinesLimit AND Rotation = 0 THEN
    interlace = 2
    result = result OR %InterlacedRes
    IF yres < VirtualLinesLimit THEN ResVirtualize ( xres, yres, vfreq, hfreq ) : result = result OR %VirtualizedRes
  END IF

  hfreq = vfreq * yres / ( interlace * ( 1 - vfreq * VerticalBlank ) )

  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

  vvtIni = ROUND ( hfreq / vfreq, 0 ) + IIF ( interlace = 2, 0.5, 0 )
  WHILE vfreq * vvtIni < HfreqMin - HfreqTolerance
    INCR vvtIni
  WEND

  FOR i = 0 TO Iterations
    hfreq = vfreq * ( vvtIni + i )
    IF hfreq <= HfreqMax + HfreqTolerance THEN
      ModelineGetLineParams ( hfreq, xres, newHhh, newHhi, newHhf, newHht )
      DotClockReq = hfreq * newHht
      ARRAY SCAN DotClockTable(), >= DotClockReq, TO j
      IF ABS ( DotClockTable( j - 1 ) - DotClockReq ) < ABS ( DotclockTable( j ) - DotClockReq ) THEN DECR j
      newVfreq = DotClockTable ( j ) / ( ( vvtIni + i ) * newHht )
      newDiff = ABS ( newVfreq - vfreq )
      IF newDiff < Diff OR Diff = 0 THEN
        hhh = newHhh : hhi = newHhi : hhf = NewHhf : hht = NewHht
        Diff = newDiff
        vIncr = i
        DotClockIdx = j
      END IF
    END IF
  NEXT

  VBlankLines = INT ( hfreq * VerticalBlank ) + IIF ( interlace = 2, 0.5, 0 )
  vvv = yres
  vvt = ( vvtIni + vIncr ) * interlace
  margen = ( vvt - vvv - VBlankLines * interlace ) / 2
  vvi = vvv + ROUND ( hfreq * VFrontPorch * interlace + margen, 0 )
  vvf = vvi + ROUND ( hfreq * VSyncPulse * interlace, 0 )

  DotClock = DotClockIdx * 10
  hfreqReal = DotClockTable ( DotClockIdx ) / hht
  vfreqReal = hfreqReal / vvt * interlace
  vfreqLabel = ROUND ( vfreqReal, 0 )

  MODE(index).x = hhh
  MODE(index).y = vvv
  MODE(index).vfreq = vfreqReal

  MODE(index).Xlabel = hhh
  MODE(index).Ylabel = vvv
  MODE(index).Vlabel = vfreqLabel

  Mdln(index).dotclockReal = DotClockTable ( DotClockIdx )
  Mdln(index).dotclock = DotClock
  Mdln(index).hhh = hhh
  Mdln(index).hhi = hhi
  Mdln(index).hhf = hhf
  Mdln(index).hht = hht
  Mdln(index).vvv = vvv
  Mdln(index).vvi = vvi
  Mdln(index).vvf = vvf
  Mdln(index).vvt = vvt
  Mdln(index).interlace = interlace

  FUNCTION = result

END FUNCTION

EDIT: I've set 'margen' as single to allow better accuracy before final rounding.
In order to get the exact same modelines for H9100 I was producing before I have to set the following:

   VFrontPorch = 64
   VSyncPulse = 160
   VBackPorch = 1056

That way I have 2.5 lines for sync so when we interlace it becomes 5 lines. When I set your monitor data it seems to produce similar modelines to yours, except for the vertical front porch that tends to be 1 line bigger, I believe it's due to different rounding.



I've tested this and it works, implemented doublescan now and looks good.  

One odd thing I see in the calculations for this part:

vvi = vvv + ROUND ( hfreq * VFrontPorch * interlace + margen, 0 )
  vvf = vvi + ROUND ( hfreq * VSyncPulse * interlace, 0 )

Is for me those numbers ended up super large, unless I remove hfreq and instead do the (VFrontPorch*1000)/LineTime calculation there instead.  LIke this...


                $vb = $OriginalHeight + int(((($Mode[$ModeBase]{'VFrontPorch'}*1000)/$LineTime) * $interlace + $margen)+0.5);
                $vc = $vb + int(((($Mode[$ModeBase]{'VSyncPulse'}*1000)/$LineTime) * $interlace)+0.5);

That seems to work good, really good actually and better than my previous way of attempting to calculate these with the frontporch and syncpulse values.  So basically is it priming the value of VerticalBlank with the default value you used of 1280/1000000 before, but just to get an HFreq estimate at first?  I'm trying to consolidate this so I don't have the two code paths of how I was calculating with the values, and this new way which works way better.  That extra line you mention that I get is a problem and I actually see it doing bad, it's the thing that with pacman makes it touchy I think.  it's just a line or two touchy and if 1-2 too many lines vertical it'll do things like throw pacman into a wide bad looking display.  So with this new code it seems to use the values for front porch and sync pulse while not doing those extra total lines, and looks like I can just remove what I was trying to do calculating with front/sync/back values everything past active lines.

I think I got it able to turn off/on both doublescan or interlace now too, so can specify not to do them for cards that can't.  Not sure if there's any obstacles there when they aren't done, I tried to follow the logic of doing the previous yres minimum cutoff when we can't doublescan.  


Here's the two relevant diff parts of how it is now with doublescan, the first is the calculations I do with all 3 values fp/sp/bp as before, and second is the one that used the hardwired value before and now is like your code is (except my alteration to remove the hfreq use).
 

Code: [Select]

@@ -1393,15 +1500,15 @@ sub get_modeline($ $ $ @) {
                if ($interlace == 2) {
                        $VBlankLines += 0.5;
                }
-               $margen = ($VT * $interlace) - $OriginalHeight - ($VBlankLines * $interlace);
+               $margen = (($VT * $interlace) - $OriginalHeight - ($VBlankLines * $interlace)) / 2;

                $LineTime = 1.0 / ( $newDC / $newHt ) * 1000000;
                $B = ($Mode[$ModeBase]{'VFrontPorch'}*1000)/$LineTime;
                $C = ($Mode[$ModeBase]{'VSyncPulse'}*1000)/$LineTime;
                $E = ($Mode[$ModeBase]{'VBackPorch'}*1000)/$LineTime;

-               $vb = $OriginalHeight + int(($B+.05)) + (int(($margen / 2)+0.5) + 1 * $interlace);
-               $vc = int($vb+int(($C*$interlace)+0.5));
+               $vb = $OriginalHeight + int(($B + $margen + 1 * $interlace)+0.5);
+               $vc = $vb + int(($C * $interlace)+0.5);
                if ($VERBOSE > 1) {
                        print "$VT total lines $margen line margen = (($VT * $interlace) - $OriginalHeight - ($VBlankLines * $interlace)) " .
                                sprintf("%.4f", $LineTime) . " linetime\n" .
@@ -1414,18 +1521,15 @@ sub get_modeline($ $ $ @) {
                if ($interlace == 2) {
                        $VBlankLines += 0.5;
                }
-               $margen = ($VT * $interlace) - $va - ($VBlankLines * $interlace);
+               $margen = (($VT * $interlace) - $va - ($VBlankLines * $interlace)) / 2;
                if ($VERBOSE > 1) {
-                       print "Using $VBlankLines Vertical blanking lines with $margen line margen = (($VT * $interlace) - $va - ($VBlankLines * $interlace))\n";
+                       print "Using $VBlankLines Vertical blanking lines with $margen line margen = ((($VT * $interlace) - $va - ($VBlankLines * $interlace))/2)\n";
                }

-               $vb = $OriginalHeight + int(($margen / 2)+0.5) + 1 * $interlace;
-               $vc = $vb;
-               if ($interlace == 2) {
-                       $vc += 5;
-               } else {
-                       $vc += 3;
-               }
+               my $LineTime = 1.0 / ( $newDC / $newHt ) * 1000000;
+
+               $vb = $OriginalHeight + int(((($Mode[$ModeBase]{'VFrontPorch'}*1000)/$LineTime) * $interlace + $margen)+0.5);
+               $vc = $vb + int(((($Mode[$ModeBase]{'VSyncPulse'}*1000)/$LineTime) * $interlace)+0.5);
        }

        if ($VERBOSE > 1) {


Here's the output of each code path for suprmrio in the same order:

arcade@arcade ~/src/SwitchRes $ ./switchres -calcgame suprmrio
# suprmrio 256x240@60.00 15.660Khz
     Modeline "256x240" 5.261760 256 272 296 336 240 244 247 261 -HSync -VSync

arcade@arcade ~/src/SwitchRes $ ./switchres -calcgame suprmrio -nousevtime
# suprmrio 256x240@60.00 15.600Khz
     Modeline "256x240" 5.241600 256 272 296 336 240 243 246 260 -HSync -VSync


Update: Also when looking at the start, if I prime VerticalBlank with the real values instead of the old default values of 1280/1000000, it yet alters the second code path with your new code, with those plugged in at first for it  the total vertical lines is more than those two...

arcade@arcade ~/src/SwitchRes $ ./switchres -calcgame suprmrio
# suprmrio 256x240@60.00 15.720Khz
     Modeline "256x240" 5.281920 256 272 296 336 240 243 246 262 -HSync -VSync

Also I am seeing some odd vertical offset issues without this, but fixed using those values which makes sense I think.   The extra few lines though for the pacman 288 line high case may trigger it to misbehave though.  It's odd, basically those few extra lines for it (like 313 instead of 312 total) will make it randomly 1 out of 3 trys go into an extra wide display, but just very random on entering/exiting the game.


Update 2: After looking closer, I'm starting to think what is going on is the need to basically do what you mentioned about possibly interpolating the vertical timing values (and probably horizontal ones too) as we move further from one of the horizontal freq ranges but still not close to the next, when in the middle areas.  Pacman is certainly in that area at around 18.9Khz and it wants fewer lines or a slightly lower value for the total vertical lines, some other games show horizontally possibly similar issues.  I suspect that is what is going on, the d9800 can do the whole range and  we can center everything with those timing values but they might be more of a continous moving value and those fixed points are guides at each normal Khz range.  Does that make sense and do you have an idea of how to do this correctly/the best way?

Update 3: I now see that I need to do (hfreq/1000) and then it calculates out the same.
« Last Edit: November 15, 2010, 02:25:39 am by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
« Reply #164 on: November 15, 2010, 03:50:30 am »
I think I figured out the best way to calculate the vertical lines, and also realized adding an extra range between CGA and EGA modes with a slightly smaller back porch seemed to fix the pacman issue too.  I think I was trying to make that one case work with the coding logic and it was making everything else suffer until I realized it was actually the values for vertical timing on that range needed changing.  Seems the 18-20Khz range is touchy, which is where 288 line high vertical games fall into, and needs less back porch or a few less total lines (312 it likes, 313+ get more and more inconsistent till at 315 every load is way too wide of display for the game).  I think the 312 number makes a lot of sense from seeing how that's the step above the standard 262 total line games, 312, then 416 and then 525, although more figured that all out through trial and error and not really fully understanding what is going on there (maybe the touchy point between monitor pretuned ranges).  I do know the way the manual says it there seems to be the 'fixed' or tuned points in the Horizontal Khz range it has, which can be moved per customer needs, and I'm guessing when we are in the middle of those perhaps it's more sensitive to a few lines less/more and the vertical timing has to be adjusted for that. 

So I uploaded version .22 adding the doublescan and now am doing all the timing calculations one way, removed all the extra duplicated code and think it now should be correct.  I fiddled around with the calculations and saw that I could get what I was doing to match what your newer code does in output numbers and kind of figured out from seeing the differences what was the best method to calculate out the vertical values for the modeline.  It also uses the newer values you gave for the H9100 monitor too.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
« Reply #165 on: November 15, 2010, 08:22:17 am »
I think I figured out the best way to calculate the vertical lines, and also realized adding an extra range between CGA and EGA modes with a slightly smaller back porch seemed to fix the pacman issue too.  I think I was trying to make that one case work with the coding logic and it was making everything else suffer until I realized it was actually the values for vertical timing on that range needed changing.  Seems the 18-20Khz range is touchy, which is where 288 line high vertical games fall into, and needs less back porch or a few less total lines (312 it likes, 313+ get more and more inconsistent till at 315 every load is way too wide of display for the game).  I think the 312 number makes a lot of sense from seeing how that's the step above the standard 262 total line games, 312, then 416 and then 525, although more figured that all out through trial and error and not really fully understanding what is going on there (maybe the touchy point between monitor pretuned ranges).  I do know the way the manual says it there seems to be the 'fixed' or tuned points in the Horizontal Khz range it has, which can be moved per customer needs, and I'm guessing when we are in the middle of those perhaps it's more sensitive to a few lines less/more and the vertical timing has to be adjusted for that. 

So I uploaded version .22 adding the doublescan and now am doing all the timing calculations one way, removed all the extra duplicated code and think it now should be correct.  I fiddled around with the calculations and saw that I could get what I was doing to match what your newer code does in output numbers and kind of figured out from seeing the differences what was the best method to calculate out the vertical values for the modeline.  It also uses the newer values you gave for the H9100 monitor too.

I really expected some of these issues to come up, and hopefully with some testing we'll soon have a clear understanding of what's going on.

That sudden width change when you cross the 312 lines limit makes a lot of sense. However, when this happens, do you mean that your picture gets too wide so it gets chopped on the side borders or it gets too narrow so you have big side margins?

If the former is true, this is without any doubt that you're crossing the limit where the EGA values start to apply. As EGA horizontal active video is just 30,69 Ás compared to CGA's 50,00 Ás, the monitor needs to adjust it's horizontal amplitude wider so that the expected 30,69 Ás signal fills the screen. If your monitor is deciding which mode to switch into on the total vertical lines, and makes the assuption that something above 312 lines is EGA, then it will set the wrong horizontal amplitude. However, we should make sure the decision is done on the total vertical lines and not on hfreq (which is what I assumed it was doing), as these values are related but are not totally equivalent.

In order to keep 288 lines modes into CGA, you might as well try to reduce your documented CGA front porch, that is 3 lines long, and seems too long for me compared to my values. That extra lines will increase as you move to upper hfreqs (adding up to that maximum 27,98 lines in my Excel). Perhaps if you just use 1 line for the front porch you'll still keep below 312 when using 288 active lines, avoiding the need of an extra interval.

This 312 figure also makes sense as 312.5 are the number of lines of each PAL field, so the total is 625 interlaced. Same with NTSC -> 262.5 * 2 = 525 interlaced
These test you're doing are very important as they will tell you the right values your monitor is using to base decisions on, and yes, the only way I'm afraid is trial and error.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
« Reply #166 on: November 15, 2010, 11:06:47 am »
I think I figured out the best way to calculate the vertical lines, and also realized adding an extra range between CGA and EGA modes with a slightly smaller back porch seemed to fix the pacman issue too.  I think I was trying to make that one case work with the coding logic and it was making everything else suffer until I realized it was actually the values for vertical timing on that range needed changing.  Seems the 18-20Khz range is touchy, which is where 288 line high vertical games fall into, and needs less back porch or a few less total lines (312 it likes, 313+ get more and more inconsistent till at 315 every load is way too wide of display for the game).  I think the 312 number makes a lot of sense from seeing how that's the step above the standard 262 total line games, 312, then 416 and then 525, although more figured that all out through trial and error and not really fully understanding what is going on there (maybe the touchy point between monitor pretuned ranges).  I do know the way the manual says it there seems to be the 'fixed' or tuned points in the Horizontal Khz range it has, which can be moved per customer needs, and I'm guessing when we are in the middle of those perhaps it's more sensitive to a few lines less/more and the vertical timing has to be adjusted for that.  

So I uploaded version .22 adding the doublescan and now am doing all the timing calculations one way, removed all the extra duplicated code and think it now should be correct.  I fiddled around with the calculations and saw that I could get what I was doing to match what your newer code does in output numbers and kind of figured out from seeing the differences what was the best method to calculate out the vertical values for the modeline.  It also uses the newer values you gave for the H9100 monitor too.

I really expected some of these issues to come up, and hopefully with some testing we'll soon have a clear understanding of what's going on.

That sudden width change when you cross the 312 lines limit makes a lot of sense. However, when this happens, do you mean that your picture gets too wide so it gets chopped on the side borders or it gets too narrow so you have big side margins?

If the former is true, this is without any doubt that you're crossing the limit where the EGA values start to apply. As EGA horizontal active video is just 30,69 Ás compared to CGA's 50,00 Ás, the monitor needs to adjust it's horizontal amplitude wider so that the expected 30,69 Ás signal fills the screen. If your monitor is deciding which mode to switch into on the total vertical lines, and makes the assuption that something above 312 lines is EGA, then it will set the wrong horizontal amplitude. However, we should make sure the decision is done on the total vertical lines and not on hfreq (which is what I assumed it was doing), as these values are related but are not totally equivalent.

In order to keep 288 lines modes into CGA, you might as well try to reduce your documented CGA front porch, that is 3 lines long, and seems too long for me compared to my values. That extra lines will increase as you move to upper hfreqs (adding up to that maximum 27,98 lines in my Excel). Perhaps if you just use 1 line for the front porch you'll still keep below 312 when using 288 active lines, avoiding the need of an extra interval.

This 312 figure also makes sense as 312.5 are the number of lines of each PAL field, so the total is 625 interlaced. Same with NTSC -> 262.5 * 2 = 525 interlaced
These test you're doing are very important as they will tell you the right values your monitor is using to base decisions on, and yes, the only way I'm afraid is trial and error.


I had thought it might be needing the EGA values too but they don't work well for it either, so it's definitely an in between gray area.  What it does is that pacman, instead of having the proper aspect ratio and proper centering (vertical on a horizontal monitor side borders being wide) it is stretched wide across the screen almost side to side.  I can reload it and it's fine, or reload it and it isn't.  If the lines are greater than 312 it is a random shoot as to what will happen.  

So your saying reduce the front porch instead of the back porch, like this...

                                                                                          
                    fill_mode("15250-18000,40-80,2.187,4.688,6.719,0.190,0.191,1.018,0,0");
>>                fill_mode("18001-20000,40-80,2.187,4.688,6.719,0.080,0.191,1.018,0,0");
                                                                                           ^^^
                    fill_mode("20001-30000,40-80,2.910,3.000,4.440,0.451,0.164,1.048,0,0");
                    fill_mode("30001-32000,40-80,0.636,3.813,1.906,0.318,0.064,1.048,0,0");
                    fill_mode("32001-38900,40-80,1.000,3.200,2.200,0.020,0.106,0.607,1,1");

That seems to kick it back down to 312 lines too, previously I had the 1.018 value at .900 and that also did it, will see to make sure it is consistent this way too.



arcade@arcade ~/src/SwitchRes $ ./switchres -calcgame pacman -v -v -v -v
Running: ./switchres -calcgame pacman -v -v -v -v
Using monitor: d9800
Default Mode: 640x480@60
Display line for pacman is:
  type: raster
  rotate: 90
  width: 288
  height: 224
  refresh: 60.606061
  pixclock: 6144000
  htotal: 384
  hbend: 0
  hbstart: 288
  vtotal: 264
  vbend: 0
  vbstart: 224

Using mame xml: [1] pacman raster vertical 384x288@60.606061 --> 384x288@60.606061 AR 1.285714

*** Horizontal frequency 18.933Khz matches monitor range [1]: 18.001Khz - 20.000Khz
Using 24 Vertical blanking lines with 0 line margen = (((312 * 1) - 288 - (24 * 1))/2)
Using ModeBase: 1 Lines: 312 Pad: (+0) VBlank: 0.001289 Hfreq: 18.909Khz Vref: 60.61Hz

# pacman 384x288@60.61 18.910Khz
     Modeline "384x288" 9.983952 384 408 456 528 288 290 294 312 -HSync -VSync


Update:  When I do the change to the frontporch I  actually am getting it a few lines off center vertically, pushed downwards too much.  Seems the back porch change kept it centered vertically.  

This seems to make it better:

 fill_mode("18001-20000,40-80,2.187,4.688,6.719,0.120,0.121,1.018,0,0");

# pacman 384x288@60.61 18.910Khz
     Modeline "384x288" 9.983952 384 408 456 528 288 291 293 312 -HSync -VSync

Just reducing the front porch and sync pulse both, but less reduction than I did before...

Is there a reason not to reduce the last timing value instead of these two?  I think both changes are essentially looking the same though, but not sure which is the better one.
« Last Edit: November 15, 2010, 11:33:18 am by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
« Reply #167 on: November 15, 2010, 11:38:31 am »
I had thought it might be needing the EGA values too but they don't work well for it either, so it's definitely an in between gray area.  What it does is that pacman, instead of having the proper aspect ratio and proper centering (vertical on a horizontal monitor side borders being wide) it is stretched wide across the screen almost side to side.  I can reload it and it's fine, or reload it and it isn't.  If the lines are greater than 312 it is a random shoot as to what will happen.

But that stretching occurs when you calculate as CGA and lines are above 312 (isn't it?), what happens when you calculate as EGA? 

Update:  When I do the change to the frontporch I actually am getting it a few lines off center vertically, pushed downwards too much.  Seems the back porch change kept it centered vertically. 

So it seems the reported frontporch is correct and necessary, but it was worth to test.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
« Reply #168 on: November 15, 2010, 11:44:57 am »
I had thought it might be needing the EGA values too but they don't work well for it either, so it's definitely an in between gray area.  What it does is that pacman, instead of having the proper aspect ratio and proper centering (vertical on a horizontal monitor side borders being wide) it is stretched wide across the screen almost side to side.  I can reload it and it's fine, or reload it and it isn't.  If the lines are greater than 312 it is a random shoot as to what will happen.

But that stretching occurs when you calculate as CGA and lines are above 312 (isn't it?), what happens when you calculate as EGA? 

Update:  When I do the change to the frontporch I actually am getting it a few lines off center vertically, pushed downwards too much.  Seems the back porch change kept it centered vertically. 

So it seems the reported frontporch is correct and necessary, but it was worth to test.


In EGA mode it stretches even more actually, and shifts off to the left side of the screen.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
« Reply #169 on: November 15, 2010, 11:55:21 am »
Just reducing the front porch and sync pulse both, but less reduction than I did before...

Is there a reason not to reduce the last timing value instead of these two?  I think both changes are essentially looking the same though, but not sure which is the better one.

No, it's ok as long as you are not loosing active lines. It's just that I like having front porch as short as possible to have room for a decent back porch while keeping the vertical blank as low as possible, which allows to get a higher maximum Vfreq for a similar yres, that's how I get those 256 lines@60Hz modes. You'll know your back porch is not enough when you start missing lines at the top of the screen, which usually appear to be closer to each other than normal, and maybe have visible return diagonals near the top, indicating your electron beam has not enough time to go up. You can explore where the limit for each porch is, which should be constant for that interval.

An interesting test would be to have one of those border modelines with 312 total lines, and start increasing its vfreq so that hfreq increases at the same time, to check if it jumps in the stretched mode or not. That would help to determine if the limit is set by the total number of lines or by hfreq.

In EGA mode it stretches even more actually, and shifts off to the left side of the screen.

I can see what you mean, definitely a gray area...
« Last Edit: November 15, 2010, 12:12:30 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
« Reply #170 on: November 15, 2010, 12:15:54 pm »
Just reducing the front porch and sync pulse both, but less reduction than I did before...

Is there a reason not to reduce the last timing value instead of these two?  I think both changes are essentially looking the same though, but not sure which is the better one.

No, it's ok as long as you are not loosing active lines. It's just that I like having front porch as short as possible to have room for a decent back porch while keeping the vertical blank as low as possible, which allows to get a higher maximum Vfreq for a similar yres, that's how I get those 256 lines@60Hz modes. You'll know your back porch is not enough when you start missing lines at the top of the screen, which usually appear to be closer to each other than normal, and maybe have visible return diagonals near the top, indicating your electron beam has not enough time to go up. You can explore where the limit for each porch is, which should be constant for that interval.

An interesting test would be to have one of those border modelines with 312 total lines, and start increasing it's vfreq so that hfreq increases at the same time, to check if it jumps in the stretched mode or not. That would help to determine if the limit is set by the total number of lines or by hfreq.

In EGA mode it stretches even more actually, and shifts off to the left side of the screen.

I can see what you mean, definitely a gray area...


This seems to be an interesting way to reduce the front porch as much as possible (1 line) and then reduce the back porch slightly less that way...


                fill_mode("15250-18000,40-80,2.187,4.688,6.719,0.190,0.191,1.018,0,0");
                fill_mode("18001-20000,40-80,2.187,4.688,6.719,0.140,0.191,0.950,0,0");


With this it looks good too, it has plenty of room at top and actually I'd say a slight space up there and the bottom of the picture touches the edge but within the monitors display area.  It seems stable and looks good like this, but also I'm thinking is better since it leaves the sync pulse alone and just reduces the front porch slightly and back porch a little too.

I think there's very few games that ever would need to be in this area/range, at least get that feeling from only this one game running into this issue.  It's odd because EGA mode settings are going the opposite and increasing these values, so it's almost like an hourglass and the monitor is wanting less lines towards the middle between CGA/EGA and then more again up nearer to EGA mode.  I do think it's probably the number of lines most likely that make it inconsistent and sort of flaky when it has more than 312 and trying to do 288 lines active in a CGA mode type resolution.  It's odd how at 313 lines it's rare, 1 out of 5 times probably it is wrong, at 314 lines maybe 1 out of 3 , and at about 315 lines or more it's just about every time it looks too wide. 
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
« Reply #171 on: November 15, 2010, 04:46:36 pm »
This seems to be an interesting way to reduce the front porch as much as possible (1 line) and then reduce the back porch slightly less that way...


                fill_mode("15250-18000,40-80,2.187,4.688,6.719,0.190,0.191,1.018,0,0");
                fill_mode("18001-20000,40-80,2.187,4.688,6.719,0.140,0.191,0.950,0,0");


With this it looks good too, it has plenty of room at top and actually I'd say a slight space up there and the bottom of the picture touches the edge but within the monitors display area.  It seems stable and looks good like this, but also I'm thinking is better since it leaves the sync pulse alone and just reduces the front porch slightly and back porch a little too.

Sounds good. So will you adopt those values also for lower resolutions or either use a separate interval 18000-20000 for them?

I think there's very few games that ever would need to be in this area/range, at least get that feeling from only this one game running into this issue.  It's odd because EGA mode settings are going the opposite and increasing these values, so it's almost like an hourglass and the monitor is wanting less lines towards the middle between CGA/EGA and then more again up nearer to EGA mode.  I do think it's probably the number of lines most likely that make it inconsistent and sort of flaky when it has more than 312 and trying to do 288 lines active in a CGA mode type resolution.  It's odd how at 313 lines it's rare, 1 out of 5 times probably it is wrong, at 314 lines maybe 1 out of 3 , and at about 315 lines or more it's just about every time it looks too wide. 

Unfortunately I have no knowledge on electronics, so I can't get a clear idea of what's being done with our signals inside the monitor. I thought that the monitor makes its decision of which range to use by looking at signal's hfreq, and most of the logic for checking limits in the modeline function code just assumes that. If the total number of lines turns out to be more critical then perhaps our ranges should be defined by lines instead of hfreqs, at least for this monitor, I have to think about this. It would also help to find out if this mysterious wide mode corresponds to one of the other modes activated by mistake or just the monitor failing to adapt to our timings.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
« Reply #172 on: November 15, 2010, 05:12:54 pm »
This seems to be an interesting way to reduce the front porch as much as possible (1 line) and then reduce the back porch slightly less that way...


                fill_mode("15250-18000,40-80,2.187,4.688,6.719,0.190,0.191,1.018,0,0");
                fill_mode("18001-20000,40-80,2.187,4.688,6.719,0.140,0.191,0.950,0,0");


With this it looks good too, it has plenty of room at top and actually I'd say a slight space up there and the bottom of the picture touches the edge but within the monitors display area.  It seems stable and looks good like this, but also I'm thinking is better since it leaves the sync pulse alone and just reduces the front porch slightly and back porch a little too.

Sounds good. So will you adopt those values also for lower resolutions or either use a separate interval 18000-20000 for them?

I think there's very few games that ever would need to be in this area/range, at least get that feeling from only this one game running into this issue.  It's odd because EGA mode settings are going the opposite and increasing these values, so it's almost like an hourglass and the monitor is wanting less lines towards the middle between CGA/EGA and then more again up nearer to EGA mode.  I do think it's probably the number of lines most likely that make it inconsistent and sort of flaky when it has more than 312 and trying to do 288 lines active in a CGA mode type resolution.  It's odd how at 313 lines it's rare, 1 out of 5 times probably it is wrong, at 314 lines maybe 1 out of 3 , and at about 315 lines or more it's just about every time it looks too wide. 

Unfortunately I have no knowledge on electronics, so I can't get a clear idea of what's being done with our signals inside the monitor. I thought that the monitor makes its decision of which range to use by looking at signal's hfreq, and most of the logic for checking limits in the modeline function code just assumes that. If the total number of lines turns out to be more critical then perhaps our ranges should be defined by lines instead of hfreqs, at least for this monitor, I have to think about this. It would also help to find out if this mysterious wide mode corresponds to one of the other modes activated by mistake or just the monitor failing to adapt to our timings.


Seems like using a separate range for them right now is generally working, will see if it hits any problems.

Here's another interesting thing that might be a clue.  I found an another anomaly/gap in the logic until I figured out what would fix it.  Basically in between VGA and SVGA mode there's a bit of space in the Hfreq where you need to have the calculations for the Horizontal of one but Vertical of the other range.  Also it seems that the EGA mode range needed to be altered slightly in that too.  With these changes, now I am seeing better centering and width correctness for games falling in that area either between VGA/SVGA and also right below VGA...


                # D9800/D9400
                #
                # CGA
                fill_mode("15250-18000,40-80,2.187,4.688,6.719,0.190,0.191,1.018,0,0");
                # CGA->EGA
                fill_mode("18001-20000,40-80,2.187,4.688,6.719,0.140,0.191,0.950,0,0");
                # EGA
                fill_mode("20001-29000,40-80,2.910,3.000,4.440,0.451,0.164,1.048,0,0");
                # VGA
                fill_mode("29001-32000,40-80,0.636,3.813,1.906,0.318,0.064,1.048,0,0");
                # VGA->SVGA
                fill_mode("32001-34000,40-80,0.636,3.813,1.906,0.020,0.106,0.607,0,0");
                # SVGA
                fill_mode("34001-38900,40-80,1.000,3.200,2.200,0.020,0.106,0.607,1,1");


I had too thought about the fact, that at least with a d9800, looking at lines might be more direct of way to approach it.  Although I'm also wondering if this way also basically is following lines in theory unless we really chose a way out of aspect resolution (which seems unlikely) which  pushes horizontal or vertical way off of the opposite one.  Like a 800x224 resolution may need the SVGA timing for width but CGA timing for height, yet that resolution would never really happen or be useful.  From what I can tell so far, these small changes in the ranges I've made are enough to seemingly (for now, unless I find issues) get things to work very well when those in between ranges are needed.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
« Reply #173 on: November 15, 2010, 05:56:47 pm »
It's good it's working with those new ranges, and also those gaps between the other modes are great info.
On the other hand, it seems to me that an analog monitor should not care about xres at all, as long as blanking is well defined. So from the monitor's point of view 320x240 and 640x240 should be indistinguishable, and show the same values on its OSD (Hfreq, Vfreq).

By the way, VeS wrote to me, hopefully he's using your stuff for a test distribution, I'm eager to try this myself.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
« Reply #174 on: November 15, 2010, 06:19:05 pm »
It's good it's working with those new ranges, and also those gaps between the other modes are great info.
On the other hand, it seems to me that an analog monitor should not care about xres at all, as long as blanking is well defined. So from the monitor's point of view 320x240 and 640x240 should be indistinguishable, and show the same values on its OSD (Hfreq, Vfreq).

Ah, maybe that's the issue then, isn't the D9800 actually a digital monitor?  Could that be why it can do the range like it does and possibly how it's using the height/width to figure things out?

By the way, VeS wrote to me, hopefully he's using your stuff for a test distribution, I'm eager to try this myself.

Sounds great, looking forward to that, will be nice to get this stuff easy to use for anybody, mainly the kernel patch and details on xorg.conf config

Also I've just gotten it so it'll override those 'invisible' default modes.  Turns out I can add a modeline of 800x600 with xrandr, I just can't label it such, it must be '800x600xSOMETHING_EXTRA' basically can't be just '800x600'.  Must be some odd bug in X, but doesn't matter because now I'm adding the xREFRESH as a string to each modeline generated for xrandr to use and now we can make those modes too.  Basically the way I'm doing it, to avoid any conflicts with my desktop mode, is I have a single modeline in xorg.conf as 641x480, then everything generated by switchres, even 640x480 modes, won't conflict with my desktop and we can use them even if a different refresh rate is needed.  I check and basically use that default desktop mode already in before launching switchres as a default in case no mode is specified by the game, but also align it to 8 removing the extra 1 pixel.  So a user with a generated desktop resolution of 641x480 or 801x600 doesn't have any worries about conflicting issues, switchres should take care of all the details.  I was always adding 8 pixels onto the horizontal width before this change, which now the focus is on the game being perfect and letting the desktop have 1 funny pixel extra.  Also if a person does use 640x480 on the desktop then it'll revert back to adding 8 pixels to the width to make up for it.  In all the calculations it always aligns it to 8 and I could try to force a single pixel there in those cases but seems unclean compared to just expecting the user to do that themselves for the desktop resolution.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .24)
« Reply #175 on: November 16, 2010, 04:54:31 pm »
Ah, maybe that's the issue then, isn't the D9800 actually a digital monitor?  Could that be why it can do the range like it does and possibly how it's using the height/width to figure things out?

I'm almost sure that being digital must affect the results in some way, however your monitor seems to have an incredible range of tolerance. There's something I've been wondering, is if your monitor has some kind of autoadjust mechanism, so that when you set a resolution, it tries to autocenter, as pc monitors do. I suppose it's something necessary for multisync monitors, although I don't really have a proper understanding of what's going on from an electronic point of view. About height/width managing, I'd say LDC panels do recognize xres when fed from an analog source, so it's possible that this technology is present in newer CRTs.

So for us it would be great that hfreq was the value used by the monitor for making decisions, but maybe it's not so simple. Some months ago I tried to make modelines for a crt TV with a cheap digital chassis. Some resolutions were distorted for some reason. The same resolutions did work when removing some lines, keeping vfreq, others didn't. Things went definitely odd around 57Hz video modes, regardless the number of lines. I tried to find a rule for it (porches, hfreq, vfreq, vertical total,...) but couldn't, it seemed random, although consistent.

Sounds great, looking forward to that, will be nice to get this stuff easy to use for anybody, mainly the kernel patch and details on xorg.conf config

Also I've just gotten it so it'll override those 'invisible' default modes.  Turns out I can add a modeline of 800x600 with xrandr, I just can't label it such, it must be '800x600xSOMETHING_EXTRA' basically can't be just '800x600'.  Must be some odd bug in X, but doesn't matter because now I'm adding the xREFRESH as a string to each modeline generated for xrandr to use and now we can make those modes too.  Basically the way I'm doing it, to avoid any conflicts with my desktop mode, is I have a single modeline in xorg.conf as 641x480, then everything generated by switchres, even 640x480 modes, won't conflict with my desktop and we can use them even if a different refresh rate is needed.  I check and basically use that default desktop mode already in before launching switchres as a default in case no mode is specified by the game, but also align it to 8 removing the extra 1 pixel.  So a user with a generated desktop resolution of 641x480 or 801x600 doesn't have any worries about conflicting issues, switchres should take care of all the details.  I was always adding 8 pixels onto the horizontal width before this change, which now the focus is on the game being perfect and letting the desktop have 1 funny pixel extra.  Also if a person does use 640x480 on the desktop then it'll revert back to adding 8 pixels to the width to make up for it.  In all the calculations it always aligns it to 8 and I could try to force a single pixel there in those cases but seems unclean compared to just expecting the user to do that themselves for the desktop resolution.

I'm happy that old default modes annoyance has been overcome, I see it's convenient to use that 641x480 for the desktop so we make sure it's not mistaken with the others, it's clean.

VeS has started with the distribution. It's very likely we'll be harassing you with questions in the next days.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .24)
« Reply #176 on: November 16, 2010, 06:59:31 pm »
Ah, maybe that's the issue then, isn't the D9800 actually a digital monitor?  Could that be why it can do the range like it does and possibly how it's using the height/width to figure things out?

I'm almost sure that being digital must affect the results in some way, however your monitor seems to have an incredible range of tolerance. There's something I've been wondering, is if your monitor has some kind of autoadjust mechanism, so that when you set a resolution, it tries to autocenter, as pc monitors do. I suppose it's something necessary for multisync monitors, although I don't really have a proper understanding of what's going on from an electronic point of view. About height/width managing, I'd say LDC panels do recognize xres when fed from an analog source, so it's possible that this technology is present in newer CRTs.

It doesn't autoadjust like a normal computer monitor, at least not from what I can tell it doesn't do that.  I do know that it's a definitely 100% fix though just having that 1 line less for the resolutions with 288 active 312 lines total, when it was 313 it could kick into more of the wide EGA type mode but it never does that now that there are 312 lines total. 


So for us it would be great that hfreq was the value used by the monitor for making decisions, but maybe it's not so simple. Some months ago I tried to make modelines for a crt TV with a cheap digital chassis. Some resolutions were distorted for some reason. The same resolutions did work when removing some lines, keeping vfreq, others didn't. Things went definitely odd around 57Hz video modes, regardless the number of lines. I tried to find a rule for it (porches, hfreq, vfreq, vertical total,...) but couldn't, it seemed random, although consistent.

The lines seem to be a factor, but also from the slight change in vertical timing values used in that upper range near where 312+ lines occur it seems to keep it acting right.  I get the feeling it might have been the lines, but also think it might still be the hfreq because it's interesting that it's right at 19Khz where that extra line pushes it over the edge and it's inconsistent there and above.  It's almost at that point for the way a game like pacman turns out, we are right in the middle between CGA and EGA mode and if it's not the 312 line thing it might be the 19Khz point or a combination of both and how they interact and some other electronic variable from that combination.

Fortunately I think this is most likely the only type of monitor we have to worry about this on, and luckily we seem to have also possibly worked around it just with the extra range there at that in between point.  It does seem to follow a pattern, there's only one missing from the ranges inside the EGA range but seems to be a 2Khz range outside each of the normal ranges from VGA->SVGA and CGA->EGA modes where it needs different timing values vertically.


                # D9800/D9400
                #
                # CGA
                $MonitorModes[scalar(@MonitorModes)] =
                        fill_mode("15250-18000,40-80,2.187,4.688,6.719,0.190,0.191,1.018,0,0",
                        $MonitorModes[scalar(@MonitorModes)]);
                # CGA->EGA
                $MonitorModes[scalar(@MonitorModes)] =
                        fill_mode("18001-20000,40-80,2.187,4.688,6.719,0.140,0.191,0.950,0,0",
                        $MonitorModes[scalar(@MonitorModes)]);
                # EGA
                $MonitorModes[scalar(@MonitorModes)] =
                        fill_mode("20001-29000,40-80,2.910,3.000,4.440,0.451,0.164,1.048,0,0",
                        $MonitorModes[scalar(@MonitorModes)]);
                # VGA
                $MonitorModes[scalar(@MonitorModes)] =
                        fill_mode("29001-32000,40-80,0.636,3.813,1.906,0.318,0.064,1.048,0,0",
                        $MonitorModes[scalar(@MonitorModes)]);
                # VGA->SVGA
                $MonitorModes[scalar(@MonitorModes)] =
                        fill_mode("32001-34000,40-80,0.636,3.813,1.906,0.020,0.106,0.607,0,0",
                        $MonitorModes[scalar(@MonitorModes)]);
                # SVGA
                $MonitorModes[scalar(@MonitorModes)] =
                        fill_mode("34001-38900,40-80,1.000,3.200,2.200,0.020,0.106,0.607,1,1",
                        $MonitorModes[scalar(@MonitorModes)]);


Sounds great, looking forward to that, will be nice to get this stuff easy to use for anybody, mainly the kernel patch and details on xorg.conf config

Also I've just gotten it so it'll override those 'invisible' default modes.  Turns out I can add a modeline of 800x600 with xrandr, I just can't label it such, it must be '800x600xSOMETHING_EXTRA' basically can't be just '800x600'.  Must be some odd bug in X, but doesn't matter because now I'm adding the xREFRESH as a string to each modeline generated for xrandr to use and now we can make those modes too.  Basically the way I'm doing it, to avoid any conflicts with my desktop mode, is I have a single modeline in xorg.conf as 641x480, then everything generated by switchres, even 640x480 modes, won't conflict with my desktop and we can use them even if a different refresh rate is needed.  I check and basically use that default desktop mode already in before launching switchres as a default in case no mode is specified by the game, but also align it to 8 removing the extra 1 pixel.  So a user with a generated desktop resolution of 641x480 or 801x600 doesn't have any worries about conflicting issues, switchres should take care of all the details.  I was always adding 8 pixels onto the horizontal width before this change, which now the focus is on the game being perfect and letting the desktop have 1 funny pixel extra.  Also if a person does use 640x480 on the desktop then it'll revert back to adding 8 pixels to the width to make up for it.  In all the calculations it always aligns it to 8 and I could try to force a single pixel there in those cases but seems unclean compared to just expecting the user to do that themselves for the desktop resolution.

I'm happy that old default modes annoyance has been overcome, I see it's convenient to use that 641x480 for the desktop so we make sure it's not mistaken with the others, it's clean.

VeS has started with the distribution. It's very likely we'll be harassing you with questions in the next days.


Sounds great, I just uploaded a new version yet with a ton of overhauls of how things are done, making it must easier to handle the modeline etc.  Actually I think I fixed it so that Soft15Khz and AcradeVGA Windows support should work a lot 'better'.  Basically now it should properly choose the right resolution, write the modeline to the file if specified to store them in, run the game with the exact resolution from the input resolutions file and also do all the correct checking for different command line args to mame for the difference between the original resolution.  In the overhaul I just did, I broke apart the main body where I had a big if statement around stuff before and was able to reorder things much more logically and that was an natural outcome of the change.  I had not been doing that check for the input resolutions early enough, before modeline generation, and in Windows do the command line processing for mame after all that and not try to use a new resolution that isn't in that original resolutions file (and write out to the new resolutions file the more precise to that game modeline generated by our engine).

I also got the way the monitor modes are filled and stored to be a bit more robust, I'm still not sure though what to add for lines parameters for each monitor range yet.  Also I'm kind of seeing something odd sometimes in the logic of the virtualize function because of how it was built for interlace and I think it doesn't work well outside of that usage.  When I try bigger resolutions outside the d9800 limits and remove my max parameters for width/height then the virtualize function can give me back some really wild resolutions, way too large and I need to look deeper into how that's done and also how to deal with when interlacing isn't set to enabled and it can't use interlace.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .25)
« Reply #177 on: November 17, 2010, 01:18:04 pm »
I also got the way the monitor modes are filled and stored to be a bit more robust, I'm still not sure though what to add for lines parameters for each monitor range yet.  Also I'm kind of seeing something odd sometimes in the logic of the virtualize function because of how it was built for interlace and I think it doesn't work well outside of that usage.  When I try bigger resolutions outside the d9800 limits and remove my max parameters for width/height then the virtualize function can give me back some really wild resolutions, way too large and I need to look deeper into how that's done and also how to deal with when interlacing isn't set to enabled and it can't use interlace.

I've been thinking about it and realized that 'virtualization' only makes sense when used within the same interval, so it involves interlacing. So if a better non-interlaced resolution can be used for a particular case, it will be found when calculating in the upper interval. I've also attached a quick scheme of how this method would work in an ideal world, where low-res/mid-res/high-res are related to each other in a perfect way (that is not the reality, I know) but may help to visualize this stuff, however bear in mind that not all the limits shown in this model are actually checked in our implementation.

In theory, there wouldn't be any need for xres limits, provided they are inside our dotclock space. However, it can be convenient to set them to filter odd resolutions, etc.
With yres, we need to stablish some limits to keep things working. The method I was using assumed that monitors don't care about vtotal but only hfreq. So our vertical limits were more user defined limits than physical ones, and accounted for our tolerance with degradation of the picture. For instance, I use 288 active lines limit because I want to have pacman and such games as progressive, even if I can't get them to work at 60 Hz (anything above 256 lines can't work at 60 Hz with my monitor). But that makes necessary to adjust vertical amplitude potenciometer to get the picture inside the frame, each time I run these games, and readjust when I run a horizontal game. I have no trouble doing this, but some people can't access their adjustments so easily, maybe because they use a TV with no service mode, and they may want to set their active lines limit to 256 and virtualize anything above, which also has the advantage of recovering the original vfreq. The same with virtual lines limit, for instance in the attached scheme I've set it to 384 instead of 448, so above 384 I'll do interlace without stretch. This will produce a very panoramic picture, that will need to be corrected again with vertical amplitud potenciometer. I can set this v.l.l. to 576, so that all resolutions above 288 will be virtualized, achieving 4:3 looking resolutions for all of them and no adjust necessary, loosing some sharpness due to stretching but reducing flicker at the same time... so it's a matter of taste. You are getting wild resolutions because as your VfreqMin is just 40 Hz, that allows for a very high total virtualized yres. You'll need to find the limits for each interval that are convenient for you. The attached scheme is super-simplified, so there wouldn't be any doubt of which mode to use for each resolution. However your case is more complex, as there are overlapped ranges where we should account for vertical padding and vfreq accuracy to decide. And we also have this vtotal limit that we should consider somehow, although those transtion ranges you've set are a smart work around. However, this model was figured out making some assuptions that may not be true after all, so feel free to modify or improve it.

EDIT: "You are getting wild resolutions because as your VfreqMin is just 40 Hz, that allows for a very high total virtualized yres."... well that's not true, as you are using your real vfreq for calculations.
« Last Edit: November 17, 2010, 01:47:46 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .25)
« Reply #178 on: November 17, 2010, 11:59:18 pm »
I also got the way the monitor modes are filled and stored to be a bit more robust, I'm still not sure though what to add for lines parameters for each monitor range yet.  Also I'm kind of seeing something odd sometimes in the logic of the virtualize function because of how it was built for interlace and I think it doesn't work well outside of that usage.  When I try bigger resolutions outside the d9800 limits and remove my max parameters for width/height then the virtualize function can give me back some really wild resolutions, way too large and I need to look deeper into how that's done and also how to deal with when interlacing isn't set to enabled and it can't use interlace.

I've been thinking about it and realized that 'virtualization' only makes sense when used within the same interval, so it involves interlacing. So if a better non-interlaced resolution can be used for a particular case, it will be found when calculating in the upper interval. I've also attached a quick scheme of how this method would work in an ideal world, where low-res/mid-res/high-res are related to each other in a perfect way (that is not the reality, I know) but may help to visualize this stuff, however bear in mind that not all the limits shown in this model are actually checked in our implementation.

In theory, there wouldn't be any need for xres limits, provided they are inside our dotclock space. However, it can be convenient to set them to filter odd resolutions, etc.
With yres, we need to stablish some limits to keep things working. The method I was using assumed that monitors don't care about vtotal but only hfreq. So our vertical limits were more user defined limits than physical ones, and accounted for our tolerance with degradation of the picture. For instance, I use 288 active lines limit because I want to have pacman and such games as progressive, even if I can't get them to work at 60 Hz (anything above 256 lines can't work at 60 Hz with my monitor). But that makes necessary to adjust vertical amplitude potenciometer to get the picture inside the frame, each time I run these games, and readjust when I run a horizontal game. I have no trouble doing this, but some people can't access their adjustments so easily, maybe because they use a TV with no service mode, and they may want to set their active lines limit to 256 and virtualize anything above, which also has the advantage of recovering the original vfreq. The same with virtual lines limit, for instance in the attached scheme I've set it to 384 instead of 448, so above 384 I'll do interlace without stretch. This will produce a very panoramic picture, that will need to be corrected again with vertical amplitud potenciometer. I can set this v.l.l. to 576, so that all resolutions above 288 will be virtualized, achieving 4:3 looking resolutions for all of them and no adjust necessary, loosing some sharpness due to stretching but reducing flicker at the same time... so it's a matter of taste. You are getting wild resolutions because as your VfreqMin is just 40 Hz, that allows for a very high total virtualized yres. You'll need to find the limits for each interval that are convenient for you. The attached scheme is super-simplified, so there wouldn't be any doubt of which mode to use for each resolution. However your case is more complex, as there are overlapped ranges where we should account for vertical padding and vfreq accuracy to decide. And we also have this vtotal limit that we should consider somehow, although those transtion ranges you've set are a smart work around. However, this model was figured out making some assuptions that may not be true after all, so feel free to modify or improve it.

EDIT: "You are getting wild resolutions because as your VfreqMin is just 40 Hz, that allows for a very high total virtualized yres."... well that's not true, as you are using your real vfreq for calculations.


That chart is great, gave me an idea so I have done an overhaul of how the line limitations are done and also now only use the weighting method to simplify things somewhat in the modeline calculation itself.

I now am just using those two active lines and virtual lines values, but each range has those values. From that all the maximum and minimum X/Y res calculations are done using the Hfreq and Vrefresh values.  I seem to have mostly gotten this working, and the weighting improved to seem to pick the best resolution in most cases so far.  There's only really one difference I see and it's where in an EGA range I can't get 640x480 anymore at 40Hz to test starwars with, it's just slightly smaller than that size now.  It seems like that might be right, and better than before actually, I'm guessing the line ranges I gave are forcing it to be more correct.  Also I kind of modified the virtualize function to try and make it more general and virtualize without interlacing, still not sure if that fully is correct but at least a start.  You might want to look at that and see if there's anything odd I did there, that and the general modeline generation has changed somewhat and hopefully am doing it mostly right.  At least now it seems I still get the same values back as before for most games but no longer am requiring extra information about lines.  Also now it somewhat works for really high modelines for normal monitors and TV's, at least can kind of eek out of it a 1920x1080 modeline that is close to cvt (mostly seems timing might be different/wrong and need better values for those?).  It at least is an interesting test to see if it can do that, also now I've got it so the only extra line restriction you need to tell it if you choose is a lowest vertical line height with -ymin args.  This basically tells it what to limit progressive to before doublescan is used and overrides the minimum the monitor can handle, to force doublescan basically for like any game below 224 even if the monitor can handle it.  I still am not fully happy with the choices for virtualizing and interlacing when going up into higher resolutions and some weighting issues when having those types and comparing them to lower resolutions.  Although most of those areas are never really used by any arcade monitor or arcade games, so it's more of a perfection issue on getting it to be the most flexible and cover any monitor in the future.  I guess I figure if it can do that then it must be right, trying to find those ways to do things automatically, at least trying to not have any real limitations outside the users monitor specs.

So I uploaded .25 with those changes, will be interested what you think and if I made anything go bad at all in the virtualize stuff :).
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

ves

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 225
  • Last login:April 11, 2020, 02:57:49 am
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
« Reply #179 on: November 18, 2010, 09:11:25 am »
Hi, I'm starting to create live with ubuntu 10.10, I am with the version i386 (to be more compatible with most PC's), with which I do not worth your kernel compiled for amd64, I wanted to ask if just using the diff of the kernel is enough to compile for i386 or need something else, if you do not mind you could also hang the i386 version of kernel? I do not wish to compile incorrectly or missing something, and not work properly.

Probably have many questions about the operation of Switchres, hoping not to be heavy or annoying.




Thanks.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
« Reply #180 on: November 18, 2010, 02:17:53 pm »
I've found what seems a mistake in my virtualize function, where it says:

ActiveLinesMax = HfreqMin / VfreqMin - VBlankLines

It should be:

ActiveLinesMax = HfreqMax / VfreqMin - VBlankLines

I'm doing some tests with your script, to see your virtualize function working. There's something wrong as I can't get simple interlace work for me, for instance these two games:

Code: [Select]
Default Mode: 641x480@60
Display line for archrivl is:
  type: raster
  rotate: 0
  width: 512
  height: 480
  refresh: 30.000000

Using mame xml: [1] archrivl raster horizontal 512x480@30.000000 --> 512x480@30.000000 AR 1.066667

# 15.625Khz - 16.670Khz: ( | Increased height | Vertical refresh doubled | Interlaced | Virtualized | 250.5 lines Vertical padding | )
# [53] - 664x496@30.00 16.170Khz
     Modeline "664x496x60.00" 14.100250 664 696 760 872 496 499 504 539 -HSync -VSync interlace

# archrivl 664x496@30.00 16.170Khz
     Modeline "664x496x60.00" 14.100250 664 696 760 872 496 499 504 539 -HSync -VSync interlace
Starting archrivl in mode "512x480" at 30.000000Hz
mame child exited with value 6
Finished running SwitchRes for archrivl with the mame emulator.

Code: [Select]
Default Mode: 641x480@60
Display line for alpinerd is:
  type: raster
  rotate: 0
  width: 640
  height: 480
  refresh: 60.000000

Using mame xml: [1] alpinerd raster horizontal 640x480@60.000000 --> 640x480@60.000000 AR 1.333333

# 15.625Khz - 16.670Khz: ( | Increased height | Interlaced | Virtualized | 250.5 lines Vertical padding | )
# [52] - 664x496@30.00 16.170Khz
     Modeline "664x496x60.00" 14.100250 664 696 760 872 496 499 504 539 -HSync -VSync interlace

# alpinerd 664x496@30.00 16.170Khz
     Modeline "664x496x60.00" 14.100250 664 696 760 872 496 499 504 539 -HSync -VSync interlace
Starting alpinerd in mode "640x480" at 60.000000Hz
mame child exited with value 6
Finished running SwitchRes for alpinerd with the mame emulator.

In both cases, 512x480 and 640x480 shouldn't be virtualized, as 480 is above my virtual lines limit:
 
            # Hantarex MTC 9110
             $MonitorModes[scalar(@MonitorModes)] =
         fill_mode("15625-16670,49.5-65,2.000,4.700,8.000,0.064,0.160,1.056,0,0,288,448"

On the other hand, I'm seeing that in order to disable interlacing, you are setting v.l.l. = a.l.l. Following my logic, that would reduce virtualize interval to 0, and would interlace anything among 288 (without stretching -> panoramic picture). If you really intended to eliminate interlaced interval, you should make v.l.l. = a.l.l. x 2, so anything above 288 would be virtualized.

Now, let's see the same with D9800:

Code: [Select]
Default Mode: 641x480@60
Display line for archrivl is:
  type: raster
  rotate: 0
  width: 512
  height: 480
  refresh: 30.000000

Using mame xml: [1] archrivl raster horizontal 512x480@30.000000 --> 512x480@30.000000 AR 1.066667

# 15.250Khz - 18.000Khz: ( | Increased height | Vertical refresh doubled | Virtualized | 227 lines Vertical padding | )
# [40] - 368x272@60.00 17.820Khz
     Modeline "368x272x60.00" 8.838750 368 392 432 496 272 276 279 297 -HSync -VSync

# 18.001Khz - 20.000Khz: ( | Increased height | Vertical refresh doubled | Virtualized | 190 lines Vertical padding | )
# [35] - 408x304@60.00 19.800Khz
     Modeline "408x304x60.00" 11.246500 408 432 488 568 304 307 311 330 -HSync -VSync

# 20.001Khz - 29.000Khz: ( | Increased height | Vertical refresh doubled | Virtualized | 61 lines Vertical padding | )
# [19] - 568x424@60.00 28.320Khz
     Modeline "568x424x60.00" 22.429500 568 632 696 792 424 437 442 472 -HSync -VSync

# 29.001Khz - 32.000Khz: ( | Vertical refresh doubled | )
# [1] - 512x480@60.00 31.500Khz
     Modeline "512x480x60.00" 20.412000 512 528 608 648 480 490 492 525 -HSync -VSync

# 32.001Khz - 34.000Khz: ( | Vertical refresh doubled | Horizontal frequency raised | 32 lines Vertical padding | )
# [6] - 512x480@60.00 32.040Khz
     Modeline "512x480x60.00" 20.762000 512 528 608 648 480 496 499 534 -HSync -VSync

# 34.001Khz - 38.900Khz: ( | Vertical refresh doubled | Horizontal frequency raised | 65 lines Vertical padding | )
# [10] - 512x480@60.00 34.020Khz
     Modeline "512x480x60.00" 22.317250 512 536 608 656 480 512 516 567 +HSync +VSync

# archrivl 512x480@60.00 31.500Khz
     Modeline "512x480x60.00" 20.412000 512 528 608 648 480 490 492 525 -HSync -VSync
Starting archrivl in mode "512x480" at 30.000000Hz
Finished running SwitchRes for archrivl with the mame emulator.

This first mode (even if it won't be used):
Modeline "368x272x60.00" 8.838750 368 392 432 496 272 276 279 297 -HSync -VSync
If it's virtualized, it's supposed to be stretched, so I would go for it's real xres (512), even if you don't get 4:3 aspect (who cares), otherwise you wouldn't be using that range's resolution to its full capacity. You should use HfreqMax for calculations (see my first comment) so you can raise your yres to almost 288. On the other hand, I can't see why it's reporting vertical padding at all with this mode.

I still have to look deeper at your code to understand the complete logic, however it seems you're checking height limits twice "Check height restrictions" and "Check active lines limit", there's a good reason for sure... I have to keep reading.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
« Reply #181 on: November 18, 2010, 02:30:32 pm »
Hi, I'm starting to create live with ubuntu 10.10, I am with the version i386 (to be more compatible with most PC's), with which I do not worth your kernel compiled for amd64, I wanted to ask if just using the diff of the kernel is enough to compile for i386 or need something else, if you do not mind you could also hang the i386 version of kernel? I do not wish to compile incorrectly or missing something, and not work properly.

Probably have many questions about the operation of Switchres, hoping not to be heavy or annoying.




Thanks.

Try the one that is labeled arcade32, it still says amd64 on it but it is cross compiled for the i386 and should work.  I think that when cross compiling on an amd64 system it still puts that in the file name.  So the linux-image-2.6.37-rc1-arcade32_0.2_amd64.deb one is supposed to be i386 and since I don't have a system to test that would be great if you could confirm that working.  Otherwise you'll need to use the linux patch on 2.6.37-rc1 (I haven't tried newer kernels yet) and then download the ubuntu patches for it http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.37-rc1-maverick/ , the use the fakeroot and make-kpkg utilities like this...


# 32 bit
fakeroot linux32 make-kpkg --initrd --append-to-version=-arcade32 --revision=0.1 --cross-compile - --arch i386 --overlay-dir=/home/ckennedy/kernel-package kernel_headers kernel_image

# 64 bit
fakeroot make-kpkg --initrd --append-to-version=-arcade64 --revision=0.1 --cross-compile - --arch amd64 --overlay-dir=/home/ckennedy/kernel-package kernel_headers kernel_image


Or similar, more info here: http://crashcourse.ca/introduction-linux-kernel-programming/intermission-building-new-ubuntu-1004-kernel-free-lesson  and there's other places too but mostly what I did above would be the necessary commands to get it working.



Sounds great, ask all the questions you need to, looking forward to having it more easily usable by others :).
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
« Reply #182 on: November 18, 2010, 02:56:58 pm »
I've found what seems a mistake in my virtualize function, where it says:

ActiveLinesMax = HfreqMin / VfreqMin - VBlankLines

It should be:

ActiveLinesMax = HfreqMax / VfreqMin - VBlankLines

Ah, I have actually changed that back and forth and wondered about that, thanks, now I guess I somewhat was understanding it.  Definitely am slowly learning about all the different calculations which can be done to get values like that, oddly I got some decent values with the minimum one so thought that it belonged but I changed it to max now since you confirmed my suspicions it was wrong.

I'm doing some tests with your script, to see your virtualize function working. There's something wrong as I can't get simple interlace work for me, for instance these two games:

Code: [Select]
Default Mode: 641x480@60
Display line for archrivl is:
  type: raster
  rotate: 0
  width: 512
  height: 480
  refresh: 30.000000

Using mame xml: [1] archrivl raster horizontal 512x480@30.000000 --> 512x480@30.000000 AR 1.066667

# 15.625Khz - 16.670Khz: ( | Increased height | Vertical refresh doubled | Interlaced | Virtualized | 250.5 lines Vertical padding | )
# [53] - 664x496@30.00 16.170Khz
     Modeline "664x496x60.00" 14.100250 664 696 760 872 496 499 504 539 -HSync -VSync interlace

# archrivl 664x496@30.00 16.170Khz
     Modeline "664x496x60.00" 14.100250 664 696 760 872 496 499 504 539 -HSync -VSync interlace
Starting archrivl in mode "512x480" at 30.000000Hz
mame child exited with value 6
Finished running SwitchRes for archrivl with the mame emulator.

Code: [Select]
Default Mode: 641x480@60
Display line for alpinerd is:
  type: raster
  rotate: 0
  width: 640
  height: 480
  refresh: 60.000000

Using mame xml: [1] alpinerd raster horizontal 640x480@60.000000 --> 640x480@60.000000 AR 1.333333

# 15.625Khz - 16.670Khz: ( | Increased height | Interlaced | Virtualized | 250.5 lines Vertical padding | )
# [52] - 664x496@30.00 16.170Khz
     Modeline "664x496x60.00" 14.100250 664 696 760 872 496 499 504 539 -HSync -VSync interlace

# alpinerd 664x496@30.00 16.170Khz
     Modeline "664x496x60.00" 14.100250 664 696 760 872 496 499 504 539 -HSync -VSync interlace
Starting alpinerd in mode "640x480" at 60.000000Hz
mame child exited with value 6
Finished running SwitchRes for alpinerd with the mame emulator.

In both cases, 512x480 and 640x480 shouldn't be virtualized, as 480 is above my virtual lines limit:
 
            # Hantarex MTC 9110
             $MonitorModes[scalar(@MonitorModes)] =
         fill_mode("15625-16670,49.5-65,2.000,4.700,8.000,0.064,0.160,1.056,0,0,288,448"

Also try running with -v -v -v -v, more -v's will get some more detail about what it's doing and you can go easier to the point it's virtualizing.  


On the other hand, I'm seeing that in order to disable interlacing, you are setting v.l.l. = a.l.l. Following my logic, that would reduce virtualize interval to 0, and would interlace anything among 288 (without stretching -> panoramic picture). If you really intended to eliminate interlaced interval, you should make v.l.l. = a.l.l. x 2, so anything above 288 would be virtualized.

Yeah it was a quick hack to get it to be able to turn off for now.  If I make the v.l.l = a.l.l x 2 though it currently will interlace it won't it up to that x2 value?  This is one of the main things I was trying to figure out but am sort of confused how the interlace can be set but not virtualize and that's where sometimes odd resolutions would be output.


Now, let's see the same with D9800:

Code: [Select]
Default Mode: 641x480@60
Display line for archrivl is:
  type: raster
  rotate: 0
  width: 512
  height: 480
  refresh: 30.000000

Using mame xml: [1] archrivl raster horizontal 512x480@30.000000 --> 512x480@30.000000 AR 1.066667

# 15.250Khz - 18.000Khz: ( | Increased height | Vertical refresh doubled | Virtualized | 227 lines Vertical padding | )
# [40] - 368x272@60.00 17.820Khz
     Modeline "368x272x60.00" 8.838750 368 392 432 496 272 276 279 297 -HSync -VSync

# 18.001Khz - 20.000Khz: ( | Increased height | Vertical refresh doubled | Virtualized | 190 lines Vertical padding | )
# [35] - 408x304@60.00 19.800Khz
     Modeline "408x304x60.00" 11.246500 408 432 488 568 304 307 311 330 -HSync -VSync

# 20.001Khz - 29.000Khz: ( | Increased height | Vertical refresh doubled | Virtualized | 61 lines Vertical padding | )
# [19] - 568x424@60.00 28.320Khz
     Modeline "568x424x60.00" 22.429500 568 632 696 792 424 437 442 472 -HSync -VSync

# 29.001Khz - 32.000Khz: ( | Vertical refresh doubled | )
# [1] - 512x480@60.00 31.500Khz
     Modeline "512x480x60.00" 20.412000 512 528 608 648 480 490 492 525 -HSync -VSync

# 32.001Khz - 34.000Khz: ( | Vertical refresh doubled | Horizontal frequency raised | 32 lines Vertical padding | )
# [6] - 512x480@60.00 32.040Khz
     Modeline "512x480x60.00" 20.762000 512 528 608 648 480 496 499 534 -HSync -VSync

# 34.001Khz - 38.900Khz: ( | Vertical refresh doubled | Horizontal frequency raised | 65 lines Vertical padding | )
# [10] - 512x480@60.00 34.020Khz
     Modeline "512x480x60.00" 22.317250 512 536 608 656 480 512 516 567 +HSync +VSync

# archrivl 512x480@60.00 31.500Khz
     Modeline "512x480x60.00" 20.412000 512 528 608 648 480 490 492 525 -HSync -VSync
Starting archrivl in mode "512x480" at 30.000000Hz
Finished running SwitchRes for archrivl with the mame emulator.

This first mode (even if it won't be used):
Modeline "368x272x60.00" 8.838750 368 392 432 496 272 276 279 297 -HSync -VSync
If it's virtualized, it's supposed to be stretched, so I would go for it's real xres (512), even if you don't get 4:3 aspect (who cares), otherwise you wouldn't be using that range's resolution to its full capacity. You should use HfreqMax for calculations (see my first comment) so you can raise your yres to almost 288. On the other hand, I can't see why it's reporting vertical padding at all with this mode.

I still have to look deeper at your code to understand the complete logic, however it seems you're checking height limits twice "Check height restrictions" and "Check active lines limit", there's a good reason for sure... I have to keep reading.



Yeah the vertical padding is sort of guessed and somewhat works but basically it is comparing what the ideal height would be to the final height after all the changes to meet the limitations.  So sometimes it's actually smaller and to use it as a weight still I just reverse the calcuation to see how much less it is than it was supposed to be.  That's another thing that I wasn't fully sure of still, how to get the exact amount of padding and weight it correctly.

The height limits checks and things like that which are done twice might be old methods I was using when the function tried to do all ranges and once it picked the best one it had to do some over again with the newer range.  So there may be some logic there still that needs to be improved, it was interesting making it weight by default, since it forced me to use weighting and of course I found a few little odd bugs in how it worked but now really can focus on it working since it's the only choice.

Update: I see what your saying about it virtualizing/interlacing above your virtual lines limit there, I think it needs to check that closer because right now it's probably just using the technical possible max and not listening to that value.  So I'm right now looking to see how to make sure it obeys the virtual lines limit value better.

Update2: Also I am always wondering about that, the aspect ratio check stuff, so I should remove that when reducing width/height?  I always think I should do the same as when adapting to a vertical game, but can see that many games aren't a 4/3 aspect and have non-square pixels.  Seems something should be done though to adjust when changing only one value, height or width though.  


Udate3: Ok , I think I fixed some of these issues, here's a diff of the virtualize function, I'm guessing because it's going by monitor limits and not our virtual lines limit it starts out too high and allows resolutions to be interlaced bigger than we told it to allow.
Code: [Select]
@@ -1566,9 +1583,14 @@ sub ResVirtualize () {
   my $vfreqlimit;
 
   $VBlankLines = $Mode[0]{'HfreqMax'} * $Mode[0]{'VerticalBlank'};
-  $ActiveLinesMax = $Mode[0]{'HfreqMin'} / $Mode[0]{'VfreqMin'} - $VBlankLines;
+  $ActiveLinesMax = $Mode[0]{'HfreqMax'} / $Mode[0]{'VfreqMin'} - $VBlankLines;
   $ActiveLinesMin = ($Mode[0]{'HfreqMin'} / $Mode[0]{'VfreqMax'} - $VBlankLines);
 
+  # Check user requested maximum interlacing size
+  if (($interlace * $ActiveLinesMax) > $Mode[0]{'VirtualLinesLimit'}) {
+       $ActiveLinesMax = $Mode[0]{'VirtualLinesLimit'} / 2;
+  }
+
   for ($i = (Normalize($ActiveLinesMax, 8) * $interlace); $i >= (Normalize($ActiveLinesMin, 16)*$interlace); $i -= 16) {
     $yres = $i;
     $VBlankLines = ( $Mode[0]{'HfreqMax'} - 50 ) * $Mode[0]{'VerticalBlank'};



Also I have removed a lot of the extra checks, will post a new version soon, seems to at least be a bit more obeying of the limits we set with that virtual lines limit and avoids the aspect ratio alterations.

« Last Edit: November 18, 2010, 03:54:21 pm by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

ves

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 225
  • Last login:April 11, 2020, 02:57:49 am
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
« Reply #183 on: November 18, 2010, 03:34:25 pm »
Hi, I'm starting to create live with ubuntu 10.10, I am with the version i386 (to be more compatible with most PC's), with which I do not worth your kernel compiled for amd64, I wanted to ask if just using the diff of the kernel is enough to compile for i386 or need something else, if you do not mind you could also hang the i386 version of kernel? I do not wish to compile incorrectly or missing something, and not work properly.

Probably have many questions about the operation of Switchres, hoping not to be heavy or annoying.




Thanks.

Try the one that is labeled arcade32, it still says amd64 on it but it is cross compiled for the i386 and should work.  I think that when cross compiling on an amd64 system it still puts that in the file name.  So the linux-image-2.6.37-rc1-arcade32_0.2_amd64.deb one is supposed to be i386 and since I don't have a system to test that would be great if you could confirm that working.  Otherwise you'll need to use the linux patch on 2.6.37-rc1 (I haven't tried newer kernels yet) and then download the ubuntu patches for it http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.37-rc1-maverick/ , the use the fakeroot and make-kpkg utilities like this...


# 32 bit
fakeroot linux32 make-kpkg --initrd --append-to-version=-arcade32 --revision=0.1 --cross-compile - --arch i386 --overlay-dir=/home/ckennedy/kernel-package kernel_headers kernel_image

# 64 bit
fakeroot make-kpkg --initrd --append-to-version=-arcade64 --revision=0.1 --cross-compile - --arch amd64 --overlay-dir=/home/ckennedy/kernel-package kernel_headers kernel_image


Or similar, more info here: http://crashcourse.ca/introduction-linux-kernel-programming/intermission-building-new-ubuntu-1004-kernel-free-lesson  and there's other places too but mostly what I did above would be the necessary commands to get it working.



Sounds great, ask all the questions you need to, looking forward to having it more easily usable by others :).


Hello bitbytebit thank you very much for the patches and for your great help, with regard to compiling the kernel I have no problems doing that, what happens is I do not want to make a version that is not correct, will try tonight to see if you let me install the version of 32, but I think it was attempting to install and told me that he could not because of 64.
Could you upload your file. Kernel config?
We need to activate something in the kernel menuconfig?

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
« Reply #184 on: November 18, 2010, 03:44:42 pm »
Hi, I'm starting to create live with ubuntu 10.10, I am with the version i386 (to be more compatible with most PC's), with which I do not worth your kernel compiled for amd64, I wanted to ask if just using the diff of the kernel is enough to compile for i386 or need something else, if you do not mind you could also hang the i386 version of kernel? I do not wish to compile incorrectly or missing something, and not work properly.

Probably have many questions about the operation of Switchres, hoping not to be heavy or annoying.




Thanks.

Try the one that is labeled arcade32, it still says amd64 on it but it is cross compiled for the i386 and should work.  I think that when cross compiling on an amd64 system it still puts that in the file name.  So the linux-image-2.6.37-rc1-arcade32_0.2_amd64.deb one is supposed to be i386 and since I don't have a system to test that would be great if you could confirm that working.  Otherwise you'll need to use the linux patch on 2.6.37-rc1 (I haven't tried newer kernels yet) and then download the ubuntu patches for it http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.37-rc1-maverick/ , the use the fakeroot and make-kpkg utilities like this...


# 32 bit
fakeroot linux32 make-kpkg --initrd --append-to-version=-arcade32 --revision=0.1 --cross-compile - --arch i386 --overlay-dir=/home/ckennedy/kernel-package kernel_headers kernel_image

# 64 bit
fakeroot make-kpkg --initrd --append-to-version=-arcade64 --revision=0.1 --cross-compile - --arch amd64 --overlay-dir=/home/ckennedy/kernel-package kernel_headers kernel_image


Or similar, more info here: http://crashcourse.ca/introduction-linux-kernel-programming/intermission-building-new-ubuntu-1004-kernel-free-lesson  and there's other places too but mostly what I did above would be the necessary commands to get it working.



Sounds great, ask all the questions you need to, looking forward to having it more easily usable by others :).


Hello bitbytebit thank you very much for the patches and for your great help, with regard to compiling the kernel I have no problems doing that, what happens is I do not want to make a version that is not correct, will try tonight to see if you let me install the version of 32, but I think it was attempting to install and told me that he could not because of 64.
Could you upload your file. Kernel config?
We need to activate something in the kernel menuconfig?

Yeah I was wondering about the cross compiling not working, from what I can tell my Ubuntu system doesn't really do any cross compiling well even though I've got it set the way everything online says to.  I can't even compile 32bit apps that run on it, so that makes sense, that the kernel isn't cross compiling correctly.  I'm letting it basically use the default kernel config that Ubuntu uses for 10.10, it chooses it automatically from that debian directory it puts into the kernel directory.  I included the one it created, it all says it's 32 bit, but guessing the compiler somehow didn't do it or the packaging forced itself to be 64 bit (might actually work but isn't able to install I'm guessing, cause it see's it's a 64 bit package).  Might be better anyways though for you to get the build done there so you can modify it too.  The stuff that is necessary is already the defaults in the Ubuntu kernel config, radeon DRM and KMS built in.  The key though to activate the arcade modes for frame buffer output and avoid other conflicts with X windows is to add the video=640x480c on the kernel command line in grub.cfg, I never figured out how to do that automatically in the .deb install setup, I'm not sure it's even possible actually.  Also you can say things like video=DVI-I-0:640x480c to choose to only use one of the outputs in arcade mode, so the other output of the video card could be a normal monitor that way.  It at least should work in theory that way, and mine does so it seems to work.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

ves

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 225
  • Last login:April 11, 2020, 02:57:49 am
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
« Reply #185 on: November 18, 2010, 03:48:59 pm »
One more thing, you know there are problems with Ubuntu 10.10 with the video when you load the kernel with real arcade monitors? ceased to be the image, as I recall it was for the kms (why not use the 10.10 for the first live), I guess your patch fixes the problem, right?


Thanks.

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
« Reply #186 on: November 18, 2010, 03:57:02 pm »
One more thing, you know there are problems with Ubuntu 10.10 with the video when you load the kernel with real arcade monitors? ceased to be the image, as I recall it was for the kms (why not use the 10.10 for the first live), I guess your patch fixes the problem, right?


Thanks.

Yes, this should fix that with that video=640x480c line in grub.cfg, because it'll use the arcade compatible interlaced version of that resolution for the frame buffer output. 
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26a)
« Reply #187 on: November 18, 2010, 04:42:47 pm »
Calamity: 

I have a new version up that hopefully fixes some of these issues, I think I figured out mostly what needs to be done for following the virtualization limits.  Still not sure about turning off interlacing for a range, so have that the same but interested in how to do this better.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26a)
« Reply #188 on: November 18, 2010, 05:25:45 pm »
I still can't get a pure 512x480 interlaced resolution for this game:

Code: [Select]
Default Mode: 641x480@60
Display line for archrivl is:
  type: raster
  rotate: 0
  width: 512
  height: 480
  refresh: 30.000000

Using mame xml: [1] archrivl raster horizontal 512x480@30.000000 1.066667 --> 512x480@30.000000 AR 1.066667

Reduced: 448 lines > 448 virtual line limit!!!
Virtualized resolution to 600x448@60 14.716416Khz with
Vertical Refresh: 60.000Hz Actual: 60.001Hz
Using ModeBase: 0 Lines: 260.5 VBlankLines: 20.5 Pad: (+-259.5) Margen: 16 VBlank: 0.00128 Hfreq: 15.630Khz Vref: 60.00Hz
Monitor Limits are 184 x 112 minimum and 288 max vertical lines, Active/Virtual (288/448)

# 15.625Khz - 16.670Khz: ( | Increased height | Vertical refresh doubled | Interlaced | Virtualized | 259.5 lines Vertical padding | )
# [54] - 600x448@30.00 15.630Khz
     Modeline "600x448x60.00" 12.129000 600 624 680 776 448 466 471 521 -HSync -VSync interlace

# archrivl 600x448@30.00 15.630Khz
     Modeline "600x448x60.00" 12.129000 600 624 680 776 448 466 471 521 -HSync -VSync interlace
Warning: 512x480 != 512x480!!!
Starting archrivl in mode "512x480" at 30.000000Hz
Executing: 'mame archrivl -cleanstretch -throttle -mt -resolution 512x480@30.000000'
Target refresh = 30.000000
mame child exited with value 2
Finished running SwitchRes for archrivl with the mame emulator.

I think the problem is this: Reduced: 448 lines > 448 virtual line limit!!!

Here our resolution shouldn't be reduced. The intervals should work like this:

]ActiveLinesLimit, VirtualLinesLimit] -> Virtualize (interlace & stretch)
]VirtualLinesLimit, ActiveLinesLimit * 2] -> Only interlace*
]ActiveLinesLimit * 2, infinitum[ -> Virtualize (interlace & stretch)

* but, if you want to disable interlace at all, you can mantain a flag for it, probably in a structure were videocard capabilities reside. So for any of the intervals above, it would be checked before activating or not 'interlace' variable (0.5, 1, 2... the same for doublescan) and in case it was no allowed, we would always call virtualize function for all of these intervals, but as 'interlace' won't be activated, you'll get a virtualized progressive res.

There's another possibility I just dropped because I don't like it: do not virtualize (stretch) but make a progressive resolution with less total lines when it's needed, so we don't stretch but we loose some lines at top and bottom. In that case you do have to care about aspect.

But as long as we are stretching, it's Mame who cares about aspect already, so we just want to have a big resolution, even if its very wide, because the result will be sharper. Don't worry if it's a strange resolution, after all it's a throw-away modeline ;D

When dealing with vertical games, I also consider aspect ratio when the original resolution allows for rotation+progressive, but if it's going to be virtualized, the bigger the better.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26a)
« Reply #189 on: November 18, 2010, 05:37:22 pm »
I still can't get a pure 512x480 interlaced resolution for this game:

Code: [Select]
Default Mode: 641x480@60
Display line for archrivl is:
  type: raster
  rotate: 0
  width: 512
  height: 480
  refresh: 30.000000

Using mame xml: [1] archrivl raster horizontal 512x480@30.000000 1.066667 --> 512x480@30.000000 AR 1.066667

Reduced: 448 lines > 448 virtual line limit!!!
Virtualized resolution to 600x448@60 14.716416Khz with
Vertical Refresh: 60.000Hz Actual: 60.001Hz
Using ModeBase: 0 Lines: 260.5 VBlankLines: 20.5 Pad: (+-259.5) Margen: 16 VBlank: 0.00128 Hfreq: 15.630Khz Vref: 60.00Hz
Monitor Limits are 184 x 112 minimum and 288 max vertical lines, Active/Virtual (288/448)

# 15.625Khz - 16.670Khz: ( | Increased height | Vertical refresh doubled | Interlaced | Virtualized | 259.5 lines Vertical padding | )
# [54] - 600x448@30.00 15.630Khz
     Modeline "600x448x60.00" 12.129000 600 624 680 776 448 466 471 521 -HSync -VSync interlace

# archrivl 600x448@30.00 15.630Khz
     Modeline "600x448x60.00" 12.129000 600 624 680 776 448 466 471 521 -HSync -VSync interlace
Warning: 512x480 != 512x480!!!
Starting archrivl in mode "512x480" at 30.000000Hz
Executing: 'mame archrivl -cleanstretch -throttle -mt -resolution 512x480@30.000000'
Target refresh = 30.000000
mame child exited with value 2
Finished running SwitchRes for archrivl with the mame emulator.

I think the problem is this: Reduced: 448 lines > 448 virtual line limit!!!

Here our resolution shouldn't be reduced. The intervals should work like this:

]ActiveLinesLimit, VirtualLinesLimit] -> Virtualize (interlace & stretch)
]VirtualLinesLimit, ActiveLinesLimit * 2] -> Only interlace*
]ActiveLinesLimit * 2, infinitum[ -> Virtualize (interlace & stretch)

* but, if you want to disable interlace at all, you can mantain a flag for it, probably in a structure were videocard capabilities reside. So for any of the intervals above, it would be checked before activating or not 'interlace' variable (0.5, 1, 2... the same for doublescan) and in case it was no allowed, we would always call virtualize function for all of these intervals, but as 'interlace' won't be activated, you'll get a virtualized progressive res.

There's another possibility I just dropped because I don't like it: do not virtualize (stretch) but make a progressive resolution with less total lines when it's needed, so we don't stretch but we loose some lines at top and bottom. In that case you do have to care about aspect.

But as long as we are stretching, it's Mame who cares about aspect already, so we just want to have a big resolution, even if its very wide, because the result will be sharper. Don't worry if it's a strange resolution, after all it's a throw-away modeline ;D

When dealing with vertical games, I also consider aspect ratio when the original resolution allows for rotation+progressive, but if it's going to be virtualized, the bigger the better.




This diff fixes that, now I see why that interlace was done before the virtualize function there :)
Code: [Select]

diff --git a/switchres b/switchres
index 24182ae..afd2129 100755
--- a/switchres
+++ b/switchres
@@ -1239,9 +1239,9 @@ sub get_modeline($ $ $ @) {
        }
 
        # Pay attention to max ability of interlacing/virtualization
-       if ($YresMax > $Mode[$ModeBase]{'VirtualLinesLimit'}) {
-               $YresMax = $Mode[$ModeBase]{'ActiveLinesLimit'};
-       }
+       #if ($YresMax > $Mode[$ModeBase]{'VirtualLinesLimit'}) {
+       #       $YresMax = $Mode[$ModeBase]{'ActiveLinesLimit'};
+       #}
 
        # Hardwired for now
        $XresMin = 184;
@@ -1310,12 +1310,12 @@ sub get_modeline($ $ $ @) {
 
        # Check active lines limit
        if ($OriginalHeight > $Mode[$ModeBase]{'ActiveLinesLimit'}) {
+               $interlace = 2;
                if ($can_interlace && $OriginalHeight <= $Mode[$ModeBase]{'VirtualLinesLimit'}) {
                        if ($VERBOSE > 1) {
                                print "Interlacing: $OriginalHeight lines > $Mode[$ModeBase]{'ActiveLinesLimit'} active line limit!!!\n";
                        }
                        $MODELINE_RESULT |= $INTERLACED;
-                       $interlace = 2;
                        my $line = ResVirtualize($OriginalWidth, $OriginalHeight, $Refresh, $HFreq, $interlace, $Mode[$ModeBase]);
                        if ($line) {
                                ($OriginalWidth, $OriginalHeight, $Refresh, $HFreq) = split(/\s/, $line);
@@ -1592,13 +1592,16 @@ sub ResVirtualize () {
   if ($ActiveLinesMin > $Mode[0]{'YresMin'}) {
        $ActiveLinesMin = $Mode[0]{'YresMin'};
   }
-  # Check user requested maximum interlacing size
-  if (($interlace * $ActiveLinesMax) > $Mode[0]{'VirtualLinesLimit'}) {
-       $ActiveLinesMax = $Mode[0]{'VirtualLinesLimit'} / $interlace;
-  }
-  if ($yres > ($ActiveLinesMin * $interlace) && $yres < $ActiveLinesMax) {
-       $ActiveLinesMax = $yres;
+  if ($ActiveLinesMax > $Mode[0]{'YresMax'}) {
+       $ActiveLinesMax = $Mode[0]{'YresMax'};
   }
+  # Check user requested maximum interlacing size
+  #if (($interlace * $ActiveLinesMax) > $Mode[0]{'VirtualLinesLimit'}) {
+  #    $ActiveLinesMax = $Mode[0]{'VirtualLinesLimit'} / $interlace;
+  #}
+  #if ($yres > ($ActiveLinesMin * $interlace) && $yres < $ActiveLinesMax) {
+  #    $ActiveLinesMax = $yres;
+  #}
 
   for ($i = (Normalize($ActiveLinesMax, 8) * $interlace); $i >= (Normalize($ActiveLinesMin, 16)*$interlace); $i -= 16) {
     $yres = $i;



Is it correct for me to comment out that stuff in the virtualize function, seems like it makes sense from what you said to just check min/max we already calculated too.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26a)
« Reply #190 on: November 18, 2010, 05:42:26 pm »
I still can't get a pure 512x480 interlaced resolution for this game:

This diff fixes that, now I see why that interlace was done before the virtualize function there :).  
Code: [Select]

diff --git a/switchres b/switchres
index 24182ae..afd2129 100755
--- a/switchres
+++ b/switchres
@@ -1239,9 +1239,9 @@ sub get_modeline($ $ $ @) {
        }
 
        # Pay attention to max ability of interlacing/virtualization
-       if ($YresMax > $Mode[$ModeBase]{'VirtualLinesLimit'}) {
-               $YresMax = $Mode[$ModeBase]{'ActiveLinesLimit'};
-       }
+       #if ($YresMax > $Mode[$ModeBase]{'VirtualLinesLimit'}) {
+       #       $YresMax = $Mode[$ModeBase]{'ActiveLinesLimit'};
+       #}
 
        # Hardwired for now
        $XresMin = 184;
@@ -1310,12 +1310,12 @@ sub get_modeline($ $ $ @) {
 
        # Check active lines limit
        if ($OriginalHeight > $Mode[$ModeBase]{'ActiveLinesLimit'}) {
+               $interlace = 2;
                if ($can_interlace && $OriginalHeight <= $Mode[$ModeBase]{'VirtualLinesLimit'}) {
                        if ($VERBOSE > 1) {
                                print "Interlacing: $OriginalHeight lines > $Mode[$ModeBase]{'ActiveLinesLimit'} active line limit!!!\n";
                        }
                        $MODELINE_RESULT |= $INTERLACED;
-                       $interlace = 2;
                        my $line = ResVirtualize($OriginalWidth, $OriginalHeight, $Refresh, $HFreq, $interlace, $Mode[$ModeBase]);
                        if ($line) {
                                ($OriginalWidth, $OriginalHeight, $Refresh, $HFreq) = split(/\s/, $line);
@@ -1592,13 +1592,16 @@ sub ResVirtualize () {
   if ($ActiveLinesMin > $Mode[0]{'YresMin'}) {
        $ActiveLinesMin = $Mode[0]{'YresMin'};
   }
-  # Check user requested maximum interlacing size
-  if (($interlace * $ActiveLinesMax) > $Mode[0]{'VirtualLinesLimit'}) {
-       $ActiveLinesMax = $Mode[0]{'VirtualLinesLimit'} / $interlace;
-  }
-  if ($yres > ($ActiveLinesMin * $interlace) && $yres < $ActiveLinesMax) {
-       $ActiveLinesMax = $yres;
+  if ($ActiveLinesMax > $Mode[0]{'YresMax'}) {
+       $ActiveLinesMax = $Mode[0]{'YresMax'};
   }
+  # Check user requested maximum interlacing size
+  #if (($interlace * $ActiveLinesMax) > $Mode[0]{'VirtualLinesLimit'}) {
+  #    $ActiveLinesMax = $Mode[0]{'VirtualLinesLimit'} / $interlace;
+  #}
+  #if ($yres > ($ActiveLinesMin * $interlace) && $yres < $ActiveLinesMax) {
+  #    $ActiveLinesMax = $yres;
+  #}
 
   for ($i = (Normalize($ActiveLinesMax, 8) * $interlace); $i >= (Normalize($ActiveLinesMin, 16)*$interlace); $i -= 16) {
     $yres = $i;



Is it correct for me to comment out that stuff in the virtualize function, seems like it makes sense from what you said to just check min/max we already calculated too.

Actually this is more correct I guess, put it into the logic I have to avoid interlacing if set to not do it...
Code: [Select]
diff --git a/switchres b/switchres
index 24182ae..35b9cee 100755
--- a/switchres
+++ b/switchres
@@ -1239,9 +1239,9 @@ sub get_modeline($ $ $ @) {
        }
 
        # Pay attention to max ability of interlacing/virtualization
-       if ($YresMax > $Mode[$ModeBase]{'VirtualLinesLimit'}) {
-               $YresMax = $Mode[$ModeBase]{'ActiveLinesLimit'};
-       }
+       #if ($YresMax > $Mode[$ModeBase]{'VirtualLinesLimit'}) {
+       #       $YresMax = $Mode[$ModeBase]{'ActiveLinesLimit'};
+       #}
 
        # Hardwired for now
        $XresMin = 184;
@@ -1314,8 +1314,8 @@ sub get_modeline($ $ $ @) {
                        if ($VERBOSE > 1) {
                                print "Interlacing: $OriginalHeight lines > $Mode[$ModeBase]{'ActiveLinesLimit'} active line limit!!!\n";
                        }
-                       $MODELINE_RESULT |= $INTERLACED;
                        $interlace = 2;
+                       $MODELINE_RESULT |= $INTERLACED;
                        my $line = ResVirtualize($OriginalWidth, $OriginalHeight, $Refresh, $HFreq, $interlace, $Mode[$ModeBase]);
                        if ($line) {
                                ($OriginalWidth, $OriginalHeight, $Refresh, $HFreq) = split(/\s/, $line);
@@ -1326,7 +1326,7 @@ sub get_modeline($ $ $ @) {
                                # Reduce vertical size to allow interlacing
                                $interlace = 2;
                                $MODELINE_RESULT |= $INTERLACED;
-                               $OriginalHeight = $Mode[$ModeBase]{'VirtualLinesLimit'};
+                               #$OriginalHeight = $Mode[$ModeBase]{'VirtualLinesLimit'};
                                if ($VERBOSE > 1) {
                                        print "Reduced: $OriginalHeight lines > $Mode[$ModeBase]{'VirtualLinesLimit'} virtual line limit!!!\n";
                                }
@@ -1592,13 +1592,16 @@ sub ResVirtualize () {
   if ($ActiveLinesMin > $Mode[0]{'YresMin'}) {
        $ActiveLinesMin = $Mode[0]{'YresMin'};
   }
-  # Check user requested maximum interlacing size
-  if (($interlace * $ActiveLinesMax) > $Mode[0]{'VirtualLinesLimit'}) {
-       $ActiveLinesMax = $Mode[0]{'VirtualLinesLimit'} / $interlace;
-  }
-  if ($yres > ($ActiveLinesMin * $interlace) && $yres < $ActiveLinesMax) {
-       $ActiveLinesMax = $yres;
+  if ($ActiveLinesMax > $Mode[0]{'YresMax'}) {
+       $ActiveLinesMax = $Mode[0]{'YresMax'};
   }
+  # Check user requested maximum interlacing size
+  #if (($interlace * $ActiveLinesMax) > $Mode[0]{'VirtualLinesLimit'}) {
+  #    $ActiveLinesMax = $Mode[0]{'VirtualLinesLimit'} / $interlace;
+  #}
+  #if ($yres > ($ActiveLinesMin * $interlace) && $yres < $ActiveLinesMax) {
+  #    $ActiveLinesMax = $yres;
+  #}
 
   for ($i = (Normalize($ActiveLinesMax, 8) * $interlace); $i >= (Normalize($ActiveLinesMin, 16)*$interlace); $i -= 16) {
     $yres = $i;


I also just took this out...

Code: [Select]
@@ -1205,9 +1205,9 @@ sub get_modeline($ $ $ @) {
        my ($XresMin, $YresMin, $YresMax);
 
        # Turn off interlacing if active = virtual lines
-       if ($Mode[$ModeBase]{'ActiveLinesLimit'} >= $Mode[$ModeBase]{'VirtualLinesLimit'}) {
-               $can_interlace = 0;
-       }
+       #if ($Mode[$ModeBase]{'ActiveLinesLimit'} >= $Mode[$ModeBase]{'VirtualLinesLimit'}) {
+       #       $can_interlace = 0;
+       #}
 
        # Get Vertical Blanking
        $Mode[$ModeBase]{'VerticalBlank'} = int((($Mode[$ModeBase]{'VFrontPorch'} * 1000) +



Which now works good, I guess that was a check I was doing which was needed from other issues which are worked out, and now doesn't do anything bad be letting interlace still be possible.  Interesting I can get some huge interlaced resolutions on the d9800 which I never knew it could do, like 1000 something by 900 something seems to work although it's definitely not wonderful being interlaced but the monitor doesn't mind doing it.  


This seems to keep it from virtualizing a game it decided it can't beforehand...
Code: [Select]
        # Check if horizontal frequency is above maximum allowed
        if($HFreq > $Mode[$ModeBase]{'HfreqMax'}) {
-               if ($OriginalHeight > $Mode[$ModeBase]{'ActiveLinesLimit'} && $can_interlace) {
+               if ($OriginalHeight > $Mode[$ModeBase]{'ActiveLinesLimit'} && $USE_INTERLACE && $interlace != 2) {
                        $interlace = 2;
                        my $line = ResVirtualize($OriginalWidth, $OriginalHeight, $Refresh, $HFreq, $interlace, $Mode[$ModeBase]);
                        if ($line) {



Without this it will virtualize when we've already decided to interlace but not virtualize, then it goes and would do it anyways.
« Last Edit: November 18, 2010, 06:04:17 pm by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
« Reply #191 on: November 18, 2010, 06:07:27 pm »
Yeah the vertical padding is sort of guessed and somewhat works but basically it is comparing what the ideal height would be to the final height after all the changes to meet the limitations.  So sometimes it's actually smaller and to use it as a weight still I just reverse the calcuation to see how much less it is than it was supposed to be.  That's another thing that I wasn't fully sure of still, how to get the exact amount of padding and weight it correctly.

I guess the best value to account for vertical padding is that 'margen' variable (btw I didn't use 'margin' in English because it's a reserved in powerbasic), before we divide it by 2, as it measures the number of extra lines (aditional to the normal yres+verticalblank) needed to keep inside our hfreq range, so the bigger this number is, the less suitable this range is for this particular resolution, the wider the resolution will look. So in case we had two valid progressive resolutions produced by adjacent ranges, the one with the smaller vertical padding should be chosen, as I believe your doing know.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
« Reply #192 on: November 18, 2010, 06:10:19 pm »
Yeah the vertical padding is sort of guessed and somewhat works but basically it is comparing what the ideal height would be to the final height after all the changes to meet the limitations.  So sometimes it's actually smaller and to use it as a weight still I just reverse the calcuation to see how much less it is than it was supposed to be.  That's another thing that I wasn't fully sure of still, how to get the exact amount of padding and weight it correctly.

I guess the best value to account for vertical padding is that 'margen' variable (btw I didn't use 'margin' in English because it's a reserved in powerbasic), before we divide it by 2, as it measures the number of extra lines (aditional to the normal yres+verticalblank) needed to keep inside our hfreq range, so the bigger this number is, the less suitable this range is for this particular resolution, the wider the resolution will look. So in case we had two valid progressive resolutions produced by adjacent ranges, the one with the smaller vertical padding should be chosen, as I believe your doing know.

Ah, I see, I should have realized that :) sounds good, that makes a lot of sense.  I'm uploading version 26b in a second, I think it's much better on these interlaced/virtual decisions, with the changes of the diffs I posted in it.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
« Reply #193 on: November 18, 2010, 06:40:03 pm »
This .26b seems to be working ok! I've tested three diferent situations, and they work well with minor issues only.

1942, perfect:

Code: [Select]
Default Mode: 641x480@60
Display line for 1942 is:
  type: raster
  rotate: 270
  width: 256
  height: 224
  refresh: 60.000000

Using mame xml: [1] 1942 raster vertical 344x256@60.000000 1.142857 --> 344x256@60.000000 AR 1.142857

Vertical Refresh: 60.000Hz Actual: 60.001Hz
Using ModeBase: 0 Lines: 277 VBlankLines: 21 Pad: (+0) Margen: 0 VBlank: 0.00128 Hfreq: 16.620Khz Vref: 60.00Hz
Monitor Limits are 184 x 112 minimum and 576 max vertical lines, Active/Virtual (288/448)

# 15.625Khz - 16.670Khz: ( Perfect Resolution )
# [0] - 344x256@60.00 16.620Khz
     Modeline "344x256x60.00" 7.711750 344 360 400 464 256 257 260 277 -HSync -VSync

# 1942 344x256@60.00 16.620Khz
     Modeline "344x256x60.00" 7.711750 344 360 400 464 256 257 260 277 -HSync -VSync
Starting 1942 in mode "344x256" at 60.000000Hz
Executing: 'mame 1942 -nomt -waitvsync -resolution 344x256@60.000000'
Target refresh = 60.000000
mame child exited with value 2
Finished running SwitchRes for 1942 with the mame emulator.

Arch Rivals, now we get proper 512x480 but for some reason hfreq & vfreq are raised:

Code: [Select]
Default Mode: 641x480@60
Display line for archrivl is:
  type: raster
  rotate: 0
  width: 512
  height: 480
  refresh: 30.000000

Using mame xml: [1] archrivl raster horizontal 512x480@30.000000 1.066667 --> 512x480@30.000000 AR 1.066667

Interlacing: 480 lines!!!
Lowered Horizontal frequency 31.195Khz changed to 16.670Khz VRefresh 60.00Hz changed to 63.87Hz
Vertical Refresh: 63.870Hz Actual: 63.870Hz
Using ModeBase: 0 Lines: 261.5 VBlankLines: 21.5 Pad: (+-258.5) Margen: 0 VBlank: 0.00128 Hfreq: 16.702Khz Vref: 63.87Hz
Monitor Limits are 184 x 112 minimum and 576 max vertical lines, Active/Virtual (288/448)

# 15.625Khz - 16.670Khz: ( | Vertical refresh raised | Horizontal frequency lowered | Interlaced | 258.5 lines Vertical padding | )
# [44] - 512x480@31.94 16.705Khz
     Modeline "512x480x63.87" 11.491000 512 536 592 688 480 482 487 523 -HSync -VSync interlace

# archrivl 512x480@31.94 16.705Khz
     Modeline "512x480x63.87" 11.491000 512 536 592 688 480 482 487 523 -HSync -VSync interlace
Starting archrivl in mode "512x480" at 30.000000Hz
Executing: 'mame archrivl -throttle -mt -resolution 512x480@30.000000'
Target refresh = 30.000000
mame child exited with value 2
Finished running SwitchRes for archrivl with the mame emulator.

Twin Cobra, perfect virtualization, only some issues when prompting resulting frequencies and stuff.

Code: [Select]
Default Mode: 641x480@60
Display line for twincobr is:
  type: raster
  rotate: 270
  width: 320
  height: 240
  refresh: 54.877858

Using mame xml: [1] twincobr raster vertical 432x320@54.877858 1.333333 --> 432x320@54.877858 AR 1.333333

Interlacing: 320 lines < 448 virtual line limit!!!
Virtualized resolution to 752x560@54.877858 16.5332498399488Khz
Vertical Refresh: 54.878Hz Actual: 54.879Hz
Using ModeBase: 0 Lines: 301.5 VBlankLines: 21.5 Pad: (+-42.5) Margen: 0 VBlank: 0.00128 Hfreq: 16.546Khz Vref: 54.88Hz
Monitor Limits are 184 x 112 minimum and 576 max vertical lines, Active/Virtual (288/448)

# 15.625Khz - 16.670Khz: ( | Interlaced | Virtualized | 42.5 lines Vertical padding | )
# [25] - 752x560@27.44 16.546Khz
     Modeline "752x560x54.88" 16.546000 752 784 864 1000 560 562 567 603 -HSync -VSync interlace

# twincobr 752x560@27.44 16.546Khz
     Modeline "752x560x54.88" 16.546000 752 784 864 1000 560 562 567 603 -HSync -VSync interlace
Warning: 432x320 != 432x320!!!
Starting twincobr in mode "432x320" at 54.877858Hz
Executing: 'mame twincobr -keepaspect -cleanstretch -nomt -waitvsync -resolution 432x320@54.877858'
Target refresh = 54.877858
mame child exited with value 2
Finished running SwitchRes for twincobr with the mame emulator.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
« Reply #194 on: November 18, 2010, 11:22:11 pm »
This .26b seems to be working ok! I've tested three diferent situations, and they work well with minor issues only.


I have version .26c now and it should fix all those issues, hopefully, and also now uses the margen values properly to calculate the padding correctly.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26d)
« Reply #195 on: November 19, 2010, 04:59:58 am »
Your script is working pretty well now, I'm testing many problematic situations to see how it behaves.

I've found an issue with pacman though:

Code: [Select]
Default Mode: 641x480@60
Display line for pacman is:
  type: raster
  rotate: 90
  width: 288
  height: 224
  refresh: 60.606061
  pixclock: 6144000
  htotal: 384
  hbend: 0
  hbstart: 288
  vtotal: 264
  vbend: 0
  vbstart: 224

Using mame xml: [1] pacman raster vertical 384x288@60.606061 1.285714 --> 384x288@60.606061 AR 1.285714

Monitor Limits: 184x112 min res 576 max yres
Lowered hfreq 18.922Khz to 16.670Khz VRefresh 60.61Hz to 53.95Hz
Modeline Calculation of 60.606Hz 18.909Khz 312 vtotal 24 vblank 0 vpad

# 15.625Khz - 16.670Khz: ( | Horizontal frequency lowered | )
# [1] - 384x288@60.61 18.909Khz
     Modeline "384x288x60.61" 10.135273 384 408 456 536 288 289 292 312 -HSync -VSync

# pacman 384x288@60.61 18.909Khz
     Modeline "384x288x60.61" 10.135273 384 408 456 536 288 289 292 312 -HSync -VSync

Even if it correctly prompts: "Lowered hfreq 18.922Khz to 16.670Khz VRefresh 60.61Hz to 53.95Hz", after that it ends up producing a 18.909Khz resolution.

Also, with Twin Cobra it still propmts Vfreq/2 (it's minor stuff):

# twincobr 752x560@27.44 16.546Khz
     Modeline "752x560x54.88" 16.545675 752 784 864 1000 560 562 567 603 -HSync -VSync interlace

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26d)
« Reply #196 on: November 19, 2010, 05:05:23 am »
Your script is working pretty well now, I'm testing many problematic situations to see how it behaves.

I've found an issue with pacman though:

Code: [Select]
Default Mode: 641x480@60
Display line for pacman is:
  type: raster
  rotate: 90
  width: 288
  height: 224
  refresh: 60.606061
  pixclock: 6144000
  htotal: 384
  hbend: 0
  hbstart: 288
  vtotal: 264
  vbend: 0
  vbstart: 224

Using mame xml: [1] pacman raster vertical 384x288@60.606061 1.285714 --> 384x288@60.606061 AR 1.285714

Monitor Limits: 184x112 min res 576 max yres
Lowered hfreq 18.922Khz to 16.670Khz VRefresh 60.61Hz to 53.95Hz
Modeline Calculation of 60.606Hz 18.909Khz 312 vtotal 24 vblank 0 vpad

# 15.625Khz - 16.670Khz: ( | Horizontal frequency lowered | )
# [1] - 384x288@60.61 18.909Khz
     Modeline "384x288x60.61" 10.135273 384 408 456 536 288 289 292 312 -HSync -VSync

# pacman 384x288@60.61 18.909Khz
     Modeline "384x288x60.61" 10.135273 384 408 456 536 288 289 292 312 -HSync -VSync

Even if it correctly prompts: "Lowered hfreq 18.922Khz to 16.670Khz VRefresh 60.61Hz to 53.95Hz", after that it ends up producing a 18.909Khz resolution.

Also, with Twin Cobra it still propmts Vfreq/2 (it's minor stuff):

# twincobr 752x560@27.44 16.546Khz
     Modeline "752x560x54.88" 16.545675 752 784 864 1000 560 562 567 603 -HSync -VSync interlace



Yeah the pacman issue should be fixed with 27a, I made a bug/mistake and was recalculating an extra time for the refresh and it messed that up.

I'll take a look at Twin Cobra and see if that's fixed or not with this change I made.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .27a)
« Reply #197 on: November 19, 2010, 05:18:37 am »
Code: [Select]
diff --git a/switchres b/switchres
index 6af16d2..cf0f190 100755
--- a/switchres
+++ b/switchres
@@ -1469,7 +1469,7 @@ sub get_modeline($ $ $ @) {
                        '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",
+                       'hfreq' => "$HFreq", 'vfreq' => ($Refresh * $interlace),
                         'result' => "$MODELINE_RESULT", 'vpad' => $margen, 'hpad' => 0,
                        'label' => "$label");
        
@@ -1714,6 +1714,11 @@ sub get_resinfo(@) {
        my $vref = (($Mode[0]{'pclock'}*1000000) / ($Mode[0]{'htotal'} *
                        $Mode[0]{'vtotal'}));
        my $hfreq = $vref * $Mode[0]{'vtotal'};
+       if ($Mode[0]{'interlace'}) {
+               $vref *= 2;
+       } elsif ($Mode[0]{'doublescan'}) {
+               $vref /= 2;
+       }
 
        return "$Mode[0]{'hactive'}x$Mode[0]{'vactive'}\@" .
                sprintf("%.2f", $vref) . " " . sprintf("%.3f", $hfreq/1000) . "Khz";


This patch should make it behave about showing the doublescan and interlaced vertical refresh rates right in the info parts.

Update: Well with this applied right afterwards :)...
Code: [Select]

diff --git a/switchres b/switchres
index cf0f190..5d4953f 100755
--- a/switchres
+++ b/switchres
@@ -1460,7 +1460,7 @@ sub get_modeline($ $ $ @) {
        }
 
        # Total vertical lines
-       $vtotal   = int(($VT * $interlace)+0.5);
+       $vtotal   = ($VT * $interlace);
 
        # Modeline structure
        my $label = sprintf("%.3f", ($Mode[$ModeBase]{'HfreqMin'}/1000)) . "Khz - " .
@@ -1469,7 +1469,7 @@ sub get_modeline($ $ $ @) {
                        '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 * $interlace),
+                       'hfreq' => "$HFreq", 'vfreq' => $Refresh,
                         'result' => "$MODELINE_RESULT", 'vpad' => $margen, 'hpad' => 0,
                        'label' => "$label");


Update:

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
« Last Edit: November 19, 2010, 05:49:29 am by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6891
  • Last login:Today at 05:37:05 pm
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .27a)
« Reply #198 on: November 19, 2010, 06:11:56 am »
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...
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

ves

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 225
  • Last login:April 11, 2020, 02:57:49 am
Re: Switchres arcade monitor modeline generator and mame wrapper (ver .27b)
« Reply #199 on: November 19, 2010, 09:34:31 am »
Hi I leave the links to the kernel image and headers, if the want to try and include in your web.
I hope to have time this weekend to have a beta already live so you can keep trying.

http://www.megaupload.com/?d=KORYJYUD
http://www.megaupload.com/?d=48WAAKYJ


Greetings.