Switchres: modeline generator engine

[bitbytebit]

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

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

Here the settings I put mine.

Grub video = 640x480c

The EDID usually comes from the monitor but an arcade monitor won't send it an EDID.  When you boot up it will only allow the 'video=640x480c' option to work right if you've got the arcade monitor plugged it, it will not work plug-n-play for arcade monitors unfortunately.  The modeline it uses for 640x480 is from Soft15Khz, an interlaced 640x480 so technically I figured it should work on all arcade monitors.  It also has others, try other ones from Soft15Khz and see if other ones work better (like 320x240c pehaps just to see).  Now that I think about it, since it does look at the EDID if there is one and won't use arcade mode, probably best to stick to the video=640x480c format and not use the DVI/VGA addition because it actually isn't really needed because the EDID will tell the kernel (when the EDID doesn't exist) to use the arcade mode.

One possibility is to make the kernel completely use only arcade modes, and maybe change the modelines it uses or put the modeline generator into it to replace CVT.  If it doesn't really work after trying all that above, I can look at doing that.


Also the xorg.conf below should be changed quite a bit actually, I'd take the output of Xorg -config first and add in the option for default modes to it.  Then add in the 1 modeline but not the one below since my example one is actually what I use on my d9800 so it's not going to work on an arcade monitor, that may be the main issue .  Use the 640x480 interlaced modeline from Soft15Khz, which is the same as the one I use in the kernel (but adjust of course the 640 active lines to 641 like I did for the one below).

The AVGA patch mainly just removed that check for the ATI magine, comment out the code that has the

printk(KERN_INFO "Invalid ATI magic.\n");

and that little if {} statement section basically, without that the AVGA should allow loading but the 3000 version will not look good unfortunately.

/etc/modprobe.d/radeon.conf

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

Xorg.conf

Code: [Select]

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

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

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

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

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

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

Option "DPMS" "false"

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

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

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

Option "DPMS" "true"
EndSection

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

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

Option     "ModeDebug"      "true"

Option      "ForceMinDotClock"    "3"

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

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

Option     "EnablePageFlip" "on"

Option     "ModeDebug"      "true"

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

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

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

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

EndSection



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

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


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




Greetings.

[dmarcum99]

I wanted to say that I am excited to see the development of a new modeline generator!  A lot of us are using special video monitors to achieve the native resolutions.

I am a little confused, so please pardon my lack of knowledge.  I see that bitbytebit has a couple of programs to download and Calamity has been involved and also has a program.  So my confusion is which program to use and how to execute the program(s) in my situation.

I am using a NEC XM-29 monitor, Windows XP 32-bit, and mameui (0.140).  My video card is an ATI X850.  I am using Soft15Khz to get some custom resolutions, but not all resolutions are a great fit.  The way I'm understanding, you guys have found a way to get modelines created that will get the games in their native res and intended refresh rate without resorting to drudging through advancemame?.  I tried for months without much luck, only getting a couple of resoutions created.

I read the whole thread for info, but when I hear talk about linux and other the technical stuff, I get overwhelmed.  If you guys could give a small description on what which program I need to use and how to use it, I would be very grateful.  I'm sure there are others with multi-synchs lurking this thread for the outcome as well.

[bitbytebit]

I wanted to say that I am excited to see the development of a new modeline generator!  A lot of us are using special video monitors to achieve the native resolutions.

I am a little confused, so please pardon my lack of knowledge.  I see that bitbytebit has a couple of programs to download and Calamity has been involved and also has a program.  So my confusion is which program to use and how to execut the program(s) in my situation.

I am using a NEC XM-29 monitor, Windows XP 32-bit, and mameui (0.140).  My video card is an ATI X850.  I am using Soft15Khz to get some custom resolutions, but not all resolutions are a great fit.  The way I'm understanding, you guys have found a way to get modelines created that will get the games in their native res and intended refresh rate without resorting to drudging through advancemame?.  I tried for months without much luck, only getting a couple of resoutions created.

I read the whole thread for info, but when I hear talk about linux and other the technical stuff, I get overwhelmed.  If you guys could give a small description on what which program I need to use and how to use it, I would be very grateful.  I'm sure there are others with multi-synchs lurking this thread for the outcome as well.

For simple modeline generation, basically you can run switchres and use arguments to it for the height width refresh that you want, like 'switchres.exe 640 480 60.00', also there are possible command line args for monitor type (d9800 might match yours closest I think, or the d9200 if it's not a continuous frequency range).  I see your monitor is even more capable, 15-50 Khz / 40-100 Hz ranges.  So you should be able to generate modelines using the command 'switchres.exe --monitor d9800 <width> <height> <refreshrate>' pretty easily.  Also with a mame.exe in your windows path, it uses that for XML output, should allow using '--calc <rom>' to get the specific games perfect resolution.

I attached a current version of the C compiled, in this .zip there's a SwitchResC.7z file and that contains the switchres.exe and .dll files too needed to run under Windows (shouldn't need Cygwin or Perl with this version now).  Let me know if it works, I just got this working where it should be easier to use under Windows now.  It may say some warnings about the config file path but you really don't need a config file to generate modelines.  Also if you want to see all the options, 'switchres -h' and notice the --nointerlace --nodoublescan which might be necessary under Windows I'm guessing for the radeon drivers, at least the doublescan one I'm pretty sure is necessary because under Windows that doesn't work I think.

I'm current trying to get this C version working under Windows as easily as possible to avoid needing the Perl program installed, reducing all the dependencies I can, so your help in testing this for your monitor would be great help to see how it works for that.  There are some extra tweaking of monitor settings for Horizontal and Vertical frontporch/syncpulse/backporch settings (do you know those for your monitor?)  That may improve things more, though the d9800 ones might just work fine too, I think they will.


Calamity:  Also try this version too, hopefully runs without needing Cygwin now as long as you have a mame.exe in the Windows PATH.  I'm not sure if the config file will work, suspecting it will under C:\\windows\etc\switchres.conf unless somehow the cygwin stuff doesn't like it.

[bitbytebit]

Quick update to the last C version posted which removes the Cygwin warning about paths, and the config file will work either way so Monitor specs can be entered there if needing custom ranges.  Seems to overall work pretty well in Windows generating modelines and hopefully works same without cygwin installed and just the .dll files and the switchres.exe in the .7z archive.

[dmarcum99]

Wow...this was pretty painless!!  I put a mame.exe in my c:\windows directory and copied all the files from the switchres download to the same location.  I used the command prompt to run the program.  I first ran the program using the --calc dkong switches and then I used the --monitor d9800 --calc dkong switches.  Listed below is the output:

C:\WINDOWS>switchres --calc dkong
[dkong] on  Monitor 344x256@60.606 Resolution 1.332 Aspect

# [11] 344x256@56.88 15.7000Khz
     "344x256x56.88" 7.033600 344 360 392 448 256 257 260 276 -HSync -VSync

C:\WINDOWS>switchres --monitor d9800 --calc dkong
[dkong] on d9800 Monitor 344x256@60.606 Resolution 1.332 Aspect

#

• 344x256@60.61 16.9697Khz

     "344x256x60.61" 7.738181 344 360 400 456 256 259 262 280 -HSync -VSync

Now...I am work (remoted in to my pc) and actually can't test the monitor for the actual display, but this looks very promising.  As long as Soft15Khz accepts these I'll be stoked.  In the past, I tried using the online modeline generators and soft 15Khz would not accept some of them so it made it difficult to execute.

You mentioned that I could customize this software to my monitor if I had the BP, FP, & SP.  The only info I have is the following:  Retrace time: horiz-4.2usec  vert-0.55msec  I don't have the monitor manual, so how would I obtain this info?  Would I be able to get it from something like Powerstrip?

[bitbytebit]

Wow...this was pretty painless!!  I put a mame.exe in my c:\windows directory and copied all the files from the switchres download to the same location.  I used the command prompt to run the program.  I first ran the program using the --calc dkong switches and then I used the --monitor d9800 --calc dkong switches.  Listed below is the output:

C:\WINDOWS>switchres --calc dkong
[dkong] on  Monitor 344x256@60.606 Resolution 1.332 Aspect

# [11] 344x256@56.88 15.7000Khz
     "344x256x56.88" 7.033600 344 360 392 448 256 257 260 276 -HSync -VSync

C:\WINDOWS>switchres --monitor d9800 --calc dkong
[dkong] on d9800 Monitor 344x256@60.606 Resolution 1.332 Aspect

#

• 344x256@60.61 16.9697Khz

     "344x256x60.61" 7.738181 344 360 400 456 256 259 262 280 -HSync -VSync

Now...I am work (remoted in to my pc) and actually can't test the monitor for the actual display, but this looks very promising.  As long as Soft15Khz accepts these I'll be stoked.  In the past, I tried using the online modeline generators and soft 15Khz would not accept some of them so it made it difficult to execute.

You mentioned that I could customize this software to my monitor if I had the BP, FP, & SP.  The only info I have is the following:  Retrace time: horiz-4.2usec  vert-0.55msec  I don't have the monitor manual, so how would I obtain this info?  Would I be able to get it from something like Powerstrip?

Sounds great, interested in hearing how that resolution works.  The values are probably ok that the d9800 uses for that monitor, Calamity have better insight about that than me though.  I think those values are possibly the sync pulse, again Calamity probably knows what they are.  I suspect the monitor has different ones for certain ranges, like the d9800 does, so hopefully those work for it because otherwise might have to do some hunting around or if not found experimenting with what keeps things properly centered for the whole range it supports.

[Calamity]

I am a little confused, so please pardon my lack of knowledge.  I see that bitbytebit has a couple of programs to download and Calamity has been involved and also has a program.  So my confusion is which program to use and how to execute the program(s) in my situation.

I'll try to sumarize... We're testing Switchres that is the evolution of Genres, a perl script written by bitbytebit, now being ported into C, useful for extracting xml info from Mame and producing modelines for each game, dynamically. Originally was focused on Linux but now also works for Windows. Linux and Windows have different limitations that prevent us from achieving dynamic arcade modelines. Until now, much of this thread has been about bitbytebit's efforts to patch Linux so it will accept dynamic modelines for arcade monitors. In Windows it's another story, although I believe I have the key to do dynamic modelines at least for older ATIs, using a patched version of Catalyst drivers I'm working on (CRT_Emudriver). So eventually we might get Switchres to link to those so we might have dynamic modelines also in Windows (btw, by dynamic I mean no need to restart the system). I happened to be developing a similar tool programmed in powerbasic to get Mame xml and produce modelines for Windows to use together with my patched drivers, so he's ported my modeline calculating functions into Switchres project C code, and we've figured out multisync monitor support. So if yours is a multisync monitor, try Switchres, that is the one we'll be testing here. On the other hand, my project doesn't do dynamic modelines nor multisync yet, it works with a precalculated list of modelines, although it does a pretty good job compared to any of the existing solutions, apart from Switchres, is designed to be used in conjunction with my patched drivers, only for the cards supported (Switchres is more general purpose aimed), has its own thread in this forum (Spanish):

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

You mentioned that I could customize this software to my monitor if I had the BP, FP, & SP.  The only info I have is the following:  Retrace time: horiz-4.2usec  vert-0.55msec  I don't have the monitor manual, so how would I obtain this info?  Would I be able to get it from something like Powerstrip?

If it's multisync it will probably have different values for each range, being that data possiby the lower values of all (SVGA?). As they state retrace time I'm not sure if they mean the whole blanking (with porches) or just the retrace length (sync pulse + some delay). We can try those D9800 values and see if they more or less work.

[bitbytebit]

Calamity, in windows should I enable waitvsync, and should I enable syncrefresh?  I'm getting all the command line stuff working in Windows and now it can run the games fine in windows plus chose things like either cleanstretch or unevenstretch or hwstretch depending on if it's windows or linux and if mame is patched or not for things.  I'm actually going to probably check mame itself for these patches, may help ease things for the  user, but the one I can't check is the frogger hack but will just have my patch enable an option for it so I can at least try and check for that.

So basically this waitvsync vs. syncrefresh thing in windows seems like they are essentially the same option and I don't see a difference, which should I do or both when they aren't throttling ?

Also I've gotten switchres mostly up to par with the perl version now, I've got just about every command line option (and more) plus writing out to a modes file now and only missing feature is reading in the Soft15Khz preset resolution files to use as guides.  That and I want to read the mame config setup to be able to know what they are running and what options we can set, and possibly fixup the ones that are set wrong if we really want to run on an arcade monitor to optimal capacity for that game (like force unevenstretch off when not needed etc).  Possibly allow of course the .ini files to override us too in the future, so it will also have a sort of 'intelligent' feature to help run mame without all the hassle people have to go through to make sure every config file option is setup for the type of game it is and if it needs stretching/keepaspect/throttle/ etc.

I'll get another C version posted probably later tonight and hopefully if I can get the Soft15Khz support into it I'm going to kill the Perl version and this will be the main version.  Some of the command line options slightly changed, so good to move on now, I've made it able to run different emulators and allow different mame binaries and all that kind of thing now so it's able to do that stuff and much better than the perl version did.

Here's the options right now to give an idea, most are settable in the config file again and of course if they say -no*** something here in the config it's without the -no part and a boolean 1 or 0 option...


SwitchRes version v1.00 r54M [b268eb2] by Chris Kennedy (C) 2010
Ported from code by Calamity to calculate modelines.

Build Date:   Mon Nov 22 17:06:18 CST 2010
Compiler:     GCC 4.4.5
Build System: x86_64 unknown unknown GNU/Linux

Usage: switchres <gamerom>
Usage: switchres <system> --emulator mess --rom <rom> --args <mess cmdline>
Usage: switchres <width> <height> <refresh>
Usage: switchres --calc <gamerom>

  --calc                          Calculate modeline and exit
  --monitor  <type>         Type of monitor [cga ega vga multi ntsc pal h9110 d9200 d9800]
  --mrange <settings>     Use custom monitor range, can have multiple ones
  --ymin <height>            Minimum height to use
  --vectorwidth <width>   Default width to use on Vector games (640)
  --vectorheight <height> Default height to use on Vector games (480)
  --nodoublescan            Video card can't doublescan
  --nointerlace                Video card can't interlace
  --throttle                      Can't sync to refresh rate, use throttle in mame
  --novsync                    Weight for x/y instead of vertical refresh
  --ff                              Frogger/Galaxian Hack is in mame executable
  --redraw                      Redraw Hack is in mame executable
  --cleanstretch              Cleanstretch Hack is in mame executable
  --modesfile <file>        Write out modelines to a file for Soft15Khz

Options for other emulators besides MAME:
  --emulator <exe>         Emulator to run, default is mame
  --xrandr                       Use this if the emulator doesn't switch resolutions
  --args <...>                 Extra command line args to send to emulator
  --rom <file>                 ROM file, normal <gamerom> becomes system type

[Calamity]

I'm testing the 1.00h version now and it works really really well, no issues yet with any game I've tried:

C:\Emuladores\Mame v0.131>switchres --calc 1942 --monitor h9110
[1942] on h9110 Monitor 344x256@60.000 Resolution 1.332 Aspect

#

• 344x256@60.00 16.6200Khz

     "344x256x60.00" 7.711680 344 360 400 464 256 257 260 277 -HSync -VSync

C:\Emuladores\Mame v0.131>switchres --calc loht --monitor h9110
[loht] on h9110 Monitor 384x256@55.018 Resolution 1.500 Aspect

# [3] 384x256@55.02 15.6250Khz
     "384x256x55.02" 7.875000 384 400 440 504 256 261 264 284 -HSync -VSync

C:\Emuladores\Mame v0.131>switchres --calc twincobr --monitor h9110
[twincobr] on h9110 Monitor 432x320@54.878 Resolution 1.331 Aspect

# [15] 752x560@54.88 16.5457Khz
     "752x560x54.88" 16.545674 752 784 864 1000 560 562 568 603 -HSync -VSync interlace

C:\Emuladores\Mame v0.131>switchres --calc sfa3 --monitor h9110
[sfa3] on h9110 Monitor 384x224@59.629 Resolution 1.714 Aspect

# [4] 384x224@59.63 15.6825Khz
     "384x224x59.63" 7.903996 384 400 440 504 224 235 238 263 -HSync -VSync

C:\Emuladores\Mame v0.131>switchres --calc archrivl --monitor h9110
[archrivl] on h9110 Monitor 512x480@30.000 Resolution 1.067 Aspect

# [16] 512x480@60.00 15.6300Khz
     "512x480x60.00" 10.503360 512 536 584 672 480 482 488 521 -HSync -VSync interlace

C:\Emuladores\Mame v0.131>switchres --calc pacman --monitor h9110
[pacman] on h9110 Monitor 384x288@60.606 Resolution 1.333 Aspect

# [11] 384x288@53.95 16.6700Khz
     "384x288x53.95" 8.535040 384 400 440 512 288 289 292 309 -HSync -VSync

C:\Emuladores\Mame v0.131>switchres --calc goldnaxe --monitor h9110
[goldnaxe] on h9110 Monitor 320x224@60.054 Resolution 1.429 Aspect

# [4] 320x224@60.05 15.6742Khz
     "320x224x60.05" 6.645857 320 336 368 424 224 234 237 261 -HSync -VSync

C:\Emuladores\Mame v0.131>switchres --calc rtype --monitor h9110
[rtype] on h9110 Monitor 384x256@55.018 Resolution 1.500 Aspect

# [3] 384x256@55.02 15.6250Khz
     "384x256x55.02" 7.875000 384 400 440 504 256 261 264 284 -HSync -VSync

C:\Emuladores\Mame v0.131>switchres --calc mk --monitor h9110
[mk] on h9110 Monitor 400x256@27.408 Resolution 1.577 Aspect

# [13] 400x256@54.82 15.6771Khz
     "400x256x54.82" 8.152112 400 416 456 520 256 262 265 286 -HSync -VSync

C:\Emuladores\Mame v0.131>switchres --calc contra --monitor h9110
[contra] on h9110 Monitor 376x280@60.000 Resolution 1.332 Aspect

# [11] 376x280@55.38 16.6700Khz
     "376x280x55.38" 8.401680 376 392 432 504 280 281 284 301 -HSync -VSync

[Calamity]

This is getting really interesting, with those functionality added this could be a perfect app...

Calamity, in windows should I enable waitvsync, and should I enable syncrefresh?  I'm getting all the command line stuff working in Windows and now it can run the games fine in windows plus chose things like either cleanstretch or unevenstretch or hwstretch depending on if it's windows or linux and if mame is patched or not for things.  I'm actually going to probably check mame itself for these patches, may help ease things for the  user, but the one I can't check is the frogger hack but will just have my patch enable an option for it so I can at least try and check for that.

So basically this waitvsync vs. syncrefresh thing in windows seems like they are essentially the same option and I don't see a difference, which should I do or both when they aren't throttling ?

Well this is an important thing. Syncrefresh is the one I've always used, as it claims to do what we are looking for: throttle only to the monitor's refresh. However, now I use it combined with triplebuffer, as I believe this buffering does not waste as much cpu time as just waiting for retrace.

The problem is that if we can't get the exact refresh we will have sound issues. I would disable triplebuffer + syncrefresh in case our refresh was, say 0.2 Hz off. This will cause tearing for these games, however. I would add an option to specify Cabmame, or at least the SoundSync patch, so in case it was there we could be using triplebuffer + syncrefresh all the time, as the soundsync patch will make the sound catch the video.



I used to have a bad concept of triplebuffer as it's claimed to increment input lag (this is another world), so I had been using syncrefresh all the time. However, after reading and thinking about it, I believe it's the same lag that must exist with normal syncrefresh, with the advantage that triplebuffer seems to save system resources.

[bitbytebit]

Have uploaded the C version 1.00i which now replaces the Perl version.  All features should now be in the C version that were in the Perl version and should work better than they did in the Perl version from reworking them quite a bit when porting them to C.  I think the Windows support for running games with command line options tuned to what works best and with Soft15Khz modeline files or ArcadeVGA ones should be better too, running games with it using those files and writing out a modes file to push back into Soft15Khz should work.  Check the README file, look at the -h output for information on the command line options which some have changed.  Should be able to run any emulator and using mess for the resolution information and other command line args get good resolutions chosen for them.  Lots of things to test, I think the basic framework and functionality is there though and seems to work pretty good/better compared to the Perl version in my testing so far. 

[Calamity]

I'm testing 1.00i, seems to be invoking Mame perfectly, and I'm glad to see that soundsync option too. It would be great to figure out how to invoke stuff (execute, read/write files) from our current path in Windows, as it's a highly trivial stuff from Windows point of view, and we would avoid the need of placing Mame in Windows directory.

Just some comments when passing our resolution to Mame in Windows, it should have its refresh coverted to an integer label, the same that should be used to store that modeline in the system registry, and will be used to identify that mode in Windows internally. We should also check for Mame version, as this Width x Height @ Refresh format is only used since v.107 version, before that 'resolution' and 'refresh' are passed as separate parameters (I don't know if you're already checking this, but just in case).

[ves]

Hi, I comment the evidence.
With AVGA or ati 9250 with DVI output (VGA adapter setting) not all display no video (no bios, no boot etc. ..) Calamity to you works out dvi vga adapter on the monitor?

With kernel patch arcade, and card or ati 9250 AVGA not get it to work at all, when you load the drm will not display the image and load the game or anything, but if you connect a pc monitor says that is out of sync but after load the game and I can play, can be through a bad patch the kernel?

With normal ubuntu kernel 6.2.35-22-generic, with AVGA and arcade monitor I could see the console after loading the drm, and I load the games but with a wrong resolution, leaving the game in the middle of the screen without adjustment.
With this kernel I've tried to change the parameters of the video = 640x480c 320x220c grub 800x600c etc. .. and whenever I have the same resolution on the console, is much higher than that begins to load (you know that resolution used at the beginning because after the kernel or can not put a better one?)

To say that these tests are not the xorg.conf, and I created a few new and I fail to xkbcomp (can not remember the exact name), I have to configure it better to avoid mistakes, so I guess that the problem of resolutions in the game is normal.


You think of any more proof or do?

For with the normal kernel if I show the terminal when loading the DRM and the patching it?

In the latest version has included the patch for the kernel you did yesterday for the AVGA?

You could say that supports video = parameter in grub? and the radeon.conf? or where to see them?

also comment that when you load the game in the arcade monitor with kernel 2.6.35-22 is very slow which does not happen with pc monitor because it can be?


That graphics card use bitbytebit?



Thanks.

[bitbytebit]

Hi, I comment the evidence.
With AVGA or ati 9250 with DVI output (VGA adapter setting) not all display no video (no bios, no boot etc. ..) Calamity to you works out dvi vga adapter on the monitor?

With kernel patch arcade, and card or ati 9250 AVGA not get it to work at all, when you load the drm will not display the image and load the game or anything, but if you connect a pc monitor says that is out of sync but after load the game and I can play, can be through a bad patch the kernel?

With normal ubuntu kernel 6.2.35-22-generic, with AVGA and arcade monitor I could see the console after loading the drm, and I load the games but with a wrong resolution, leaving the game in the middle of the screen without adjustment.
With this kernel I've tried to change the parameters of the video = 640x480c 320x220c grub 800x600c etc. .. and whenever I have the same resolution on the console, is much higher than that begins to load (you know that resolution used at the beginning because after the kernel or can not put a better one?)

To say that these tests are not the xorg.conf, and I created a few new and I fail to xkbcomp (can not remember the exact name), I have to configure it better to avoid mistakes, so I guess that the problem of resolutions in the game is normal.


You think of any more proof or do?

For with the normal kernel if I show the terminal when loading the DRM and the patching it?

In the latest version has included the patch for the kernel you did yesterday for the AVGA?

You could say that supports video = parameter in grub? and the radeon.conf? or where to see them?

also comment that when you load the game in the arcade monitor with kernel 2.6.35-22 is very slow which does not happen with pc monitor because it can be?


That graphics card use bitbytebit?



Thanks.

So the older AVGA cards don't work with the KMS enabled either?  I suspected that, I really doubt they will because KMS works directly with the ATI Atom bios and just doesn't look like it'll be possible unless someone from ATI wanted to get them to work.  I don't include that patch in my main one because I really doubt it'll ever work, unfortunately the AVGA really is only a mediocre card under windows and actually a bit less under Linux, unless you flash the bios then it's a normal radeon under both (I haven't reflashed mine to check under the KMS stuff but at least under Windows it worked great with Soft15Khz and newest ATI drivers for me after flashing it, before that it was painful like others report). 

The radeon.conf is needed under /etc/modprobe.d/ and might have to run some modprobe create command I think when changing those?  It turns off polling so things aren't slow with an arcade monitor, because polling eats up a ton of resources (and also the newer 2.6.37-rc1 kernel is necessary to yet another polling issue they fixed right after 2.6.36, could be the slowness you've seen in the default ubuntu kernel?).

The /boot/grub/grub.cfg file might be constructed dynamically too, from stuff in /etc/grub.d and definitely it's all basically needed at bootup to be setup with the arcade monitor and that video=640x480c line in there and monitors plugged in to the places they will be, since there's no way for the kernel to change a framebuffer once it boots and it has to decide right at boot which monitors are arcade monitors.

The xorg.conf Default modes setting and the kernel command line definitely have to work together to boot into a graphical boot, both must be done and active, can you boot to a console only and see that on an arcade monitor, test that way and then construct the xorg.conf start up, see what the output of xrandr -q  is?  If you get that far on an arcade monitor and that works, then I'd be interested in the output of 'xrandr -q' and xrandr -q --verbose too.  That might help see what is going on, and if there's modes still lingering in there.  Also running switchres with -v -v -v -v -v mode to be really verbose too, and see that output. 

Seeing the combined logs/output of switchres execution (try the newest C version too, better verbose output most likely), and xrandr -q --verbose output, would probably help me try and figure something out.  Also might need to update xrandr to the newest from git, that is another possibility (and I can't say for sure but maybe it really needs the newest X Windows from GIT, might be they really made things better in the last few months since the Ubuntu version pull of X Windows).

[Calamity]

Hi, I comment the evidence.
With AVGA or ati 9250 with DVI output (VGA adapter setting) not all display no video (no bios, no boot etc. ..) Calamity to you works out dvi vga adapter on the monitor?

Hi VeS, I don't know why in the world you're using the DVI instead of VGA for testing. Please send an email to me so we can speak as I can't understand your previous post (google translator?).

[bitbytebit]

I'm testing 1.00i, seems to be invoking Mame perfectly, and I'm glad to see that soundsync option too. It would be great to figure out how to invoke stuff (execute, read/write files) from our current path in Windows, as it's a highly trivial stuff from Windows point of view, and we would avoid the need of placing Mame in Windows directory.

Just some comments when passing our resolution to Mame in Windows, it should have its refresh coverted to an integer label, the same that should be used to store that modeline in the system registry, and will be used to identify that mode in Windows internally. We should also check for Mame version, as this Width x Height @ Refresh format is only used since v.107 version, before that 'resolution' and 'refresh' are passed as separate parameters (I don't know if you're already checking this, but just in case).

Yeah sounds like the mame -showusage output will be needed for the version checking too, figured it was probably necessary, interesting how older mame did that different.

The local directory stuff is probably possible by me just altering the PATH environment variable in the switchres program itself to include the current working directory before executing the mame program, usually in Unix the current working directory isn't included and in cygwin it takes the Windows PATH environment variable and converts it to Unix style paths.  So the current working directory wouldn't be in that PATH setting and I'll need to add it I'm guessing to make that work.  File writing/reading though should work fine to the current working directory when no path is specified, it'll just write/read where ever switchres was executed from, at least should and is the behavior under Linux.

Ah, I'll have to convert those refresh values to integers, probably best for both Linux and Windows since mame doesn't read them as doubles anywhere and my patch really doesn't matter because it doesn't even use refresh rate in SDL mode to modeswitch.  Since it's just a label in a sense I'm guessing it doesn't matter if I round them or not?  Is that limitation there too where since they are decimal in Windows we really have to dynamically add them this way else the 60.61 vs. 60 Hz resolution with the same width/height would not be able to exist for Windows at the same time?

[Calamity]

Ah, I'll have to convert those refresh values to integers, probably best for both Linux and Windows since mame doesn't read them as doubles anywhere and my patch really doesn't matter because it doesn't even use refresh rate in SDL mode to modeswitch.  Since it's just a label in a sense I'm guessing it doesn't matter if I round them or not?  Is that limitation there too where since they are decimal in Windows we really have to dynamically add them this way else the 60.61 vs. 60 Hz resolution with the same width/height would not be able to exist for Windows at the same time?

Yes, that's our limitation, if we want to have those two resolutions at the same time, one should be labelled as 60 and the other one as 61. As it's just a label, Mame doesn't care if it's 60, 61 or whatever, it will just switch to the resolution addressed by our label.

(However, in order to achieve dynamic resolutions in Windows, eventually, we might want to label all resolutions as 60Hz, to reduce the resulting list of modes, as we will be able to tune any of them to our desired refresh just before running Mame, because I haven't been able to add new modes dynamically, just modify the existing ones.)

[bitbytebit]

Ah, I'll have to convert those refresh values to integers, probably best for both Linux and Windows since mame doesn't read them as doubles anywhere and my patch really doesn't matter because it doesn't even use refresh rate in SDL mode to modeswitch.  Since it's just a label in a sense I'm guessing it doesn't matter if I round them or not?  Is that limitation there too where since they are decimal in Windows we really have to dynamically add them this way else the 60.61 vs. 60 Hz resolution with the same width/height would not be able to exist for Windows at the same time?

Yes, that's our limitation, if we want to have those two resolutions at the same time, one should be labelled as 60 and the other one as 61. As it's just a label, Mame doesn't care if it's 60, 61 or whatever, it will just switch to the resolution addressed by our label.

(However, in order to achieve dynamic resolutions in Windows, eventually, we might want to label all resolutions as 60Hz, to reduce the resulting list of modes, as we will be able to tune any of them to our desired refresh just before running Mame, because I haven't been able to add new modes dynamically, just modify the existing ones.)

Interesting, so in Windows how does one access the existing modelines, because using that access to get the list of possible ones to choose from would be way better than a file list which I'm suspecting is always going to be slightly off of what they actually are (like the arcadeVGA list, would be nice to just get it from the registry directly).  I'm guessing possibly an external program native to windows may need to be called to grab this information, since I doubt inside of cygwin programs we'd be able to use any API from Windows that does this.  If I knew the registry keys and locations/format it stores that stuff in at least would give me a direction to look/go to try and read the current modes we have to choose from.

[Calamity]

Interesting, so in Windows how does one access the existing modelines, because using that access to get the list of possible ones to choose from would be way better than a file list which I'm suspecting is always going to be slightly off of what they actually are (like the arcadeVGA list, would be nice to just get it from the registry directly).  I'm guessing possibly an external program native to windows may need to be called to grab this information, since I doubt inside of cygwin programs we'd be able to use any API from Windows that does this.  If I knew the registry keys and locations/format it stores that stuff in at least would give me a direction to look/go to try and read the current modes we have to choose from.

Yeeeeees that has been the main problem with all Windows programs trying to select resolutions for Mame: they didn't have a way to know the actual vertical refresh of the modes.

Fortunately I have already coded all the functions needed for accessing the registry to read/write that information (only for Catalyst) as Winmodelines or Soft15KHz do, so it can be a matter of porting it to C. My VideoModeMaker app already stores the modes in the registry, so you can rip the needed stuff. However my Arcade_OSD app source would be better for this as it has implemented all the state of art dynamic modelines stuff, I'll pass it to you.

However, one should always check the registry list of modelines against the actual list of available video modes returned by the system.

[dmarcum99]

Hey Guys!

I'd thought I'd share some of my experiences last night using my NEC XM29 monitor.  For the most part, I had a good experience with the software.  My testing was only limited to 5-6 games, but most of the games I played had the resolution/refresh rate locked in.  The best part was when I fired up Mortal Kombat (without triple buffer) and I didn't have any tearing!  That was awesome!  The sound had a couple of hitches however as it would only run at 97% using switchres.  I have a 3.2ghz quad core so I'm not sure how this would be resolved.  I'm using the command line mame and not cabmame...and do not have any other diffs installed other than hi-score and nag screen.

Earlier when I posted my screen output on donkey kong, it showed a resolution of 344X256.  This appeared a little strange because if I used mame by itself, it would load DK with 224x256 but at 60hz.  Why did switchres choose 344 x 256 for dk?  There was a difference as the 344x256 seemed to be squished a little.  Pacman was spot-on when it loaded @ 224x288.

I switched out my X850 for my ATI9200SE (PCI) and got the same results.

Should I be running cabmame or mame?  Do these need any of the special diff's that are in the downloads?  Just wondering to make sure I'm running things like intended.

Oh yeah, I also have Hyperspin as a front end.  How can I use this program with Hyperspin?

**edit**  If I wanted to try different monitor settings like you guys have defaults for the d9200-d9800, etc, how would I go about plugging them in your program?

[Calamity]

Hi dmarcum99,

Before anything, make sure you're actually using the modelines, you need to make them available first by introducing them via Soft15Khz custom list or something.
DK resolution is correct, bear in mind it's actually a rotated resolution, not the actual one.

[bitbytebit]

Hey Guys!

I'd thought I'd share some of my experiences last night using my NEC XM29 monitor.  For the most part, I had a good experience with the software.  My testing was only limited to 5-6 games, but most of the games I played had the resolution/refresh rate locked in.  The best part was when I fired up Mortal Kombat (without triple buffer) and I didn't have any tearing!  That was awesome!  The sound had a couple of hitches however as it would only run at 97% using switchres.  I have a 3.2ghz quad core so I'm not sure how this would be resolved.  I'm using the command line mame and not cabmame...and do not have any other diffs installed other than hi-score and nag screen.

Earlier when I posted my screen output on donkey kong, it showed a resolution of 344X256.  This appeared a little strange because if I used mame by itself, it would load DK with 224x256 but at 60hz.  Why did switchres choose 344 x 256 for dk?  There was a difference as the 344x256 seemed to be squished a little.  Pacman was spot-on when it loaded @ 224x288.

I switched out my X850 for my ATI9200SE (PCI) and got the same results.

Should I be running cabmame or mame?  Do these need any of the special diff's that are in the downloads?  Just wondering to make sure I'm running things like intended.

Oh yeah, I also have Hyperspin as a front end.  How can I use this program with Hyperspin?

**edit**  If I wanted to try different monitor settings like you guys have defaults for the d9200-d9800, etc, how would I go about plugging them in your program?

I personally like cabmame in windows, and it has changes that might help the sound issue but overall are just good and some of those are in my patche to mame but it's aimed at Linux mostly since the cabmame does good in Windows (there's other stuff in cabmame which either is impossible to port to Linux SDL or not really necessary there).

If you wrap mame with switchres (newest version is best if you do this, just added new options) then you can turn on these hacks through that and it will utilize them somewhat by enabling/disabling them as needed (like when to throttle or not, sync with vrefresh or not, tries to make the best decisions so you don't have to have a one size fits all command line or config file for mame).  Basically the redraw/cleanstretch/froggerfix/soundsync hack enabled options are all very good and can fix issues and might help.

Also newest switchres allows you to run it and write out to a file the modelines as you play, then you can take those and setup in Soft15Khz as usermodes.txt, reboot and then point the command line of switchres to all the Soft15Khz files you use and it'll decide which resolution is the best match (and use the custom ones you created that way for sure by forcing them on the command line).

Calamity is right about checking to make sure it's really using the right resolution, it may be picking another unless loading into Soft15khz and forced on the command line of mame to point to that exact one (and still if there's another matching in Soft15Khz already it may override that actually).  Of course that's the part we have not done yet, figuring out that whole issue of the tricky nature of Windows modeline setup and actually getting these to be available instantly and really have mame choose the one we want it to. 

[Calamity]

I'll post here some of the questions that VeS and I are discussing by mail, some of them may have been answered before, sorry if so...
Why can't we see the console nor the games with patched kernel while we can with regular one?
Is there any other param we shoud try to tweak in grub's video line or radeon.conf?
Do you mean that older ATIs (not addressable by AtomBios) may not work at all with this project? (this is an important one as I believe there are thousands of cabs built on Radeon 9200/9250 cards).

[bitbytebit]

I'll post here some of the questions that VeS and I are discussing by mail, some of them may have been answered before, sorry if so...
Why can't we see the console nor the games with patched kernel while we can with regular one?
Is there any other param we shoud try to tweak in grub's video line or radeon.conf?
Do you mean that older ATIs (not addressable by AtomBios) may not work at all with this project? (this is an important one as I believe there are thousands of cabs built on Radeon 9200/9250 cards).

If it's not showing up with the patched kernel, that is quite odd.  Possibly seeing the Xorg log, dmesg output and bootup log, and output of xrandr -q (if no console, login through ssh and run 'xrandr -display :0.0 -q' to get the output).  Those would tell me what is going on most likely.

Those should be enough, just that video line and the polling being off in radeon.conf.

I think when the kernel isn't patched, it may use some default modelines and work decent with those, there is a custom modeline hopefully setup correctly for that output to the arcade monitor?  With the patch and defaultmodes turned off in xorg.conf, you have to have one modeline or else there's nothing to use for X.

I think the older ATI cards are actually fine with KMS too, it's all the same now in the DRM layer from what I can tell and they should work the same.  It's only the special/different AVGA Bios that when in KMS mode and truly running the ATOM bios which it never did before in the radeon X driver without KMS (basically they moved it all into the kernel and now have real access to the ATOM Bios), seems the AVGA bios doesn't act the same when truly running it and seems to have the clocks all out of wack from what they should be.

[bitbytebit]

I'm testing 1.00i, seems to be invoking Mame perfectly, and I'm glad to see that soundsync option too. It would be great to figure out how to invoke stuff (execute, read/write files) from our current path in Windows, as it's a highly trivial stuff from Windows point of view, and we would avoid the need of placing Mame in Windows directory.

Just some comments when passing our resolution to Mame in Windows, it should have its refresh coverted to an integer label, the same that should be used to store that modeline in the system registry, and will be used to identify that mode in Windows internally. We should also check for Mame version, as this Width x Height @ Refresh format is only used since v.107 version, before that 'resolution' and 'refresh' are passed as separate parameters (I don't know if you're already checking this, but just in case).

Version 1.00j now does the refresh rate as an integer for running mame, modeline output.  Checks for the different hacks and gets the mame version (not used yet, will need to see how the command line needs to be for older versions), also now will execute mame.exe (or whatever --emulator X is set to) from the current working directory if it exists there.

[Calamity]

Version 1.00j now does the refresh rate as an integer for running mame, modeline output.  Checks for the different hacks and gets the mame version (not used yet, will need to see how the command line needs to be for older versions), also now will execute mame.exe (or whatever --emulator X is set to) from the current working directory if it exists there.

This version 1.00 works perfectly running Mame from the current directory, very cool now. It might be good to have the real vfreq also prompted besides its integer label.

For versions prior to v0.107, resolutions are set like this:

resolution 320x240
refresh 60

instead of

resolution0 320x240@60

[bitbytebit]

Version 1.00j now does the refresh rate as an integer for running mame, modeline output.  Checks for the different hacks and gets the mame version (not used yet, will need to see how the command line needs to be for older versions), also now will execute mame.exe (or whatever --emulator X is set to) from the current working directory if it exists there.

This version 1.00 works perfectly running Mame from the current directory, very cool now. It might be good to have the real vfreq also prompted besides its integer label.

For versions prior to v0.107, resolutions are set like this:

resolution 320x240
refresh 60

instead of

resolution0 320x240@60

Ah, so I just have to use the command line "-refresh 60 -resolution 320x240 then.  I wonder if the Linux versions before this were using 320x240 or 320x240x32 using the depth there, I'll have to look at that.

I'm not able to find through the registry file system that cygwin gives video keys, but then again it's really a big maze in there and I think in the code it's using functions that probably are finding the right directory to look in.  Do you have an example of a direct path to a custom modeline and one of the built in drivers modelines?

[Calamity]

The path will look like this:

HKLM\System\CurrentControlSet\Control\Video\{75BBD41E-4F24-4E21-9BDA-12CF2CC445F6}\0000

And the registry keys are we have these ones to store the list of custom modes:

Code: [Select]

HKR,, DALNonStandardModesBCD, %REG_BINARY%,\
01,84,01,92,00,00,00,60,01,84,02,00,00,00,00,60,01,92,01,92,00,00,00,60,01,92,02,08,00,00,00,60,\
01,92,02,16,00,00,00,60,02,08,02,08,00,00,00,60,02,16,02,24,00,00,00,60,02,24,02,24,00,00,00,60,\
02,24,02,32,00,00,00,60,02,24,02,40,00,00,00,60,02,32,02,24,00,00,00,60,02,40,01,92,00,00,00,60,\
02,40,02,16,00,00,00,60,02,40,02,24,00,00,00,60,02,40,02,32,00,00,00,60,02,40,02,40,00,00,00,60,\
02,40,02,52,00,00,00,60,02,40,02,56,00,00,00,60,02,48,01,92,00,00,00,60,02,48,02,24,00,00,00,60

HKR,, DALNonStandardModesBCD1, %REG_BINARY%,\
02,48,02,40,00,00,00,60,02,48,02,56,00,00,00,60,02,56,01,84,00,00,00,60,02,56,01,92,00,00,00,60,\
02,56,02,08,00,00,00,60,02,56,02,16,00,00,00,60,02,56,02,22,00,00,00,60,02,56,02,24,00,00,00,60,\
02,56,02,30,00,00,00,60,02,56,02,31,00,00,00,60,02,56,02,32,00,00,00,60,02,56,02,39,00,00,00,60,\
02,56,02,40,00,00,00,60,02,56,02,48,00,00,00,60,02,56,02,56,00,00,00,60,02,56,02,88,00,00,00,54,\
02,56,05,12,00,00,00,60,02,64,02,24,00,00,00,60,02,64,02,40,00,00,00,60,02,72,02,24,00,00,00,60

HKR,, DALNonStandardModesBCD2, %REG_BINARY%,\
02,72,02,72,00,00,00,57,02,80,02,10,00,00,00,60,02,80,02,32,00,00,00,60,02,80,02,40,00,00,00,60,\
02,80,02,56,00,00,00,60,02,80,02,80,00,00,00,55,02,88,02,08,00,00,00,60,02,88,02,16,00,00,00,60,\
02,88,02,24,00,00,00,60,02,88,02,40,00,00,00,60,02,88,02,48,00,00,00,60,02,88,02,56,00,00,00,60,\
02,88,02,88,00,00,00,54,02,96,02,24,00,00,00,60,02,96,02,38,00,00,00,60,02,96,02,40,00,00,00,60,\
03,04,02,16,00,00,00,60,03,04,02,24,00,00,00,60,03,04,02,32,00,00,00,60,03,04,02,40,00,00,00,60

And these other ones to store the modeline definition for each mode:

Code: [Select]

HKR,, DALDTMCRTBCD256X240X0X60, %REG_BINARY%,\
00,00,00,0C,00,00,03,52,00,00,02,56,00,00,02,72,00,00,00,32,00,00,02,61,00,00,02,40,00,00,02,41,00,00,\
00,03,00,00,05,51,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,F7,53

HKR,, DALDTMCRTBCD256X248X0X60, %REG_BINARY%,\
00,00,00,0C,00,00,03,52,00,00,02,56,00,00,02,72,00,00,00,32,00,00,02,69,00,00,02,48,00,00,02,49,00,00,\
00,03,00,00,05,68,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,F7,2A

HKR,, DALDTMCRTBCD256X256X0X60, %REG_BINARY%,\
00,00,00,0C,00,00,03,52,00,00,02,56,00,00,02,72,00,00,00,32,00,00,02,77,00,00,02,56,00,00,02,57,00,00,\
00,03,00,00,05,86,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,F7,00

HKR,, DALDTMCRTBCD256X288X0X54, %REG_BINARY%,\
00,00,00,0C,00,00,03,52,00,00,02,56,00,00,02,72,00,00,00,32,00,00,03,09,00,00,02,88,00,00,02,89,00,00,\
00,03,00,00,05,87,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,F6,9F

HKR,, DALDTMCRTBCD256X512X0X60, %REG_BINARY%,\
00,00,00,0E,00,00,03,52,00,00,02,56,00,00,02,72,00,00,00,32,00,00,05,55,00,00,05,12,00,00,05,14,00,00,\
00,05,00,00,05,86,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,F3,E5

HKR,, DALDTMCRTBCD264X224X0X60, %REG_BINARY%,\
00,00,00,0C,00,00,03,60,00,00,02,64,00,00,02,80,00,00,00,32,00,00,02,61,00,00,02,24,00,00,02,33,00,00,\
00,03,00,00,05,63,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,F7,47

HKR,, DALDTMCRTBCD264X240X0X60, %REG_BINARY%,\
00,00,00,0C,00,00,03,60,00,00,02,64,00,00,02,80,00,00,00,32,00,00,02,61,00,00,02,40,00,00,02,41,00,00,\
00,03,00,00,05,63,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,F7,2F

HKR,, DALDTMCRTBCD272X224X0X60, %REG_BINARY%,\
00,00,00,0C,00,00,03,68,00,00,02,72,00,00,02,88,00,00,00,32,00,00,02,61,00,00,02,24,00,00,02,33,00,00,\
00,03,00,00,05,76,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,F7,22

HKR,, DALDTMCRTBCD272X272X0X57, %REG_BINARY%,\
00,00,00,0C,00,00,03,68,00,00,02,72,00,00,02,88,00,00,00,32,00,00,02,93,00,00,02,72,00,00,02,73,00,00,\
00,03,00,00,06,13,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,F6,85

HKR,, DALDTMCRTBCD280X210X0X60, %REG_BINARY%,\
00,00,00,0C,00,00,03,76,00,00,02,80,00,00,02,96,00,00,00,32,00,00,02,61,00,00,02,10,00,00,02,27,00,00,\
00,03,00,00,05,89,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,F7,11

HKR,, DALDTMCRTBCD280X232X0X60, %REG_BINARY%,\
00,00,00,0C,00,00,03,76,00,00,02,80,00,00,02,96,00,00,00,32,00,00,02,61,00,00,02,32,00,00,02,37,00,00,\
00,03,00,00,05,89,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,F6,F1

HKR,, DALDTMCRTBCD280X240X0X60, %REG_BINARY%,\
00,00,00,0C,00,00,03,76,00,00,02,80,00,00,02,96,00,00,00,32,00,00,02,61,00,00,02,40,00,00,02,41,00,00,\
00,03,00,00,05,89,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,F6,E5

Built in modes are not defined here, you can get a list of them by calling the specific api. However, you can restrict any of them by the use of this other key:

Code: [Select]

HKR,, DALRestrictedModesBCD, %REG_BINARY%,\
03,20,02,00,00,00,00,00,03,20,02,40,00,00,00,00,04,00,03,00,00,00,00,00,05,12,03,84,00,00,00,00,\
06,40,04,00,00,00,00,00,08,00,06,00,00,00,00,00,10,24,07,68,00,00,00,00,11,52,08,64,00,00,00,00,\
12,80,10,24,00,00,00,00,16,00,12,00,00,00,00,00,17,92,13,44,00,00,00,00,18,00,14,40,00,00,00,00,\
19,20,10,80,00,00,00,00,19,20,12,00,00,00,00,00,19,20,14,40,00,00,00,00,20,48,15,36,00,00,00,00


[bitbytebit]

Thanks, I'll hopefully be able to figure out how to do that in Cygwin, unfortunately I think cygwin doesn't allow writing to the registry directly but then again I guess I could just write out a .reg file and do it that way. 

I'm refactoring the linux kernel patch, plus have confirmed it to work on 2.6.37-rc3 too so there's some improvements in that release with the drm stuff.  I'm going to switchres to generate all the modelines for the console/framebuffer and reduce them to just the main needed 640x480 800x600 1024x768 in 15Khz modes for a user to choose from.  I'm also possibly going to make it easier (I hope) to switch into arcade mode but of course that may not be possible since we have the no EDID issue but that could be another monitor than an arcade one.  There's really no way to know for sure if it's an arcade monitor or a broken EDID normal monitor, the whole reason why the linux kernel drivers and Windows drivers are designed to not work well with arcade monitors.  It all has to act like a non EDID monitor is a modern one to be 'safe', I'm mainly trying to make it so we still can plug a normal monitor into another port and get display too.  Otherwise I could just make it all arcade mode output but that probably would be too easy and not the best method.  I might go with just saying if there's no EDID you get arcade mode, unless you really put a special framebuffer video= mode on the command line other than the one with the 'c' at the end. 

[bitbytebit]

Where we do the recalculating when the
/* Minimum horizontal frequency */
part is hit and we go to the "Horizontal frequency too high %.3f vfreq %.3f" and can't virtualize since interlacing has already been done and that was where if we virtualized and had interlaced it caused the vertical refresh rate to not be honored.  This diff seems to do the best thing, after running the recalculation check the vertical refresh and if it's below/above limits then make it either the max/min depending on which way it's out of bounds then virtualize on that basis (this basically seems to happen when you give it a mode which is not really possible like the cga 1024 768 60.0Hz).  Now it seems to be able to produce something decent, I think at least, the diff and the two outputs before and after this change...

Before

Code: [Select]

arcade@arcade ~/src/SwitchResC $ switchres 1024 768 50 --monitor cga -v -v -v
Mame Version: 0.0
Hacks enabled: froggerfix redraw
[] on cga Monitor 1024x768@50.000 Resolution 1.000 Aspect

User input for minimum vertical size 224
Setup monitor limits min=184x224 max=0x576
Using interlace
Horizontal frequency too high 20.513 vfreq 50.000
Lowered horizontal frequency to  15.700 vfreq 38.861
Original Vref 50.000000 != 38.861384
# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vref Change | Interlace | )
#  [16] 1024x768x32@38.86 15.7194Khz
     "1024x768x38.86" 20.875403 1024 1064 1160 1328 768 770 776 809 -HSync -VSync interlace

#  [16] 1024x768x32@38.86 15.7194Khz
     "1024x768x38.86" 20.875403 1024 1064 1160 1328 768 770 776 809 -HSync -VSync interlace


After

Code: [Select]

arcade@arcade ~/src/SwitchResC $ ./switchres 1024 768 50 --monitor cga -v -v -v   
Running: mame -h
Mame Version: 0.140
Running: mame -showconfig
Hacks enabled: froggerfix redraw
[] on cga Monitor 1024x768@50.000 Resolution 1.000 Aspect

User input for minimum vertical size 224
Setup monitor limits min=184x224 max=0x576
Using interlace
Horizontal frequency too high 20.513 vfreq 50.000
Virtualized to 1024x592@49.50 15.6420Khz
Lowered horizontal frequency to  15.642 vfreq 49.500
Original Vref 50.000000 != 49.500000
# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vref Change | Interlace | Virtualize | )
#  [26] 1024x592x32@49.50 15.6668Khz
     "1024x592x49.50" 20.805444 1024 1064 1160 1328 592 594 600 633 -HSync -VSync interlace

#  [26] 1024x592x32@49.50 15.6668Khz
     "1024x592x49.50" 20.805444 1024 1064 1160 1328 592 594 600 633 -HSync -VSync interlace



Code: [Select]

diff --git a/modeline.c b/modeline.c
index c48d337..fbf09db 100644
--- a/modeline.c
+++ b/modeline.c
@@ -170,6 +170,16 @@ int ModelineCreate(GameInfo *game, MonitorMode *monitor, ModeLine *mode) {
                        VBlankLines = round(mode->hfreq * monitor->VerticalBlank);
                        mode->vfreq = mode->hfreq / (mode->vactive / interlace + VBlankLines);
                        mode->result |= RESULT_HFREQ_CHANGE;
+                       if (mode->vfreq > monitor->VfreqMax || mode->vfreq < monitor->VfreqMin) {
+                               if (mode->vfreq > monitor->VfreqMax)
+                                       mode->vfreq = monitor->VfreqMax;
+                               else
+                                       mode->vfreq = monitor->VfreqMin;
+                               interlace = 2;
+                               mode->interlace = 1;
+                               ResVirtualize(mode, monitor);
+                               mode->result |= RESULT_INTERLACE | RESULT_VIRTUALIZE;
+                       }
                        if (monitor->cs->verbose > 1)
                                fprintf(stderr, "Lowered horizontal frequency to  %.3f vfreq %.3f\n",
                                        mode->hfreq/1000, mode->vfreq);


So do you think this fix is the right thing to do, it works at doing basically the same thing before when we don't check if interlacing has been done yet but that of course caused the vertical refresh to not always be able to get on target when it was a possibility (so this seems to allow it to try but if it can't, then resort to changing it and virtualizing).

[Calamity]

I have to look more carefully into that, the fact is that my original algorithm does not produce that lowered vfreq. If I ask it to produce 1024x768@60 for H9110 it will do:

Modeline "1024x512@60.0Hz 16.7KHz (60Hz)" 22.660 1024 1072 1176 1360 512 514 519 555 interlace -hsync -vsync

There's a good reason for the order and position of each block and checking, but as it was mostly done more than two years ago now when moving stuff around it's really hard even for me to predict if it will have some side effect or not. But what's sure is that the logic has been slightly modified, otherwise you wouldn't need that extra check to repair things...

[Calamity]

I think I figured it out, maybe. That resolution should be catched here:

   /* Minimum horizontal frequency */
       [....]
      if (mode->vactive > monitor->ActiveLinesLimit &&
           monitor->cs->interlace && interlace == 1)

But it's not being captured right now because when it gets there interlace is 2 already (as it must be btw, and set on the upper check), so here you should remove && interlace == 1 in order to allow the resolution go through virtualizing.

(I've tried to compile the new version with the libxml you posted, however there seems to be some Unix specific functions in your code that won't allow a native Windows compile.)

[bitbytebit]

I think I figured it out, maybe. That resolution should be catched here:

   /* Minimum horizontal frequency */
       [....]
      if (mode->vactive > monitor->ActiveLinesLimit &&
           monitor->cs->interlace && interlace == 1)

But it's not being captured right now because when it gets there interlace is 2 already (as it must be btw, and set on the upper check), so here you should remove && interlace == 1 in order to allow the resolution go through virtualizing.

(I've tried to compile the new version with the libxml you posted, however there seems to be some Unix specific functions in your code that won't allow a native Windows compile.)

Ah cool, that works now, and I tried your case before which is why I had added that interlace==1 part (the one for 512 480 60 which got 63Hz ) and it works right too now with the change.  So when I put that there the rest of the code probably had other bugs I've fixed and now it comes out correctly as you expected for both games .  Hopefully that means things are improving somewhat, I went through your original code to check if I was missing anything or had went too far off and that was the only difference mainly I could see so good to know it was that one difference (and had tried removing that interlace==1 too but was worried about the previous issue when it wasn't there, but I just tested and it no longer is there so great).

Yeah it won't be able to compile in a native windows compiler but I'll use cygwin and it'll be the same either way since it's a binary that will work on Windows.  The reason is that there are Posix functions like wait and exec used and other wise we would never be able to compile on both Linux and Windows cleanly without tons of ifdef's and extra code so the code would be quite ugly to use both.  Besides that we are doing some stuff like executing mame mainly that I guess require completely different methods in Windows code compared to Linux code, and there's probably some other stuff I am utilizing that is Posix compliant and pure Windows compilers aren't. 

The interesting thing though is that I can put Windows API into the code and compile it still under Cygwin, I tried and am able to port the read active video modes or built in ones to the Windows C API and read the registry, compiling in Cygwin and mixing with Posix Linux/Unix C.  So it's the best of both worlds from what I can tell, We can use either Windows API calls or Unix/MacOS X Posix C calls too together with Cygwin.  Also it's what I currently have to compile it with and allows me to code for Linux and mostly know it'll compile for me still in Windows without constantly rewriting things again for a Windows native compiler .

[bitbytebit]

Version 1.00k
* New linux kernel patch supporting 2.6.37-rc3 with new modelines for bootup/framebuffer DRM generated using switchres for 640x480, 800x600 and 1024x768
* Version check so should work with resolution/refresh command line for older than 104 version of mame.
* Fixes for Windows and better check for cabmame hacks, for the most part should autodetect everything patched in mame that is necessary to create the best command line.
* fix for modeline generation from check for interlacing at a point it wasn't necessary
* weighting changed to improve best match on multisync monitors checking between virtualization and interlacing vs. size change and vert refresh changes.

[bitbytebit]

Thanks to Calamity in providing information on access the Windows registry, now switchres in Windows with the --soft15khz option can read the registry video modes available (both Soft15khz custom added ones and normal ones), use those to choose the best modeline to use instead of a separate file.  With a newer ArcadeVGA card this won't work since they don't store them in the registry for those.  Definitely one step closer to dynamic modeline generation in Windows, for now restarting the system with the modelines you generate though with switchres as it runs games works.   

Version 1.00r84
* version number now corresponds to my GIT repository revision number
* Soft15Khz Windows registry reading support to get the modes available to switch too, no longer need a file of modelines, only needed now for newer arcadeVGA cards
* Fixed some bugs, improved running setup on Windows a bit and better error checking in some places.
* show true refresh rate in double for output modelines info section,even in Windows where the actual modeline on the mame cmd line uses an integer.

[Calamity]

I'm posting here the results of the tests done by VeS,

** Pc 64bits, Ubuntu 10.10 64bits, normal installation, kernel 2.6.37-rc1 arcade (compiled by bitbytebit), grub video=640x480c, radeon.conf in modprobe.d

This is the xorg.conf being used (note by Calamity: I think there's some stuff missing yet, DefaultModes and the desktop modeline, however VeS claims to have tested also with those.)

Code: [Select]

Section "ServerLayout"
    Identifier     "X.org Configured"
    Screen      0  "Screen0" 0 0
    InputDevice    "Mouse0" "CorePointer"
    InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/X11/misc"
    FontPath     "/usr/share/fonts/X11/cyrillic"
    FontPath     "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/Type1"
    FontPath     "/usr/share/fonts/X11/100dpi"
    FontPath     "/usr/share/fonts/X11/75dpi"
    FontPath     "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
    FontPath     "built-ins"
EndSection

Section "Module"
    Load  "extmod"
    Load  "glx"
    Load  "record"
    Load  "dbe"
    Load  "dri2"
    Load  "dri"
EndSection

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

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

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
    Option "DPMS"
    HorizSync 14.0 - 18.0
    VertRefresh 50.0 - 62.0
- ATI 9250 + arcade monitor + xorg.conf : nothing shown on the screen (just the startup is badly displayed, not showing 15KHz, until drm, since there no picture) but you can hear the gnome desktop loading and Mame with toki.

xrandr -display :0.0 -q reports

Code: [Select]

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA-0 disconnected (normal left inverted right x axis y axis)
VGA-1 disconnected (normal left inverted right x axis y axis)
S-video disconnected (normal left inverted right x axis y axis)
- ATI 9250 + pc monitor + xorg.conf: shows startup until drm, no video since there (out of sync), after that gnome desktop shows and Mame can be loaded.

xrandr -display :0.0 -q reports

Code: [Select]

Screen 0: minimum 320 x 200, current 1152 x 864, maximum 4096 x 4096
DVI-0 disconnected (normal left inverted right x axis y axis)
VGA-0 connected 1152x864+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1360x768       59.8 
   1152x864       60.0*
   1024x768       60.0 
   800x600        60.3 
   640x480        59.9 
S-video disconnected (normal left inverted right x axis y

- AVGA 9250 + arcade monitor + xorg.conf : no video at all

xrandr -display :0.0 -q reports:

Code: [Select]

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA-0 disconnected (normal left inverted right x axis y axis)
VGA-1 disconnected (normal left inverted right x axis y axis)
S-video disconnected (normal left inverted right x axis y axis)
** Now we switch to the normal linux 2.6.35 kernel:

- AVGA 9250 + arcade monitor + xorg.conf : loads gnome desktop and Mame, although just one resolution is available (a low one):

xrandr -display :0.0 -q reports:

Code: [Select]

Screen 0: minimum 320 x 200, current 384 x 288, maximum 1344 x 1344
VGA-1 disconnected 384x288+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
VGA-0 disconnected (normal left inverted right x axis y axis)
S-video disconnected (normal left inverted right x axis y axis)
  384x288@51 (0x71)    7.4MHz
        h: width   384 start  416 end  440 total  472 skew    0 clock   15.8KHz
        v: height  288 start  288 end  291 total  292           clock   54.0Hz

Hopefully there's something from this tests that can give you some hint of what's going on.

[bitbytebit]

I'm posting here the results of the tests done by VeS,

** Pc 64bits, Ubuntu 10.10 64bits, normal installation, kernel 2.6.37-rc1 arcade (compiled by bitbytebit), grub video=640x480c, radeon.conf in modprobe.d

This is the xorg.conf being used (note by Calamity: I think there's some stuff missing yet, DefaultModes and the desktop modeline, however VeS claims to have tested also with those.)

Code: [Select]

Section "ServerLayout"
    Identifier     "X.org Configured"
    Screen      0  "Screen0" 0 0
    InputDevice    "Mouse0" "CorePointer"
    InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/X11/misc"
    FontPath     "/usr/share/fonts/X11/cyrillic"
    FontPath     "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/Type1"
    FontPath     "/usr/share/fonts/X11/100dpi"
    FontPath     "/usr/share/fonts/X11/75dpi"
    FontPath     "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
    FontPath     "built-ins"
EndSection

Section "Module"
    Load  "extmod"
    Load  "glx"
    Load  "record"
    Load  "dbe"
    Load  "dri2"
    Load  "dri"
EndSection

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

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

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
    Option "DPMS"
    HorizSync 14.0 - 18.0
    VertRefresh 50.0 - 62.0
- ATI 9250 + arcade monitor + xorg.conf : nothing shown on the screen (just the startup is badly displayed, not showing 15KHz, until drm, since there no picture) but you can hear the gnome desktop loading and Mame with toki.

xrandr -display :0.0 -q reports

Code: [Select]

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA-0 disconnected (normal left inverted right x axis y axis)
VGA-1 disconnected (normal left inverted right x axis y axis)
S-video disconnected (normal left inverted right x axis y axis)
- ATI 9250 + pc monitor + xorg.conf: shows startup until drm, no video since there (out of sync), after that gnome desktop shows and Mame can be loaded.

xrandr -display :0.0 -q reports

Code: [Select]

Screen 0: minimum 320 x 200, current 1152 x 864, maximum 4096 x 4096
DVI-0 disconnected (normal left inverted right x axis y axis)
VGA-0 connected 1152x864+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1360x768       59.8  
   1152x864       60.0*
   1024x768       60.0  
   800x600        60.3  
   640x480        59.9  
S-video disconnected (normal left inverted right x axis y

- AVGA 9250 + arcade monitor + xorg.conf : no video at all

xrandr -display :0.0 -q reports:

Code: [Select]

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA-0 disconnected (normal left inverted right x axis y axis)
VGA-1 disconnected (normal left inverted right x axis y axis)
S-video disconnected (normal left inverted right x axis y axis)
** Now we switch to the normal linux 2.6.35 kernel:

- AVGA 9250 + arcade monitor + xorg.conf : loads gnome desktop and Mame, although just one resolution is available (a low one):

xrandr -display :0.0 -q reports:

Code: [Select]

Screen 0: minimum 320 x 200, current 384 x 288, maximum 1344 x 1344
VGA-1 disconnected 384x288+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
VGA-0 disconnected (normal left inverted right x axis y axis)
S-video disconnected (normal left inverted right x axis y axis)
  384x288@51 (0x71)    7.4MHz
        h: width   384 start  416 end  440 total  472 skew    0 clock   15.8KHz
        v: height  288 start  288 end  291 total  292           clock   54.0Hz

Hopefully there's something from this tests that can give you some hint of what's going on.

In a lot of these tests it seems there are no modes available, I'm not sure what it's even doing, but suspect without the DefaultModes option used properly and if the kernel command line was done properly then that would be the result (which would give no modeline for the desktop to use).  Which means also there wasn't any default desktop modeline put into xorg.conf, which is what I would expect to happen.  Need to do three things essentially and if any are left out it'll possibly act like these examples, have the kernel DRM know it's an arcade monitor for the console output to use 640x480 (need to see the dmesg commands output to make sure this is really correct), turn off all the default modes in xorg.conf (which seeing the /var/log/Xorg.0.log file would show me it is really working right), and then you don't have any modelines for X to use so you need to add a modeline in xorg.conf for it to be able to show anything (need to see the xorg.conf log again and also very important actually is to have the Debug option in there like in mine to actually see information about what is going on ).  

So those 3 things are the keys, I have a feeling they aren't all being done together correctly, just maybe one or two at a time it looks like.  

The xorg.conf sections need these important parts...

Code: [Select]


xorg.conf --


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

        Option "DPMS"                   "false"

        HorizSync       15.25-38.00
        VertRefresh     40.00-80.00

        Option          "Primary"       "True"

        Option          "DefaultModes"  "False"                                # <<< Necessary
        UseModes        "ArcadeModes"                                         # <<< Necessary
EndSection



#
# This is necessary
#
Section "Modes"
        Identifier "ArcadeModes"

        # 641x480@60.00 15.6300Khz
        Modeline "641x480x60.00" 13.004160 641 664 728 832 480 482 488 521 -HSync -VSync interlace
EndSection



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

        #Option             "EXAVSync"       "yes"
        Option      "EnablePageFlip" "on"
        
        Option      "ModeDebug"      "true"                                          # <<< This is good to see info in Xorg.0.log

        Option      "ForceMinDotClock"    "3"

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



/boot/grub/grub.cfg

menuentry 'Gentoo Linux 2.6.37-rc1 x86_64' --class gentoo --class gnu-linux --class gnu --class os {
        recordfail
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        search --no-floppy --fs-uuid --set 9024ef37-9e8b-4502-a2a0-54a883fdd45e
        linux   /kernel-genkernel-x86_64-2.6.37-rc1_Digit root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sdc3 video=640x480c                         <<<<<<<<<<<IMPORTANT
        initrd  /initramfs-genkernel-x86_64-2.6.37-rc1_Digit
}



So hopefully those are all double checked, the xorg.conf file of course is very important and it seems that's not very cultivated with the needed keys which I outlined above.  I need to have a better documentation I guess of this process but of course it's all so new and  I'm trying to get everything put together, there's a lot of pieces to the puzzle :/.

It's interesting seeing the xrandr output, weird with the default kernel it does that, of course the default kernel shouldn't be able to do much besides a basic output and won't let the dotclocks below 12Mhz, and console won't show bootup (although ubuntu doesn't show much, and of course we won't get the bios to ever show up and startup of the kernel before DRM mode kicks in).  I  feel the linux kernel command line is there, and sometimes the default modes were turned off too.  I suspect there wasn't a default modeline properly setup for X to use (use the one I have above, if one was put in invalid, it would not use it, need to see Xorg.0.log in /var/log/ too).   Also make sure NOT to put anything into the Screen section referencing modelines, this is a thing about xorg.conf hardly anyone knows but one of the kernel developers told me and I saw this in the code (and what we've found in the past too).  Anything in there will make a CVT default of itself, so the screens section should look like this...

Code: [Select]


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



Also another possible test, is using 2.6.37-rc3 with my newest switchres linux patch, which both has a better 640x480c modeline and I wonder if possibly the 2.6.37-rc3 kernel might have some improvements for the AVGA cards (plus I now included that patch for them in it all as one patch).  Possibly after we figure out what is going on with the xorg.conf file, which seems like the main issue, proper setup of it. 
  

[Calamity]

Hi bitbytebit, thanks a lot for your patience, I'm sorry I can't be of much help on this, though I've been following the thread and know that every single step has a good reason for it and not following it will ruin the result, it's difficult for me remind what was the initial reason for each patch to be able to explain to VeS, however hopefully we'll be able to make it work or at least give you a decent report with that info now.

[bitbytebit]

Hi bitbytebit, thanks a lot for your patience, I'm sorry I can't be of much help on this, though I've been following the thread and know that every single step has a good reason for it and not following it will ruin the result, it's difficult for me remind what was the initial reason for each patch to be able to explain to VeS, however hopefully we'll be able to make it work or at least give you a decent report with that info now.

There's also another thing I can see as an issue, and definitely one that makes me wonder if using Ubuntu as a base is not a good thing.  I've never been able to build a kernel for Ubuntu that is custom, and gotten it to work right.  There's always some issue with the apps and patches they run extra, it always is half broken.  This is because if you read the official Ubuntu documentation they say they will not support custom kernels and really discourage it, and besides seem to have broken it too.  I thought the things I found would be better though, but I just tried booting into that custom one I built on my desktop ubuntu system and it complains about some apparmour part/app/service being non-compatible and has other unhappy messages as it boots.  Which really makes see how the Gentoo systems I've been working with are so much easier to put a custom kernel onto and it's like it used to be, how normal un-modified Linux systems work.  So that's an issue, is there a reason why Vess is using Ubuntu?  I'm curious because actually everything in Ubuntu seems to actually go somewhat against running mame, it's good for a desktop system and easy but for mame and emulation it doesn't have (from what I can tell) the best setup for this stuff.  It would be neat to build a Gentoo based system from the ground up similar to mine I've gotten this running on, because I know it works there and mainly because there there's really no changes to the source code for the main system.  It's just what the developers of the parts have done, minor fix patches, and unlike Ubuntu they don't go in and  change things to make it so you can't compile/install stuff yourself without breaking the system.  Which for this, how we are really patching the kernel and having to customize X startup (which Ubuntu doesn't really support custom X org configs, it expects to do it all itself), it really goes against the Ubuntu way of doing things but falls right in line with the Gentoo way. 

I guess the /var/log/dmesg output would show possibly if Ves is also running into the same issues as me with the Ubuntu kernel, but my desktop system uses the proprietary nvidia kernel module too which doesn't seem to install properly on my system for my custom arcade kernel build so I don't even get X windows on mine either.  The bootup might not be seen on an arcade monitor though, but if he boots it on a normal monitor I wonder if it is a clean bootup or has all the oddness I'm seeing here, keeps spitting out console messages about this and that not running (all extra extensions Ubuntu puts in, which we don't really need but it's not a clean setup at all with things doing that).  So definitely discourages me if I can't even build a kernel for Ubuntu with the Ubuntu development patches to the kernel which supposedly make it  work, and they don't for me. 

[Calamity]

He actually complained about using Ubuntu but I adviced him to do so as it had been discussed here that 10.10 had the new stuff we needed. I don't really know what he was using for his previous distribution. So this makes sense as he claimed to be changing stuff from xorg when doing tests as he was seeing errors and stuff.