The NEW Build Your Own Arcade Controls

Software Support => GroovyMAME => Topic started by: bitbytebit on October 07, 2010, 03:06:34 am

Title: Switchres: modeline generator engine
Post by: bitbytebit on October 07, 2010, 03:06:34 am
Switchres is a modeline generator that uses the algorithms from Calamity to calculate Arcade monitor modelines depending on your monitor type and specs.  It actually can calculate modelines for VGA and SVGA monitors too, or even LCD monitors.  Also Switchres can run any emulator with the modeline it generates in Linux and Windows, so you can actually try out the modeline live.  You need ATI cards to do this currently, and in Windows you need custom modelines setup for switchres to modify.

Switchres has been merged into Mame, although still useful for other emulators.  This thread mostly is just technical discussion on modelines for running mame with, history of development of groovymame.

http://arcade.groovy.org (http://arcade.groovy.org) - Switchres homepage with more information
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: Quinny on October 07, 2010, 07:41:36 am
Thanks for writing this. I am eager to try it once my arcadeVGA arrives.

Just one question, how do you know what the min and max values should be? I'll be using a PAL tv.
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 07, 2010, 12:25:44 pm
Thanks for writing this. I am eager to try it once my arcadeVGA arrives.

Just one question, how do you know what the min and max values should be? I'll be using a PAL tv.


for a PAL TV it takes the -pal argument (lrmc and the shell script).  Really the min/max values probably don't need to be used for the most part.  I use the min vertical height value for example on the d9800 because games lrmc can calculate 224 height on them or less than 240 basically which doesn't turn out so well on an arcade monitor (at least the d9800 it doesn't).  Also anything above 800x600 on a d9800 is no going to work, so I use those as the max values (defaults I set because most arcade situations won't use anything above that).  So you probably don't have to mess with those values at all, and if you see resolutions produced that don't work well because of being too high/low for those values then you can set those limits to avoid them.


Also note I just uploaded a new version because I realized the default resolution needed to change for different monitors, like a PAL TV.  This is the resolution it falls back on for games like Frogger Galaxian which have really crazy vertical resolutions (768) and basically just need to fall back onto something like 640x480@60 Hz.  So now it adapts to the default for each monitor type, and also the default can be changed on the command line now too.  So this should work for a PAL/NTSC TV better now, definitely interested in the results and any thing I need to fix to make it work on those if it has problems.
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 08, 2010, 02:25:50 am
Version 0.06 - I added a cabmame.diff file which can patch the current version of mame with the cabmame hacks and include Linux support.  The frogger/galaxian patch can be utilized from that patch now with the -ff option to lrmc to handle all the games with those odd 224x768 resolutions.  Also I was able to fix a ton of resolutions where instead of going to 640x480 it can calculate a good resolution with the same vertical height as the original.  This helps games like Tron when you have a WG d9800 and can display a resolution of 688x512@57.14 and it looks better, also with the frogger/galaxian patch now galaxian can play nice without the refresh issues at 400x256@57.36.  Now the only resolutions it resorts to using unevenstretch/keepaspect instead of native monitor resolution and the given default res (640x480@60 by default for WG9800 monitors) are the ones which are way larger than your given maximum width/width (defaults to 800x600).
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: ves on October 08, 2010, 09:23:46 am
Hi, thanks for your patches and improvements in Genres, I wanted to ask if this genre to implement real arcade monitors as HANTAREX or otherwise you're just applying it to the Wells Gardner, which would be an optimum configuration for Hantarex?

With regard to the diff, you could explain more what they actually do? I have understood the implemented improvements cabmame.diff cleanstretch emuspeed resolution (resolved or additions would be problems in sdlmame Syncrefresh and waitvsync?).
With nativeres.diff would leave only select their original resolution?
Parameters that would need the mame.ini with new patches?



Thanks.
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 08, 2010, 10:38:25 am
Hi, thanks for your patches and improvements in Genres, I wanted to ask if this genre to implement real arcade monitors as HANTAREX or otherwise you're just applying it to the Wells Gardner, which would be an optimum configuration for Hantarex?

With regard to the diff, you could explain more what they actually do? I have understood the implemented improvements cabmame.diff cleanstretch emuspeed resolution (resolved or additions would be problems in sdlmame Syncrefresh and waitvsync?).
With nativeres.diff would leave only select their original resolution?
Parameters that would need the mame.ini with new patches?



Thanks.

It should work for any monitor/TV, since it's using lrmc it should be able to either use -cga for arcade monitors or even any custom set of Horizontal/Vertical frequencies using an lrmc.conf file.  I of course have only tested on the d9800, but suspect it should work for anything that lrmc supports, which seems to be any lowres monitor or PAL/NTSC TV.  You basically just have to give it a command like this for an actual arcade monitor...

./create_xorg.sh -cga

and add -ff if using the frogger/galaxian included patches.  If there are limits on max resolution sizes, alter those with the command line args and any other lrmc args needed to create a good modeline for the monitor.  I would be interested in any additional args needed, then I could add those as defaults for different monitor types, like the maximum height/width most likely since I have it at 800x600 for the d9800 as the default.

The nativeres is a patch from the qmc2 project and just basically uses the games native resolution settings instead of changing it in mame, really I don't see it doing too much actually to be honest so can have nativeres at the default of 0 to be safe.  I also made the nativeres setting work when the changeres option is used, I think that makes it to where it keeps the games original resolution inside the forced resolution from the .ini file but not 100% sure on that, it seems act fine that way and maybe a few pixels/lines nicer on the edges with that from what I can tell.  The other patch just applies to a source tree that has the nativeres patch already applied.  Really the main bonus I've seen of the patches so far is that the frogger/galaxian games fixes, which do seem to rely some on the cleanstretch patch although it seems like just an opposite of the unevenstretch option already in sdlmame but a different take on how to do it I think.  I've just started exploring the CabMame patches and ported the ones to Linux that seem doable, the sound frequency one seems possibly hard because SDL sound doesn't allow frequency changing on the fly easily like the Windows API seems to.  Seems like the patches run fine still with waitvsync either on/off, the options below are the additional options they enable...

nativeres 1/0 (0 by default)
cleanstretch 1/0 (1 by default)

I also think I fixed a possible bug in the cleanstretch patch working with the frogger/galaxian patch properly, at least when cleanstretch is turned off it seems that the frogger/galaxian fix wasn't also done in that case while now it will work with cleanstretch off as well.  There is an oddity I see with the frogger/galaxian patch though when using software video instead of opengl for some reason the frogger/galaxian resolution games don't get put in the window centered (they are way down below so basically just a black screen).  That's one issue I don't fully understand, that opengl is required for that fix, also similar to an issue that happens in mame without patches in SDL where if the artwork is present but turned off the games are offset by the bezel sizes using software video while in opengl it properly centers then correctly even with the artwork present but settings turning it off.  I get the feeling somehow software rendering in SDL mame doesn't do something that opengl is doing to setup the screen to the actual game dimensions once artwork or the galaxian vertical size adjustment is done.  Would be interesting to see if others really see this same issue as me or  it's just something I'm doing wrong locally on my setup.

Also it's important to set the following mame options in the mame.ini to these, to avoid any stretching in SDL mame.

video                   opengl   # prefered for reasons explained above
filter                    0          # off to prevent opengl softening
gl_glsl_filter          0           # Assume filtering is bad, guessing this is not necessary


waitvsync                 1 # sounds good, works fine with patches, not sure if really necessary

window                     0
maximize                   0
keepaspect                0 # this is setup only for a few games in the .ini files which resolutions don't match the aspect ratio
unevenstretch            0 # same as above, used together
cleanstretch              0  # Actually surprisingly I have this off for now, not fully tested.  It DOES NOT work well with unevenstretch enabled.  Seem like opposite options.

# Off for an arcade setup, oddly in soft mode even if off and I have the artwork directory, game is offset size of artwork from top.  Same as with frogger patch, since it reduces the vertical size I guess.
artwork_crop                0  
use_backdrops             0
use_overlays               0
use_bezels                 0



Hopefully that helps clear up some things of how to set the options to work the best and the patches, similar to what the ArcadeVGA card setup instructions are in Windows yet somewhat different for SDL.  I still don't get why they ask you to use unevenstretch and keepaspect as defaults (which makes pacman look terrible, at least in SDL).  Or why the current Windows based .ini file generators used choose some of the resolutions they do, which is why I created this genres method plus getting those modelines in Linux and knowing they all would work was proving to be way too tricky.  Usually they say go through and tweak them by hand, but I've really worked to make this able to not require that and automated all of the tweaking by hand since most of the time there's some algorithm there you can put into code for all the games following the same logic.


Edit: I think I'm going to remove the cabmame.diff and just include a Linux SDL version of the frogger.diff fix from cabmame.  This seems like the only real important patch necessary to work with lrmc like this and get those games like frogger/galaxian to natively display correctly on arcade monitors.  Doing some testing, next version will include just the frogger patch and nativeres one although it is only optional since I don't even know for sure yet if it does much of anything :/.
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: Calamity on October 08, 2010, 02:06:55 pm
Hi bitbytebit,

This is a highly interesting project, I hope we can share some stuff. I also wrote a program to generate modelines + .inis from Mame XML, for the Windows platform. Mine is called VideoModeMaker, and can be downloaded here (in Spanish):

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

As you state, there is a limitation to Windows video drivers that, by default, just allow for a small number of custom modes to be defined. That's why I patched Ati Catalyst drivers so they can admit more modelines, up to 200. I focused on Ati because at the beginning I was only interested in extending ArcadeVGA capabilities. However, 200 modelines is still not enough to accommodate all resolutions needed for emulation, that's why I wrote that program, that attempts to order them by importance so they can fit in a predefined-length mode table.

Though I have no experience with Linux, I'm trying to help VeS (who posted above) to prepare a live distribution of Linux that works like AdvanceMame, we've been struggling with it in this thread (in Spanish also):

http://www.retrovicio.com/foro/showthread.php?t=9258 (http://www.retrovicio.com/foro/showthread.php?t=9258)

In Windows, I have worked out a modeline "labeling" system that works reasonably well for it's purpose, but we're having some troubles to port it to Linux. Maybe with your system and inis we can achive the results we're looking for. I'd highly appreciate some help with this.

To add up, in Windows OS video modes are stored using three integers: xres, yres, vfreq. So, to invoke a given resolution using Mame, you just have to set the ini up like this:

resolution0 320x224@58

Now consider we have two modelines which vertical refresh rate just differs in some tenths:

Modeline "320x224@57.6Hz 15.7KHz (58Hz)" 6.630 320 336 368 424 224 239 242 272 -hsync -vsync
Modeline "321x224@58.0Hz 15.7KHz (58Hz)" 6.640 320 336 368 424 224 238 241 270 -hsync -vsync

As vertical refresh rate is stored as an integer, I need to modify the mode "label" so both video modes can coexist. I do that by increasing xres by one pixel each time (321, 322, ...) so I can store 8 variations of a resolution within 1 Hz interval (as I only use 8 pixel multiples for xres). This can be done because we store these "labels" in windows registry before they are used by the OS, which by the way are indepent of the actual modeline info that we store together.

BUT... I suspect that in Linux, the modeline part between quotations is just considered as a name, it could be "320x224" or "whatever". Am I right?
SO... how can you manage to make a difference among above modelines?
How would you invoke them from Mame inis to be sure the proper modeline is used?

Now, about CabMame stuff... I also use Windows CabMame to work with the modelines produced by my program, as Syncrefresh was spoiled since v0.107 (as far as I know), so it's also a great surprise that you are trying to port those patches to SDLMame. Even if we don't have triplebuffer in SDLMame, have you got Waitvsync to work smoothly as it's intended? What we need, is an option that disables normal throttling and just syncs the game action to the vertical frequency, whatever it is. I was able to hack regular Mame to do this without the help of CabMame patches, but whatever method you use and works we'll be grateful to know.

Thanks!

Calamity
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 08, 2010, 03:45:36 pm
Hi bitbytebit,

This is a highly interesting project, I hope we can share some stuff. I also wrote a program to generate modelines + .inis from Mame XML, for the Windows platform. Mine is called VideoModeMaker, and can be downloaded here (in Spanish):

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

As you state, there is a limitation to Windows video drivers that, by default, just allow for a small number of custom modes to be defined. That's why I patched Ati Catalyst drivers so they can admit more modelines, up to 200. I focused on Ati because at the beginning I was only interested in extending ArcadeVGA capabilities. However, 200 modelines is still not enough to accommodate all resolutions needed for emulation, that's why I wrote that program, that attempts to order them by importance so they can fit in a predefined-length mode table.


Yes definitely, I currently have 442 modes generated with both mess and mame combined.  Next version of genres has mess support too, and it just adds tons of new ones.


Though I have no experience with Linux, I'm trying to help VeS (who posted above) to prepare a live distribution of Linux that works like AdvanceMame, we've been struggling with it in this thread (in Spanish also):

http://www.retrovicio.com/foro/showthread.php?t=9258 (http://www.retrovicio.com/foro/showthread.php?t=9258)

In Windows, I have worked out a modeline "labeling" system that works reasonably well for it's purpose, but we're having some troubles to port it to Linux. Maybe with your system and inis we can achive the results we're looking for. I'd highly appreciate some help with this.

To add up, in Windows OS video modes are stored using three integers: xres, yres, vfreq. So, to invoke a given resolution using Mame, you just have to set the ini up like this:

resolution0 320x224@58

Now consider we have two modelines which vertical refresh rate just differs in some tenths:

Modeline "320x224@57.6Hz 15.7KHz (58Hz)" 6.630 320 336 368 424 224 239 242 272 -hsync -vsync
Modeline "321x224@58.0Hz 15.7KHz (58Hz)" 6.640 320 336 368 424 224 238 241 270 -hsync -vsync

As vertical refresh rate is stored as an integer, I need to modify the mode "label" so both video modes can coexist. I do that by increasing xres by one pixel each time (321, 322, ...) so I can store 8 variations of a resolution within 1 Hz interval (as I only use 8 pixel multiples for xres). This can be done because we store these "labels" in windows registry before they are used by the OS, which by the way are indepent of the actual modeline info that we store together.

Oh, that's an integer value in the ini files?  Very odd, wonder why they have it like that since they are all not like that in the xml file and in the code too.  I wonder if that can be changed to read the ini files refresh rates as doubles instead, which would solve the need for extra work like that.


BUT... I suspect that in Linux, the modeline part between quotations is just considered as a name, it could be "320x224" or "whatever". Am I right?
SO... how can you manage to make a difference among above modelines?
How would you invoke them from Mame inis to be sure the proper modeline is used?

In linux they are just labels, and can be anything such as "BIGRES" and that'd work if in the Modes  section in line, also in Linux if you put basic "800x600" in the Modes section it'll find the default on from the cards driver.   I just do the "800x600@60.00" and have them different that way, looks like the best way to pull that from ini files (I had thought were accepting the full double values) would be to hack mame to accept that.


Now, about CabMame stuff... I also use Windows CabMame to work with the modelines produced by my program, as Syncrefresh was spoiled since v0.107 (as far as I know), so it's also a great surprise that you are trying to port those patches to SDLMame. Even if we don't have triplebuffer in SDLMame, have you got Waitvsync to work smoothly as it's intended? What we need, is an option that disables normal throttling and just syncs the game action to the vertical frequency, whatever it is. I was able to hack regular Mame to do this without the help of CabMame patches, but whatever method you use and works we'll be grateful to know.

Really new to the cabmame patches, as of yesterday basically, and definitely interested in this throttle issue and vsync.  I do notice in SDL if I set throttle to 0 or off, then the games run as fast as they can and are fast forwarding basically, so in SDL seems even with waitvsync set to 1 it doesn't work.  I know I can set waitvsync to 1 and things work fine, but not sure if it's really doing anything and I know the throttle setting has to be 1 for things not to fly super fast.  Have seen how triplebuffer would be better, not sure if that's a driver thing missing in SDL or fully how all that works yet.  I'd be interested in seeing how you got the vsync working, would help me understand more how that all is setup in the code and maybe help figure out more about the throttle issue and SDL. 

I have the frogger patch figured out, it's simple, although there's still something odd there because it won't work without opengl so it's missing some proper setup in SDL to do both soft/opengl.  The cleanstretch still strange to me because it seems like it would only be needed when having to stretch things and the unevenstretch interferes with it oddly, trying to see how that all works.  I swear it looks like the cleanstretch patch changes the action of things so they aren't the same when it's set to 0, sort of how the frogger patch only was setup to work when the cleanstretch patch was applied and set to 1.   A lot of the other cabmame patches look like either would not fit SDL without some really heavy changes to things from lack of SDL support for audio resampling on the fly (at least what I can tell it doesn't work), I have a hiscore patch for Linux (just adds onto the current one on these forums, so it's a quick easy fix per version change of mame to add on top of that one), the defaults patch and changeres seems probably not necessary for basic arcade games so I'm looking at it later (plus seems a bit tricky to port).  The emuspeed patch I don't fully see what it's doing, or resolution one I'm not fully sure either yet.  So the vsync thing seems really interesting to me, since this all would really work well with getting the .ini files and modelines exact, waiting on all the other cabmame patches for now since seems not as centered around the resolution stuff and require some redoing I think in the SDL part of mame.

Thanks!

Calamity


Thanks, I'm going to look at the .ini refresh rate thing and also have a lot of fixes/cleanups actually to genres including the support for mess modelines/merging.  Sounds like this .ini file issue would be a big step, since now I realize not all my modelines are probably getting used.

Thanks,
Chris
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 08, 2010, 06:12:48 pm

To add up, in Windows OS video modes are stored using three integers: xres, yres, vfreq. So, to invoke a given resolution using Mame, you just have to set the ini up like this:

resolution0 320x224@58


Oh my, look at this, at least in the sdl code we are doing it wrong...

if (sscanf(data, "%dx%dx%d@%d", &config->width, &config->height, &config->depth, &config->refresh) < 2 && report_error)

Actually the resolution value needs to be widthxheightxdepth@refresh

How odd, but they are definitely integers, that's for sure.

Ah, ok, in windows this doesn't have the depth value...

if (sscanf(data, "%dx%d@%d", &config->width, &config->height, &config->refresh) < 2 && report_error)

But also an integer



At least I'm finding where to start looking.


Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: Calamity on October 08, 2010, 06:57:42 pm
Oh, that's an integer value in the ini files?  Very odd, wonder why they have it like that since they are all not like that in the xml file and in the code too.  I wonder if that can be changed to read the ini files refresh rates as doubles instead, which would solve the need for extra work like that.

It's not a Mame issue, it's the OS that stores videomodes in that way, so it doesn't matter that you use doubles in Mame, because at least in windows you end up having to a ask the OS for the mode you need, and the functions involved use integers.

I don't mean it's the same in Linux, but think about this... do you think that when you add a modeline the operating system is really working out the vfreq resulting from that modeline data so that you can ask for it later? I really doubt it.

In linux they are just labels, and can be anything such as "BIGRES" and that'd work if in the Modes  section in line, also in Linux if you put basic "800x600" in the Modes section it'll find the default on from the cards driver.   I just do the "800x600@60.00" and have them different that way, looks like the best way to pull that from ini files (I had thought were accepting the full double values) would be to hack mame to accept that.

Are those labels stored somewhere? Can you by any means invoke those video modes by using it's text label, like "BIGRES"? That would definitely solve the problem if we modified Mame to read a string from the inis instead of a numbers for the resolution. It's just a suggestion as I have no idea how Linux manages this stuff.

Really new to the cabmame patches, as of yesterday basically, and definitely interested in this throttle issue and vsync.  I do notice in SDL if I set throttle to 0 or off, then the games run as fast as they can and are fast forwarding basically, so in SDL seems even with waitvsync set to 1 it doesn't work.  I know I can set waitvsync to 1 and things work fine, but not sure if it's really doing anything and I know the throttle setting has to be 1 for things not to fly super fast.  Have seen how triplebuffer would be better, not sure if that's a driver thing missing in SDL or fully how all that works yet.  I'd be interested in seeing how you got the vsync working, would help me understand more how that all is setup in the code and maybe help figure out more about the throttle issue and SDL. 

I have the frogger patch figured out, it's simple, although there's still something odd there because it won't work without opengl so it's missing some proper setup in SDL to do both soft/opengl.  The cleanstretch still strange to me because it seems like it would only be needed when having to stretch things and the unevenstretch interferes with it oddly, trying to see how that all works.  I swear it looks like the cleanstretch patch changes the action of things so they aren't the same when it's set to 0, sort of how the frogger patch only was setup to work when the cleanstretch patch was applied and set to 1.   A lot of the other cabmame patches look like either would not fit SDL without some really heavy changes to things from lack of SDL support for audio resampling on the fly (at least what I can tell it doesn't work), I have a hiscore patch for Linux (just adds onto the current one on these forums, so it's a quick easy fix per version change of mame to add on top of that one), the defaults patch and changeres seems probably not necessary for basic arcade games so I'm looking at it later (plus seems a bit tricky to port).  The emuspeed patch I don't fully see what it's doing, or resolution one I'm not fully sure either yet.  So the vsync thing seems really interesting to me, since this all would really work well with getting the .ini files and modelines exact, waiting on all the other cabmame patches for now since seems not as centered around the resolution stuff and require some redoing I think in the SDL part of mame.

This is the patch I used for restoring Syncrefresh functionallity in Mame v0.131 (I believe it's still usable). However, in SDLMame there's no Syncrefresh so it should be adapted for Waitvsync (I don't know how this option works in SDLMame or if it's equivalent). It's a very simple hack. Bear in mind I have never used C for programming, so if you find a more intelligent way for referencing those declares it would be great.

Code: [Select]
-------------------------------------------------------------------------------
 Restoring Syncrefresh option - Mame v0.131
02/02/09 Calamity
-------------------------------------------------------------------------------

In src\emu\video.c:

After the includes, we copy:

/***************************************************************************
    Restoring Syncrefresh
    Declares copied from src\osd\windows\video.h
***************************************************************************/

#define MAX_WINDOWS 4

typedef struct _win_window_config win_window_config;
struct _win_window_config
{
float aspect; // decoded aspect ratio
int width; // decoded width
int height; // decoded height
int refresh; // decoded refresh
};

typedef struct _win_video_config win_video_config;
struct _win_video_config
{
// global configuration
int windowed; // start windowed?
int prescale; // prescale factor
int keepaspect; // keep aspect ratio
int numscreens; // number of screens
int layerconfig; // default configuration of layers

// per-window configuration
win_window_config window[MAX_WINDOWS]; // configuration data per-window

// hardware options
int mode; // output mode
int waitvsync; // spin until vsync
int syncrefresh; // sync only to refresh rate
int triplebuf; // triple buffer
int switchres; // switch resolutions

// ddraw options
int hwstretch; // stretch using the hardware

// d3d options
int filter; // enable filtering
};

extern win_video_config video_config;


Still in src\emu\video.c:
Below, we'll search for:

/* if we're throttling, synchronize before rendering */
if (!debug && !skipped_it && effective_throttle(machine))

We'll replace it with:

/* if we're throttling, synchronize before rendering */
if (!debug && !skipped_it && effective_throttle(machine) && !video_config.syncrefresh)

The problem with this hack is that if modeline's vfreq is slightly different from the original game vfreq we should have sound sync problems, I believe.

Until Mame v0.106, it was enough to turn Syncrefresh on to have perfectly smooth scrolls with sound syncronized. Triplebuffer enables vsync but it's not as cpu consuming as vsync (syncrefresh). IMHO, the most important hack in CabMame is the soundsync option, which allows you to activate Triplebuffer without the sound issues that exist since v0.107. As triplebuffer may not be implemented in SDL (I don't really know), we could manage with the hack above if we got it working, despite the sound.

If vsync is not working properly, it's noticeable as you'll have horrible tearing in your games.

BTW, if you run mame with -verbose option it will prompt the video mode chosen, this might help to determine if it's working as expected.

Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 08, 2010, 11:28:10 pm
Yeah I am wondering now about the refresh rate and how it would be called for a game even, not sure if the SDL calls really can be that precise.  I did alter the SDL code in mame to store it as doubles and pass it to SDL, but can see how the Windows code doesn't look so inviting to such a change.  Right now I'm trying to figure out if all my odd refresh rates of the same resolution really are even being used.  Actually I can't tell for sure if the vertical frequency is being applied for sure, oddly even with -verbose on mame or the X windows output logs it doesn't say if it used it.  From what I can tell I'm just getting all of them with a range of 57-60 Hz and mostly 59 Hz it seems.  I'm digging into see if something is limiting that in the X server for the Radeon chip which the ArcadeVGA card is using.

Basically the way the modelines work in X windows are lables and they are just plain labels, then you have a list of them as a Modes section in order from first choice to last.  It seems the calls to change resolution go through this list finding the first one that matches.  It looks like this...


    Modeline "288x240x56.00"  5.278336  288 296 328 344  240 244 248 274  -HSync -VSync
    Modeline "280x247x54.08"  5.124000  280 288 320 336  247 251 255 282  -HSync -VSync
    Modeline "280x244x60.04"  5.628000  280 288 320 336  244 248 252 279  -HSync -VSync
    Modeline "280x240x60.00"  5.523840  280 288 320 336  240 244 248 274  -HSync -VSync
    Modeline "280x240x58.00"  5.339712  280 288 320 336  240 244 248 274  -HSync -VSync
    Modeline "272x267x50.00"  5.002000  272 280 304 328  267 272 276 305  -HSync -VSync
    Modeline "272x251x53.14"  5.002000  272 280 304 328  251 256 260 287  -HSync -VSync
    Modeline "272x240x60.00"  5.392320  272 280 304 328  240 244 248 274  -HSync -VSync
    Modeline "272x240x57.00"  5.122704  272 280 304 328  240 244 248 274  -HSync -VSync
    Modeline "272x240x56.00"  5.032832  272 280 304 328  240 244 248 274  -HSync -VSync
    Modeline "264x256x55.00"  5.139200  264 272 296 320  256 260 264 292  -HSync -VSync
    Modeline "264x240x60.00"  5.260800  264 272 296 320  240 244 248 274  -HSync -VSync
    Modeline "264x240x59.00"  5.173120  264 272 296 320  240 244 248 274  -HSync -VSync
    Modeline "264x240x58.00"  5.085440  264 272 296 320  240 244 248 274  -HSync -VSync
    Modeline "256x256x57.36"  5.092000  256 264 288 304  256 260 264 292  -HSync -VSync
 
And then in another section it has them listed as...
    Modes "288x267x50.00" "288x244x60.04" "288x243x55.05" "288x240x60.00" "288x240x59.00" "288x240x58.00" "288x240x57.00" "288x240x56.00" "280x247x54.08" "280x244x60.04" "280x240x60.00" "280x240x58.00" "272x267x50.00" "272x251x53.14" "272x240x60.00" "272x240x57.00" "272x240x56.00" "264x256x55.00" "264x240x60.00" "264x240x59.00" "264x240x58.00" "256x256x57.36"

Where the first is the first one tried

From what I can tell in SDL at least, we are just giving it the height/width actually.  The code I saw in there using the refresh rate is for SDL 1.3 it seems, which I need to try again, first compile with it did not work at all.  So seems that SDL 1.2 doesn't even pass the refresh rate it wants.  

Definitely interesting, I'm looking deeper into this, also seems the code I'm looking at probably would be somehow involving the waitvsync stuff which seems broken if the throttle is turned off although maybe it's doing the job because some code calls SDL functions using that.


Update: When I run as root in SDL mode at the Linux Console outside of X windows using software rendering, it seems it listens to my vertical refresh rates and the throttle setting can be 0 too.  Hmmm, so something is odd, it can do it, but X windows may be getting in the way or not being root (I can do this as a normal user for some reason, at least change modes, it will play though).

Ok it's even weirder than that, I can use the waitvsync 1 and throttle 0 options, get it to show the proper vertical refresh loading up, but have to run the mame default SDL menu and launch games from there.  Once that is done then after that it will work for them outside of that menu, because it writes a new .mame/game.ini file for each game using the values from the custon ini/game.ini file?   It seems really strange it's doing it this way, and it doesn't pay attention to those settings otherwise.  Well I've got something really odd to explore now, it does seem to be really utilizing the monitor now getting the resolution to really use the modelines though.  I'm definitely confused now as to what exactly it's doing, like it only does the switchres properly from the mame sdl menu and/or when there's a .ini file in ~/.mame/ and not ~/ini/
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 09, 2010, 05:30:19 am
I figured out the issue in Linux with the Xorg server and at least the ATI Radeon driver (which the ArcadeVGA card uses).  I am thinking other X Drivers may do this too, basically it ignores your entire Modeline except the very first part of it or name and parses that for the HxW values and ignores everything else.  Seems quite odd to make all these modelines and for the X Driver to ignore all of it.  I have hacked it so far to actually take the refresh value and calculate it, was just using 60.0 hardwired in the driver.  This has improved things already seeing the actual refresh rates be correct.  I still need to figure out how to make it really listen to the whole modeline though, it is ignoring the -Vsync value for some reason and always using +VSync, also alters the numbers slightly and figure it'd be nice if we could either choose all that or have an option to tell the driver what kind of Arcade monitor it exactly is so it can be like lrmc and do the calculations right. 

So there might have to be a lrmc/Radeon driver patch for Linux to allow the ArcadeVGA or any other Radeon card to use lrmc and calculate modelines which MAME mostly will use with the ini files, probably a patch for MAME to use doubles for the resolution (which I do have) but also have to figure out how to really force the X driver to go to the proper mode with the right refresh rate we want.  I'm pretty sure this is possible, hopefully doesn't need SDL 1.3 because that is not near ready from what I can tell for general use.  There's this RandR X Method of changing the X server resolution which MAME might be able to call and tell it what to do, maybe that's what xmame did or similar to how AdvanceMAME worked but this is officially through the X Driver API. 

Seems like when all this is put together should be pretty good, and see how the vsync method would help.  I can tell already with the change in using the refresh rate games play way smoother and I had a lot of fun, either I'm sleep deprived or it made quite a difference already. 
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: Calamity on October 09, 2010, 06:21:43 am
Hi bitbytebit,

These are great news! I suspected there was something odd with Linux modeline management. And yes, I also found some strange behaviour when invoking games from SDLMame menu, the ini options weren't read or used as expected, or just were properly used for the first one... though I did these tests some time ago and I can't remember exactly what was wrong...

This is a patch I used over CabMame diffs, its related to Emuspeed patch and I use it to prompt the real emulation speed in Hz, with several decimals, and the average speed. It is useful in combination with vsync to see if the vfreq intended is actually working:

Code: [Select]

Go to \src\emu\video.c

/*-------------------------------------------------
    Patch for prompting emulation speed in Hz
    This was done for v0.131, it may need updating
    - Calamity -

    video_get_speed_text - print the text to
    be displayed in the upper-right corner
-------------------------------------------------*/

const char *video_get_speed_text(running_machine *machine)
{
int paused = mame_is_paused(machine);
static char buffer[1024];
char *dest = buffer;
float rate;
screen_state *state = NULL;

/* validate */
assert(machine != NULL);

/* if we're paused, just display Paused */
if (paused)
dest += sprintf(dest, "paused");

/* if we're fast forwarding, just display Fast-forward */
else if (global.fastforward)
dest += sprintf(dest, "fast ");

/* if we're auto frameskipping, display that plus the level */
else if (effective_autoframeskip(machine))
dest += sprintf(dest, "auto%2d/%d", effective_frameskip(), MAX_FRAMESKIP);

/* otherwise, just display the frameskip plus the level */
else
dest += sprintf(dest, "skip %d/%d", effective_frameskip(), MAX_FRAMESKIP);

/* append the speed for all cases except paused */

if (machine->primary_screen != NULL)
state = get_safe_token(machine->primary_screen);

rate = (state != NULL) ? ATTOSECONDS_TO_HZ(state->frame_period) : DEFAULT_FRAME_RATE;

if (!paused && global.overall_emutime.seconds >= 2)
{
osd_ticks_t tps = osd_ticks_per_second();
double average_real_time = (double)global.overall_real_seconds + (double)global.overall_real_ticks / (double)tps;
double average_emu_time = attotime_to_double(global.overall_emutime);

dest += sprintf(dest, " %4.2f%% %4.6f/%4.6f Hz [%4.6f]", 100 * global.speed_percent, global.speed_percent * rate, rate, average_emu_time / average_real_time * rate);


        }
/* display the number of partial updates as well */
if (global.partial_updates_this_frame > 1)
dest += sprintf(dest, "\n%d partial updates", global.partial_updates_this_frame);

/* return a pointer to the static buffer */
return buffer;
}

If you are going to dig in the modeline calculations for Ati Radeon, this will be of your interest: if you download the package from the link I pasted in my firt post, you'll find a file named Ati9250.txt. Inside there's the list of the real dotclocks used by Ati Radeon 9250 hardware, measured one by one by me. If you use that data for your modeline calculations, you can predict the resulting vfreq with extreme accuracy.

Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 09, 2010, 12:59:51 pm
Hi bitbytebit,

These are great news! I suspected there was something odd with Linux modeline management. And yes, I also found some strange behaviour when invoking games from SDLMame menu, the ini options weren't read or used as expected, or just were properly used for the first one... though I did these tests some time ago and I can't remember exactly what was wrong...

This is a patch I used over CabMame diffs, its related to Emuspeed patch and I use it to prompt the real emulation speed in Hz, with several decimals, and the average speed. It is useful in combination with vsync to see if the vfreq intended is actually working:

Code: [Select]

Go to \src\emu\video.c

/*-------------------------------------------------
    Patch for prompting emulation speed in Hz
    This was done for v0.131, it may need updating
    - Calamity -

    video_get_speed_text - print the text to
    be displayed in the upper-right corner
-------------------------------------------------*/

const char *video_get_speed_text(running_machine *machine)
{
int paused = mame_is_paused(machine);
static char buffer[1024];
char *dest = buffer;
float rate;
screen_state *state = NULL;

/* validate */
assert(machine != NULL);

/* if we're paused, just display Paused */
if (paused)
dest += sprintf(dest, "paused");

/* if we're fast forwarding, just display Fast-forward */
else if (global.fastforward)
dest += sprintf(dest, "fast ");

/* if we're auto frameskipping, display that plus the level */
else if (effective_autoframeskip(machine))
dest += sprintf(dest, "auto%2d/%d", effective_frameskip(), MAX_FRAMESKIP);

/* otherwise, just display the frameskip plus the level */
else
dest += sprintf(dest, "skip %d/%d", effective_frameskip(), MAX_FRAMESKIP);

/* append the speed for all cases except paused */

if (machine->primary_screen != NULL)
state = get_safe_token(machine->primary_screen);

rate = (state != NULL) ? ATTOSECONDS_TO_HZ(state->frame_period) : DEFAULT_FRAME_RATE;

if (!paused && global.overall_emutime.seconds >= 2)
{
osd_ticks_t tps = osd_ticks_per_second();
double average_real_time = (double)global.overall_real_seconds + (double)global.overall_real_ticks / (double)tps;
double average_emu_time = attotime_to_double(global.overall_emutime);

dest += sprintf(dest, " %4.2f%% %4.6f/%4.6f Hz [%4.6f]", 100 * global.speed_percent, global.speed_percent * rate, rate, average_emu_time / average_real_time * rate);


        }
/* display the number of partial updates as well */
if (global.partial_updates_this_frame > 1)
dest += sprintf(dest, "\n%d partial updates", global.partial_updates_this_frame);

/* return a pointer to the static buffer */
return buffer;
}

If you are going to dig in the modeline calculations for Ati Radeon, this will be of your interest: if you download the package from the link I pasted in my firt post, you'll find a file named Ati9250.txt. Inside there's the list of the real dotclocks used by Ati Radeon 9250 hardware, measured one by one by me. If you use that data for your modeline calculations, you can predict the resulting vfreq with extreme accuracy.



Thanks, I am sure those will help things.  I've been able to hack the Radeon driver and basically replace the modeline calculations it does with lrmc's.  So essentially I put lrmc into the Radeon driver and it no longer uses the default Xorg modeline calculator.  I figured out that what is happening is now X Windows basically does all the modeline calculations no matter what you put as modelines, it overrides users input and they aren't even done in the driver usually but in the X Server itself.  They aren't really even radeon specific calculations, they just take the string of modenames and assume they are heightxwidth's and use 60 Hz for each one in basically the cvt program or "Calculates VESA CVT (Coordinated Video Timing) modelines for use with X.", which is not a good thing to use for Arcade monitors or anything low resolution. 

I've now am actually getting the exact modelines running, and looks like I was working uphill before because now a lot of the work arounds I was doing probably are not doing some odd stuff, because I couldn't escape the Vertical Frequency of 60Hz they forced and now I can get anywhere from 40 - 100 like the specs of the d9800 say.  I'm going to play around with this, figure out more and hopefully soon will have a modified Radeon driver that could be used with any Arcade monitor or TV with LRMC doing the calculations inside it.  Also should be able to specify the Monitor type in the xorg.conf file also this does allow you to have an lrmc.conf file in /etc/lrmc.conf or the current working directory to change custom settings for lrmc.  I think I can merge the X Windows Vertical/Horizontal config to do that for lrmc, and we should have a full on X Server for Arcade Monitors for Radeon cards. 

I'm still learning about the timing stuff, so will look into the timing settings you sent too and try to figure out how to improve things with those.  Definitely interesting, I'm surprised I was able to get it working, and looks like hopefully if Mame isn't already able to push a vertical frequency into it in the future we probably can put the xRandr support into there and do it that way.  At least seems that way, supposidly SDL can do it and maybe it already does and I just didn't connect the code.

It's funny when you look through google at this issue with the X Drivers, turns out there are tons of people finding they can't set modelines anymore and no one knows why, the developers are ignoring them saying the monitors should do the EIDID stuff instead.  In the code it seems like in theory it should be reading the whole settings of the modelines but when you trace it they seem to skip that part or something now.
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: Calamity on October 09, 2010, 03:48:46 pm
I've been able to hack the Radeon driver and basically replace the modeline calculations it does with lrmc's.  So essentially I put lrmc into the Radeon driver and it no longer uses the default Xorg modeline calculator.

That's a big achievement! So you have direct control on the Radeon driver, and can set the code to calculate a modeline on the fly with the parameters you define... I wish I had that on Windows ;)

I figured out that what is happening is now X Windows basically does all the modeline calculations no matter what you put as modelines, it overrides users input and they aren't even done in the driver usually but in the X Server itself.  They aren't really even radeon specific calculations, they just take the string of modenames and assume they are heightxwidth's and use 60 Hz for each one in basically the cvt program or "Calculates VESA CVT (Coordinated Video Timing) modelines for use with X.", which is not a good thing to use for Arcade monitors or anything low resolution.

Amazing. Now I understand why the modelines we used didn't seem to work as expected. What sounds strange to me is that if CVT is being used you shouldn't be getting a stable picture on an arcade monitor, as sync pulses are way too different... at least it wouldn't work on my Hantarex MTC9110 (lowres only). Maybe yours is more tolerant?

It's funny when you look through google at this issue with the X Drivers, turns out there are tons of people finding they can't set modelines anymore and no one knows why, the developers are ignoring them saying the monitors should do the EIDID stuff instead.  In the code it seems like in theory it should be reading the whole settings of the modelines but when you trace it they seem to skip that part or something now.

It's incredible all the modeline stuff is bypassed in practice, really amazing. That's is a great discovery.
If you end up getting it to work this is going to be a perfect support for emulation, I will consider to move to Linux  ;D

I haven't looked at lrmc code and don't know how it calculates modelines. Most modeline calculators I've seen use percentages to work out the borders size and sync pulses. I find it not very accurate. I think it's a better aproach to work with characters (integer 8 pixel blocks) instead of pixels for the inner calculations, and define the porchs and sync pulses as time data, then work out the number of those characters we need to achieve these timings. This is the method I implemented, however I harcoded it for lowres, no multisync support. Anyway, this is not important now.

When I have the time I have to make a list of Mame games which resolution is badly reported by xml, I've come up with many. I've been considering doing a patch for this.

Thanks for all the effort!
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 09, 2010, 08:13:38 pm
I've been able to hack the Radeon driver and basically replace the modeline calculations it does with lrmc's.  So essentially I put lrmc into the Radeon driver and it no longer uses the default Xorg modeline calculator.

That's a big achievement! So you have direct control on the Radeon driver, and can set the code to calculate a modeline on the fly with the parameters you define... I wish I had that on Windows ;)

I figured out that what is happening is now X Windows basically does all the modeline calculations no matter what you put as modelines, it overrides users input and they aren't even done in the driver usually but in the X Server itself.  They aren't really even radeon specific calculations, they just take the string of modenames and assume they are heightxwidth's and use 60 Hz for each one in basically the cvt program or "Calculates VESA CVT (Coordinated Video Timing) modelines for use with X.", which is not a good thing to use for Arcade monitors or anything low resolution.

Amazing. Now I understand why the modelines we used didn't seem to work as expected. What sounds strange to me is that if CVT is being used you shouldn't be getting a stable picture on an arcade monitor, as sync pulses are way too different... at least it wouldn't work on my Hantarex MTC9110 (lowres only). Maybe yours is more tolerant?

Yeah it's definitely more tolerant, this d9800 has the ability to go 15.250-40Khz horizontal and 40-100Hz vertical, it actually officially supports CGA/EGA/VGA/SVGA.  They have 4 clock ranges within the horizontal for each of those video types, having a tolerance of a Khz or so, like 15.250-16.750, 24-26, 31-32, 35-39 from what I can tell.  The SVGA support is new in the 9800 compared to the 9200, which is was not official, so I haven't seen much on it but I can say it can do a basic 800x600@60 and 39Khz which looks dang nice (they have a 37Khz in the manual for SVGA, it looks ok like that, but think the extra few Khz make quite a difference).  So it was able to handle it and I was being robbed of the ability to really utilize it, makes sense now why I was seeing it not work for all the d9200 modelines produced by lrmc because it was stuck being around 58-60 Hz by the Radeon driver.  I'm just right now getting back to actually looking at the games more with the X driver now, took me all night to hack it with lrmc, but so far it's pretty darn good and there's a few oddities that probably are the things I was doing to work around the Radeon drivers limitations, and now they are not so good with it actually willing to go down to lower horizontal frequencies. 

Also with lrmc of course it's able to be set to strict ega/cga/vga/svga or ntsc/pal modelines too, besides the d9200/d9400/d9800 which are basically taking groups of them being able to handle most all of them.

It's funny when you look through google at this issue with the X Drivers, turns out there are tons of people finding they can't set modelines anymore and no one knows why, the developers are ignoring them saying the monitors should do the EIDID stuff instead.  In the code it seems like in theory it should be reading the whole settings of the modelines but when you trace it they seem to skip that part or something now.

It's incredible all the modeline stuff is bypassed in practice, really amazing. That's is a great discovery.
If you end up getting it to work this is going to be a perfect support for emulation, I will consider to move to Linux  ;D

Yeah it's definitely going to work, there's the issue of my limited knowledge of the algorithms for these resolutions, I've been letting lrmc do the math and I know basically about video resolutions from my experience working with NTSC/ATSC video encoding for my jobs and was a broadcast engineer in the past although I was mostly the computer guy for them learning about the TV stuff.

I haven't looked at lrmc code and don't know how it calculates modelines. Most modeline calculators I've seen use percentages to work out the borders size and sync pulses. I find it not very accurate. I think it's a better aproach to work with characters (integer 8 pixel blocks) instead of pixels for the inner calculations, and define the porchs and sync pulses as time data, then work out the number of those characters we need to achieve these timings. This is the method I implemented, however I harcoded it for lowres, no multisync support. Anyway, this is not important now.

When I have the time I have to make a list of Mame games which resolution is badly reported by xml, I've come up with many. I've been considering doing a patch for this.

Thanks for all the effort!

lrmc is interesting, but I'm wondering if your knowledge combined with what I have would solve the minor games here and there which I can't get to work through mass algorithms trying to automate setting modelines for them all.  How there's always a few here and there that look good one method and switch to looking a little off when others that were good then go a little off with another method.  I'm trying to find the logic for each of those cases, there's really not tons of them cause mostly groups of types of games will have the same issues.

I've wondered about the games not all having correct information, definitely can see some that the info just doesn't seem right and it's hard to get the to display nicely.  Also the pixelclock values are there for some, but when I try to use that in my calculations which I can do in lrmc as a minimum, it just makes some games become too small on the screen.

Hopefully I'll clean this radeon driver up over the weekend and have it posted here in a few days, you can then see directly the things lrmc does and what I have done to make it not use the generic VESA calculations it forced on everybody in the last few years.  I'm figuring out how to add variables to the xorg.conf file so I can have the monitor chosen, utilize the freq variables for H/V that the x driver has available to input to lrmc, improve my d9800 support now that I finally have it really being given the modelines I made for it directly, and possibly ways to dynamically have the radeon driver either dynamically calculate games modelines or use the xrandr to talk with mame better, possibly try to simplify having so many ini files or something there.  Just seems like this should be able to get much simpler now that we can work with the X driver instead of working around it and weren't able to touch the actual hardware though our modelines before.   

It's definitely fun to work on this, started this arcade cabinet as a project for myself and had to use Linux cause that's all I ever have used for anything, which has led me on a mission to share what I am doing for myself which I want to basically make this stuff work on Linux as good as Windows.  Oddly I'm surprised that it seems we probably already  have surpassed Windows in some ways because of the ability to really access the hardware directly through the X server, have unlimited modelines, and not have any doors permanently closed so pretty much should only be limited by what the hardware really can do and time it takes to program it.

Thanks,
Chris

Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: Calamity on October 10, 2010, 07:25:19 am
Back in a minute...
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: Calamity on October 10, 2010, 07:56:09 am
I've wondered about the games not all having correct information, definitely can see some that the info just doesn't seem right and it's hard to get the to display nicely.  Also the pixelclock values are there for some, but when I try to use that in my calculations which I can do in lrmc as a minimum, it just makes some games become too small on the screen.

Pixelclock values in mame.xml as well as porch values are precious information by their own, and also if we intended to replicate the exact original video signal, but I'm afraid this is not the way to go if we want to have hundreds of games simultaneously centered on the monitor, so we must redefine the pixelclock for each video mode resulting for the porchs (borders) we want to have, which should be as constant as possible among different video modes, to avoid having to be adjusting our monitor all the time (this is only possible with horizontal borders, vertical amplitud must be adjusted manually). At the same time we have to keep our vertical frequency as close as possible to the original.

It's definitely fun to work on this, started this arcade cabinet as a project for myself and had to use Linux cause that's all I ever have used for anything, which has led me on a mission to share what I am doing for myself which I want to basically make this stuff work on Linux as good as Windows.  Oddly I'm surprised that it seems we probably already  have surpassed Windows in some ways because of the ability to really access the hardware directly through the X server, have unlimited modelines, and not have any doors permanently closed so pretty much should only be limited by what the hardware really can do and time it takes to program it.

Definitely that functionallity is not available in Windows. Well, I have managed to trick the Catalsyt video driver to "reset" itself on the fly so it will read the registry modelines without the need of rebooting, so I would eventually have unlimited modelines also in Windows, but I still have to figure out how to make this available for different emulators (I believe the only option is a sort of loader), and definitely your Linux method is much cleaner and straightforward.

My biggest concern with Linux and the X Radeon driver is if you can really achieve a proper Vsync functionallity. I have heard there were problems with these cards and vsync, I hope it's been solved. Some folks had problems with this in the Spanish forum:

http://www.retrovicio.com/foro/showthread.php?t=8250&highlight=investigaci%C3%B3n (http://www.retrovicio.com/foro/showthread.php?t=8250&highlight=investigaci%C3%B3n)

Thanks for the good work!



Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 10, 2010, 03:53:39 pm
My biggest concern with Linux and the X Radeon driver is if you can really achieve a proper Vsync functionallity. I have heard there were problems with these cards and vsync, I hope it's been solved. Some folks had problems with this in the Spanish forum:

http://www.retrovicio.com/foro/showthread.php?t=8250&highlight=investigaci%C3%B3n (http://www.retrovicio.com/foro/showthread.php?t=8250&highlight=investigaci%C3%B3n)

Thanks for the good work!
You know I bet they were just running into the modeline issue, because from what I can tell no one has been able to really insert Arcade modelines that are anything different than 58-60Hz refresh rates, Xorg has been ignoring them silently (turn on debugging it they don't show, VESA modified ones show up instead using just the WxH).  So I suspect from what I can tell Vsync works decently, ever since I modfied the driver to create the modelines itself.  From what I see in the source, and read that all the other Xorg drivers besides the ATI one do this too, people have been wasting time creating modelines and thinking they were actually telling the X driver to do more than choose that Width and Height combo at 60Hz.  Seems weird, but does explain what we both have seen and so most likely makes the people in that thread having issues from this same problem I have found.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: ves on October 11, 2010, 04:31:25 am
Hi, I have several questions, what happened to the diff nativeres.diff cabmame.diff and are no longer needed?
what version of mame you are using to implement the new diff? as I tried to apply the diff to the version 139u3 because they always give an error, I have proven with the 139 version where if you run the 0139u3_frogger.diff and hi_139-linux.diff, but hi_dat_dir.diff does not work as a missing hiscore.c because there is, because it can be? but you lack any diff? what you may be using a version of cabmame to deploy your patches and therefore in a official mame not work?

With respect to the Ati driver version you're using Xorg, kernel and linux distribution?



Thanks.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: bitbytebit on October 11, 2010, 04:47:26 am
Hi, I have several questions, what happened to the diff nativeres.diff cabmame.diff and are no longer needed?
what version of mame you are using to implement the new diff? as I tried to apply the diff to the version 139u3 because they always give an error, I have proven with the 139 version where if you run the 0139u3_frogger.diff and hi_139-linux.diff, but hi_dat_dir.diff does not work as a missing hiscore.c because there is, because it can be? but you lack any diff? what you may be using a version of cabmame to deploy your patches and therefore in a official mame not work?

With respect to the Ati driver version you're using Xorg, kernel and linux distribution?



Thanks.

The cabmame patch was just a quick try at porting it, but I realized it really wasn't working as expected and those cabmame patches in general need more detailed work to fit into the SDL code.  The nativeres patch didn't seem to do anything different with it applied, and when looking at the code it really seems to not even fit in with switchres enabled which all this is made to work with.  So those patches are no longer needed, the newer patches I have basically need to be applied in order in Mame 0.139u3 and that hi_dat_dir.diff needs to be applied last after the other 2 because it changes the first hiscore patch slightly.  Also you need to apply the hiscore patch from http://forum.arcadecontrols.com/index.php?topic=64298.0 (http://forum.arcadecontrols.com/index.php?topic=64298.0) first before my Linux hiscore patch, it's based off that patch.  I should have made that more clear, all the patches essentially are just extra too though and the lrmc/ATI driver of course only slightly need the frogger patch and that's if you want to display galaxian/frogger in closer to native res too.

So basically first apply the patch from http://mamestuff.lowtrucks.net/MKChamp/hi_139u3.txt (http://mamestuff.lowtrucks.net/MKChamp/hi_139u3.txt)
Then apply the 0139u3_frogger.diffpatch
Then apply the hi_139-linux.diff patch
Then apply the hi_dat_dir.diff patch

This should be on a clean 0139u3 version of Mame.

The ATI driver is just the Xorg one without any distribution specifics, version 6.13.0 of that ati driver and version 1.7.7 of the xorg-server (although I think the ati driver is somewhat version independent hopefully).  I think it should work on any newer 2.6 kernel.  The original ati driver comes from here: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/ (http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/)  and taking the vanilla version of 6.13.0 and doing a diff against it, then applying that diff to any other version newer of the ati driver, in theory should allow applying it to other versions of the ati driver.  I use Gentoo and just pulled the original sources tarballs for it from what portage downloaded and worked off that, so this is the original xf86-video-ati-6.13.0 driver basically just with the lrmc changes to it.



Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: ves on October 11, 2010, 05:21:11 am
Hello, for anyone who is interested in compiling the driver etc. .. I leave from ubuntu packages needed to compile the driver Ati.
x11proto-DRI2-dev_2.3-1_all.deb
x11proto-fonts-dev_2.1.0-1_all.deb
x11proto-video-dev_2.3.0-1_all.deb
x11proto-xf86dri-dev_2.1.0-1_all.deb
xserver-xorg-Dev_2 :1.9.0-0ubuntu7_i386. deb

In order to compile mame I had to patch from windows with the original mame u1, u2, u3, and hiscore.diff, after that I could apply your patches and I was able to compile it (it is compiling yet), now just need to try it I'll tell you how it works.

It is possible to patch from linux with the original mame updates u1, u2, u3? as with the command patch -p1 < 0139u1.diff or patch -p0 -E < 0139u1.diff etc. .. always fails, as can be done from linux?

Any suggestions for using this with a monitor HANTAREX 9110?



Thanks.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: bitbytebit on October 11, 2010, 05:30:56 am
Hello, for anyone who is interested in compiling the driver etc. .. I leave from ubuntu packages needed to compile the driver Ati.
x11proto-DRI2-dev_2.3-1_all.deb
x11proto-fonts-dev_2.1.0-1_all.deb
x11proto-video-dev_2.3.0-1_all.deb
x11proto-xf86dri-dev_2.1.0-1_all.deb
xserver-xorg-Dev_2 :1.9.0-0ubuntu7_i386. deb

In order to compile mame I had to patch from windows with the original mame u1, u2, u3, and hiscore.diff, after that I could apply your patches and I was able to compile it (it is compiling yet), now just need to try it I'll tell you how it works.

It is possible to patch from linux with the original mame updates u1, u2, u3? as with the command patch -p1 < 0139u1.diff or patch -p0 -E < 0139u1.diff etc. .. always fails, as can be done from linux?

Any suggestions for using this with a monitor HANTAREX 9110?



Thanks.
Escuchar
Leer fonéticamente

I use -p0 -E as options to patch, and from within the mame source directory itself.  With that monitor, if it's strict CGA then in the xorg.conf file you want the ArcadeMonitor Option to be set to cga instead of the current d9800 it is (inside the xorg/xorg.conf-top template).  Also when running the ./genres script use the -cga option for it, and with the patches add the -ff option for the frogger patch too.  Check the xorg/ templates to customize them to what your xorg.conf setup needs (I'm guessing it's pretty generic for these ati cards). 

What are the monitor specs, specific Vertical and Horizontal ranges and pclock range?  If your outside these CGA specs: 'Clock = 8 - 25 / 15.75 / 50 - 60' which is the lrmc default for a CGA monitor, you'll need to have a custom /etc/lrmc.conf file with the specs in it in that same format, or run lrmc -default and it'll write out a default lrmc.conf and you can edit it for your monitor and put it into /etc/lrmc.conf.  Seems the lrmc.conf file is an interesting way to really make the ati driver able to choose custom modelines to the fit monitor type, when outside the ArcadeMonitor options of cga/ega/vga/multi/d9800/d9200. 

Definitely interesting to see how it works with a pure arcade monitor, instead of my d9800.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: Calamity on October 11, 2010, 05:35:24 am
Hi VeS,

It's great you've been able to build it, now it's time to test. I highly recommend you to include the patch for Mame that I pasted above (just the second one), in order to see the real emulation speed (e.g. [59.763 Hz]) when you press F9.

Regarding to Hantarex 9110 + ArcadeVGA, I believe it'll be necessary to make an specific lrmc.conf file, as -cga option may not fit here. The timings I've been using for the Hantarex MTC9110, translated to this lrmc format, would be:

Clock = 3.75 - 25 / 15.625 - 16.650 / 49.50 - 65.00

It's very important to be able to reach this low dotclock (around 3.75), otherwise lower resolutions would have huge porchs (borders).
Just to clarify things, this dotclock thing (3.75-25) is videocard related, not a monitor feature. ArcadeVGA and Radeon 9250 can be set for very low dotclocks, thus these cards are suitable for emulation. Many newer cards do not allow dotclocks as low as 3.75 MHz (some do).

Thanks

Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: Calamity on October 11, 2010, 06:00:57 am
Sorry, I duplicated my last post...
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: bitbytebit on October 11, 2010, 06:08:39 am
Hi VeS,

It's great you've been able to build it, now it's time to test. I highly recommend you to include the patch for Mame that I pasted above (just the second one), in order to see the real emulation speed (e.g. [59.763 Hz]) when you press F9.

Regarding to Hantarex 9110 + ArcadeVGA, I believe it'll be necessary to make an specific lrmc.conf file, as -cga option may not fit here. The timings I've been using for the Hantarex MTC9110, translated to this lrmc format, would be:

Clock = 3.75 - 25 / 15.625 - 16.650 / 49.50 - 65.00

It's very important to be able to reach this low dotclock (around 3.75), otherwise lower resolutions would have huge porchs (borders).
Just to clarify things, this dotclock thing (3.75-25) is videocard related, not a monitor feature. ArcadeVGA and Radeon 9250 can be set for very low dotclocks, thus these cards are suitable for emulation. Many newer cards do not allow dotclocks as low as 3.75 MHz (some do).

Thanks



It's interesting about the lower dotclock, there's some limitations I can remove but not sure if they are really actively limiting things.  First is the radeon driver, it claimed normally it could only go down to 12Mhz and I lowered this to 5Mhz in my patch.  I can it just allow any dotclock asked for, but not sure if that really is a hard limit in the driver and the value is really used.  I'll look at this value closer in the driver, one of the many little things I've been wanting to do, since it seems like the ati radeon driver has so many limitations on the hardware like the modelines or the dotclock which the actual hardware doesn't really have.  I always wondered why that xorg.conf setting of lowering the dotclock was sometimes used and sometimes not in peoples configs, it may be another xorg.conf setting that is either ignored or less intuitive on how it's actually used.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: bitbytebit on October 11, 2010, 06:24:42 am
Hi VeS,

It's great you've been able to build it, now it's time to test. I highly recommend you to include the patch for Mame that I pasted above (just the second one), in order to see the real emulation speed (e.g. [59.763 Hz]) when you press F9.

Regarding to Hantarex 9110 + ArcadeVGA, I believe it'll be necessary to make an specific lrmc.conf file, as -cga option may not fit here. The timings I've been using for the Hantarex MTC9110, translated to this lrmc format, would be:

Clock = 3.75 - 25 / 15.625 - 16.650 / 49.50 - 65.00

It's very important to be able to reach this low dotclock (around 3.75), otherwise lower resolutions would have huge porchs (borders).
Just to clarify things, this dotclock thing (3.75-25) is videocard related, not a monitor feature. ArcadeVGA and Radeon 9250 can be set for very low dotclocks, thus these cards are suitable for emulation. Many newer cards do not allow dotclocks as low as 3.75 MHz (some do).

Thanks



It's interesting about the lower dotclock, there's some limitations I can remove but not sure if they are really actively limiting things.  First is the radeon driver, it claimed normally it could only go down to 12Mhz and I lowered this to 5Mhz in my patch.  I can it just allow any dotclock asked for, but not sure if that really is a hard limit in the driver and the value is really used.  I'll look at this value closer in the driver, one of the many little things I've been wanting to do, since it seems like the ati radeon driver has so many limitations on the hardware like the modelines or the dotclock which the actual hardware doesn't really have.  I always wondered why that xorg.conf setting of lowering the dotclock was sometimes used and sometimes not in peoples configs, it may be another xorg.conf setting that is either ignored or less intuitive on how it's actually used.

I need to look at the way lrmc in the radeon driver will do the lrmc.conf file reading, just realized it may ignore that file because I have it so the option in xorg.conf gives a monitor type.  I need an option I guess to use the config file, actually wish I could use the xorg.conf settings for the Vert/Horz rates but oddly I can't seem to get that information from the driver.  That would be ideal, all setup in xorg.conf, and seems strange to need to add another settting for those values instead of using the default ones already in xorg.conf.  This is definitely interesting, have to figure out the simplest way to pass this information through, wish the modelines were actually read by the driver to begin with and it would simplify things greatly.  I'm planning on trying to find out if that information is even available to me, may be like the horz/vert values where the driver seems cutoff from the main xserver and the config file reading seems to be split up between xorg parts.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: Calamity on October 11, 2010, 06:31:16 am
It's interesting about the lower dotclock, there's some limitations I can remove but not sure if they are really actively limiting things.  First is the radeon driver, it claimed normally it could only go down to 12Mhz and I lowered this to 5Mhz in my patch.  I can it just allow any dotclock asked for, but not sure if that really is a hard limit in the driver and the value is really used.  I'll look at this value closer in the driver, one of the many little things I've been wanting to do, since it seems like the ati radeon driver has so many limitations on the hardware like the modelines or the dotclock which the actual hardware doesn't really have.  I always wondered why that xorg.conf setting of lowering the dotclock was sometimes used and sometimes not in peoples configs, it may be another xorg.conf setting that is either ignored or less intuitive on how it's actually used.

A 5 MHz dotclock is low enough for a 240x240@60 video mode, e.g.:

Modeline "240x240@60.0Hz 15.7KHz (60Hz)" 5.010 240 256 280 320 240 241 244 261 -hsync -vsync

However, it's understandable they limit it in the Radeon driver as it's generic and many Ati cards can't use these low dotclocks.
I wonder which options are available from lrmc.conf (I'd like to get a blank template to adapt it to MTC 9110).

Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: bitbytebit on October 11, 2010, 06:35:31 am
It's interesting about the lower dotclock, there's some limitations I can remove but not sure if they are really actively limiting things.  First is the radeon driver, it claimed normally it could only go down to 12Mhz and I lowered this to 5Mhz in my patch.  I can it just allow any dotclock asked for, but not sure if that really is a hard limit in the driver and the value is really used.  I'll look at this value closer in the driver, one of the many little things I've been wanting to do, since it seems like the ati radeon driver has so many limitations on the hardware like the modelines or the dotclock which the actual hardware doesn't really have.  I always wondered why that xorg.conf setting of lowering the dotclock was sometimes used and sometimes not in peoples configs, it may be another xorg.conf setting that is either ignored or less intuitive on how it's actually used.

A 5 MHz dotclock is low enough for a 240x240@60 video mode, e.g.:

Modeline "240x240@60.0Hz 15.7KHz (60Hz)" 5.010 240 256 280 320 240 241 244 261 -hsync -vsync

However, it's understandable they limit it in the Radeon driver as it's generic and many Ati cards can use these low dotclocks.
I wonder which options are available from lrmc.conf (I'd like to get a blank template to adapt it to MTC 9110).


lrmc.conf can change the interlace, doublescan, stretch, vsync values used in lrmc

I'm guessing it may be best just to use the lrmc.conf file instead of adding more settings to xorg.conf, so lrmc and the radeon driver will definitely use the same settings to calculate modelines.  Hopefully I can figure out how to make it just read the modelines again properly and then we'd not have to worry about reading lrmc.conf from the x driver.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: bitbytebit on October 11, 2010, 07:08:11 am
Hi VeS,

It's great you've been able to build it, now it's time to test. I highly recommend you to include the patch for Mame that I pasted above (just the second one), in order to see the real emulation speed (e.g. [59.763 Hz]) when you press F9.

Regarding to Hantarex 9110 + ArcadeVGA, I believe it'll be necessary to make an specific lrmc.conf file, as -cga option may not fit here. The timings I've been using for the Hantarex MTC9110, translated to this lrmc format, would be:

Clock = 3.75 - 25 / 15.625 - 16.650 / 49.50 - 65.00

It's very important to be able to reach this low dotclock (around 3.75), otherwise lower resolutions would have huge porchs (borders).
Just to clarify things, this dotclock thing (3.75-25) is videocard related, not a monitor feature. ArcadeVGA and Radeon 9250 can be set for very low dotclocks, thus these cards are suitable for emulation. Many newer cards do not allow dotclocks as low as 3.75 MHz (some do).

Thanks



It's interesting about the lower dotclock, there's some limitations I can remove but not sure if they are really actively limiting things.  First is the radeon driver, it claimed normally it could only go down to 12Mhz and I lowered this to 5Mhz in my patch.  I can it just allow any dotclock asked for, but not sure if that really is a hard limit in the driver and the value is really used.  I'll look at this value closer in the driver, one of the many little things I've been wanting to do, since it seems like the ati radeon driver has so many limitations on the hardware like the modelines or the dotclock which the actual hardware doesn't really have.  I always wondered why that xorg.conf setting of lowering the dotclock was sometimes used and sometimes not in peoples configs, it may be another xorg.conf setting that is either ignored or less intuitive on how it's actually used.

I need to look at the way lrmc in the radeon driver will do the lrmc.conf file reading, just realized it may ignore that file because I have it so the option in xorg.conf gives a monitor type.  I need an option I guess to use the config file, actually wish I could use the xorg.conf settings for the Vert/Horz rates but oddly I can't seem to get that information from the driver.  That would be ideal, all setup in xorg.conf, and seems strange to need to add another settting for those values instead of using the default ones already in xorg.conf.  This is definitely interesting, have to figure out the simplest way to pass this information through, wish the modelines were actually read by the driver to begin with and it would simplify things greatly.  I'm planning on trying to find out if that information is even available to me, may be like the horz/vert values where the driver seems cutoff from the main xserver and the config file reading seems to be split up between xorg parts.
Code: [Select]
diff --git a/xf86-video-ArcadeVGA-6.13.0/src/radeon.h b/xf86-video-ArcadeVGA-6.13.0/src/radeon.h
index 7d84eab..96248f9 100644
--- a/xf86-video-ArcadeVGA-6.13.0/src/radeon.h
+++ b/xf86-video-ArcadeVGA-6.13.0/src/radeon.h
@@ -451,6 +451,7 @@ typedef enum {

 typedef enum {
     RADEON_ARCADE_NONE,
+    RADEON_ARCADE_LRMC,
     RADEON_ARCADE_CGA,
     RADEON_ARCADE_EGA,
     RADEON_ARCADE_VGA,
diff --git a/xf86-video-ArcadeVGA-6.13.0/src/radeon_output.c b/xf86-video-ArcadeVGA-6.13.0/src/radeon_output.c
index ae4317d..5c4ab80 100644
--- a/xf86-video-ArcadeVGA-6.13.0/src/radeon_output.c
+++ b/xf86-video-ArcadeVGA-6.13.0/src/radeon_output.c
@@ -2891,7 +2891,9 @@ Bool RADEONSetupConnectors(ScrnInfoPtr pScrn)
     info->ArcadeMonitor = 0; /* Default is CGA */
     optstr = (char *)xf86GetOptValString(info->Options, OPTION_ARCADE_MONITOR);
     if (optstr) {
-       if (!strncmp("cga", optstr, strlen("cga")))
+       if (!strncmp("lrmc", optstr, strlen("lrmc")))
+            info->ArcadeMonitor = RADEON_ARCADE_LRMC;
+       else if (!strncmp("cga", optstr, strlen("cga")))
             info->ArcadeMonitor = RADEON_ARCADE_CGA;
         else if (!strncmp("ega", optstr, strlen("ega"))) /* alias */
             info->ArcadeMonitor = RADEON_ARCADE_EGA;

Quick patch to the radeon driver to allow you to set the ArcadeMonitor setting in xorg.conf to "lrmc" and then it'll read the /etc/lrmc.conf file for the monitor specs.

Also I'm starting to see how to get the other values from the xorg.conf file so hopefully can just read the modelines from it and we'll not need to compute them anymore inside the driver itself, which would simplify needing calculate them twice at ini file creation and then again from the labels on starting X.  Which is what we wanted of course the driver to do in the first place and everyone *thinks* it already does. 
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: ves on October 11, 2010, 07:12:50 am
Hi, I have everything compiled but I can not even try, I have several questions, where is the lrm.conf? I have not found on any site, when you say to try the "Clock = 3.75 - 25 / 15625-16650 / 49.50 - 65.00" This is put in the xorg.conf, right?
I would have to change
Code: [Select]
HorizSync    15.625 - 16.650
VertRefresh  49.00 - 65.00
--------------------------------------------
Option           "ForceMinDotClock" "3.75MHz"


When creating the xorg.conf me to believe so, I have given the following options "genres -cga -ff"

Code: [Select]
Section "ServerLayout"
        Identifier     "X.org Configured"
        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 "Files"
        ModulePath   "/usr/lib/xorg/modules"
        FontPath     "/usr/share/fonts/misc/"
        FontPath     "/usr/share/fonts/TTF/"
        FontPath     "/usr/share/fonts/OTF"
        FontPath     "/usr/share/fonts/Type1/"
        FontPath     "/usr/share/fonts/100dpi/"
        FontPath     "/usr/share/fonts/75dpi/"
EndSection

Section "Module"
        #Load  "FGL.renamed.libglx"
        Load  "glx"
        Load  "extmod"
        Load  "dbe"
        Load  "dri2"
        Load  "dri"
        Load  "record"
        SubSection "extmod"
                Option          "omit DPMS"
        EndSubSection
EndSection

Section "ServerFlags"
        Option          "AIGLX" "on"
        AllowMouseOpenFail
    Option       "Dont Zoom"
    Option         "NoDDC"
    Option         "UseEdidFreqs" "0"
    Option         "IgnoreEDID" "1"
    Option         "TMDS" "0"
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

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Wells Gardner"
        ModelName    "D9800"
        HorizSync    15.250 - 16.75, 24.00 - 26.00, 31.00 - 32.00, 37-40
        VertRefresh  47.00 - 85.00

    Option "DPMS"        "false"
EndSection

Section "Device"
        Option           "ForceMinDotClock" "5MHz"
    Option              "ModeDebug" "true"
    Option         "NoDDC"
    Option         "IgnoreEDID" "on"
    #
    Option          "ArcadeMonitor"  "d9800"
        #
        Identifier  "Card0"
        Driver      "radeon"
        VendorName  "ATI Technologies Inc"
        BoardName   "Unknown Board"
        BusID       "PCI:1:0:0"

EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        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

                Modes "800x576x24.96" "792x480x30.00" "768x256x56.25" "768x240x60.11" "760x576x25.04" "744x486x29.66" "744x288x50.00" "744x240x60.11" "736x264x54.50" "720x480x30.00" "720x240x60.11" "712x512x28.07" "712x288x50.00" "704x480x30.00" "704x240x60.11" "696x488x29.66" "696x480x30.00" "688x512x28.07" "688x500x28.79" "672x524x27.49" "672x506x28.58" "672x480x30.00" "672x240x60.11" "656x240x60.11" "648x504x28.58" "648x502x28.69" "648x498x28.79" "648x240x60.11" "640x482x30.00" "640x480x30.00" "640x478x30.00" "640x288x50.00" "640x256x56.25" "640x240x60.11" "632x496x29.01" "632x478x30.00" "624x524x27.58" "624x486x29.66" "624x480x30.00" "624x478x30.00" "616x558x25.78" "616x480x30.00" "616x288x50.00" "608x480x30.00" "600x288x50.00" "600x240x60.11" "592x532x27.02" "592x480x30.00" "584x520x27.58" "576x578x25.04" "576x518x27.78" "576x504x28.58" "576x288x50.00" "568x480x30.00" "568x478x30.00" "560x504x28.58" "560x502x28.79" "560x500x28.90" "560x498x28.79" "560x484x29.77" "560x280x51.47" "560x243x59.21" "552x496x29.01" "552x480x30.00" "552x240x60.11" "544x486x29.55" "544x480x30.00" "544x240x60.11" "536x514x28.07" "536x482x29.89" "536x478x30.00" "536x240x60.11" "528x488x29.55" "528x480x30.00" "528x478x30.00" "528x288x50.00" "528x261x55.07" "528x245x58.77" "528x244x58.99" "528x240x60.11" "520x504x28.69" "520x240x60.11" "512x576x24.96" "512x512x28.07" "512x504x28.58" "512x480x30.00" "512x288x50.00" "512x256x56.25" "512x254x56.65" "512x252x57.07" "512x240x60.11" "504x488x29.55" "504x486x29.66" "504x484x29.66" "504x482x30.00" "504x482x29.89" "504x288x50.00" "504x250x57.69" "496x480x30.00" "496x478x30.00" "496x240x60.11" "488x576x24.96" "488x488x29.66" "488x480x30.00" "480x480x30.00" "480x478x30.00" "480x288x50.00" "480x240x60.11" "472x262x54.88" "472x243x59.21" "464x288x50.00" "464x261x55.07" "464x248x58.12" "464x240x60.11" "456x578x24.96" "456x576x24.96" "456x512x28.07" "456x480x30.00" "456x288x50.00" "456x256x56.25" "456x255x56.45" "456x252x57.07" "448x252x57.07" "448x251x57.48" "448x240x60.11" "440x257x56.05" "440x256x56.25" "440x253x56.86" "440x252x57.07" "432x512x28.07" "432x288x50.00" "432x280x51.47" "432x276x52.15" "432x264x54.50" "432x257x56.05" "432x256x56.25" "432x253x56.86" "432x252x57.07" "432x251x57.48" "432x248x58.12" "432x240x60.11" "424x512x28.07" "424x480x30.00" "424x288x50.00" "424x272x52.85" "416x288x50.00" "416x267x53.94" "416x266x54.12" "416x262x54.88" "416x256x56.25" "416x243x59.21" "416x241x59.66" "416x240x60.11" "408x266x54.12" "408x253x56.86" "408x252x57.07" "408x240x60.11" "400x512x28.07" "400x288x50.00" "400x280x51.47" "400x272x52.85" "400x264x54.50" "400x260x55.46" "400x257x56.05" "400x256x56.25" "400x253x56.86" "400x252x57.07" "400x251x57.48" "400x250x57.69" "400x248x58.12" "400x240x60.11" "392x243x59.21" "392x240x60.11" "384x576x24.96" "384x288x50.00" "384x256x56.25" "384x248x58.12" "384x240x60.11" "376x288x50.00" "376x280x51.47" "376x259x55.65" "376x240x60.11" "368x266x54.12" "368x257x56.05" "368x256x56.25" "368x240x60.11" "360x288x50.00" "360x272x52.85" "360x266x54.12" "360x251x57.27" "360x250x57.69" "360x248x58.12" "360x240x60.11" "352x288x50.00" "352x261x55.26" "352x261x55.07" "352x256x56.25" "352x248x58.12" "352x244x58.99" "352x243x59.21" "352x242x59.43" "352x240x60.11" "344x512x28.07" "344x258x55.85" "344x256x56.25" "344x241x59.66" "344x240x60.11" "344x240x59.89" "336x257x56.05" "336x252x57.07" "336x251x57.48" "336x250x57.69" "336x248x58.12" "336x244x58.99" "336x243x59.21" "336x240x60.11" "336x240x59.89" "328x244x58.99" "328x243x59.21" "328x241x59.66" "328x240x60.11" "320x256x56.25" "320x255x56.45" "320x248x58.12" "320x240x60.11" "312x288x50.00" "312x243x59.21" "312x241x59.66" "312x240x60.11" "312x240x59.89" "304x266x54.12" "304x241x59.66" "304x240x60.11" "296x288x50.00" "296x260x55.46" "296x257x56.05" "296x256x56.25" "296x255x56.45" "296x253x56.86" "296x240x60.11" "288x288x50.00" "288x266x54.12" "288x252x57.07" "288x250x57.69" "288x248x58.12" "288x240x60.11" "280x258x55.85" "280x243x59.21" "280x242x59.43" "280x241x59.66" "280x240x60.11" "280x240x59.89" "272x256x56.25" "272x252x57.07" "272x251x57.48" "272x248x58.12" "272x241x59.66" "272x240x60.11" "264x261x55.07" "264x248x58.12" "264x243x59.21" "264x241x59.66" "264x240x60.11"
        EndSubSection
EndSection

Would be correct?

I have seen that there is a folder called modes where might modelines (modes_mame.txt modes.txt) in 2 different formats, this folder is used for something? I mean, the used the genre to make the xorg.conf or you have to use those modelines in the xorg.conf manually?




Greetings.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: bitbytebit on October 11, 2010, 07:16:34 am
Hi, I have everything compiled but I can not even try, I have several questions, where is the lrm.conf? I have not found on any site, when you say to try the "Clock = 3.75 - 25 / 15625-16650 / 49.50 - 65.00" This is put in the xorg.conf, right?
I would have to change
Code: [Select]
HorizSync    15.625 - 16.650
VertRefresh  49.00 - 65.00
--------------------------------------------
Option           "ForceMinDotClock" "3.75MHz"


When creating the xorg.conf me to believe so, I have given the following options "genres -cga -ff"

Code: [Select]
Section "ServerLayout"
        Identifier     "X.org Configured"
        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 "Files"
        ModulePath   "/usr/lib/xorg/modules"
        FontPath     "/usr/share/fonts/misc/"
        FontPath     "/usr/share/fonts/TTF/"
        FontPath     "/usr/share/fonts/OTF"
        FontPath     "/usr/share/fonts/Type1/"
        FontPath     "/usr/share/fonts/100dpi/"
        FontPath     "/usr/share/fonts/75dpi/"
EndSection

Section "Module"
        #Load  "FGL.renamed.libglx"
        Load  "glx"
        Load  "extmod"
        Load  "dbe"
        Load  "dri2"
        Load  "dri"
        Load  "record"
        SubSection "extmod"
                Option          "omit DPMS"
        EndSubSection
EndSection

Section "ServerFlags"
        Option          "AIGLX" "on"
        AllowMouseOpenFail
    Option       "Dont Zoom"
    Option         "NoDDC"
    Option         "UseEdidFreqs" "0"
    Option         "IgnoreEDID" "1"
    Option         "TMDS" "0"
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

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Wells Gardner"
        ModelName    "D9800"
        HorizSync    15.250 - 16.75, 24.00 - 26.00, 31.00 - 32.00, 37-40
        VertRefresh  47.00 - 85.00

    Option "DPMS"        "false"
EndSection

Section "Device"
        Option           "ForceMinDotClock" "5MHz"
    Option              "ModeDebug" "true"
    Option         "NoDDC"
    Option         "IgnoreEDID" "on"
    #
    Option          "ArcadeMonitor"  "d9800"
        #
        Identifier  "Card0"
        Driver      "radeon"
        VendorName  "ATI Technologies Inc"
        BoardName   "Unknown Board"
        BusID       "PCI:1:0:0"

EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        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

                Modes "800x576x24.96" "792x480x30.00" "768x256x56.25" "768x240x60.11" "760x576x25.04" "744x486x29.66" "744x288x50.00" "744x240x60.11" "736x264x54.50" "720x480x30.00" "720x240x60.11" "712x512x28.07" "712x288x50.00" "704x480x30.00" "704x240x60.11" "696x488x29.66" "696x480x30.00" "688x512x28.07" "688x500x28.79" "672x524x27.49" "672x506x28.58" "672x480x30.00" "672x240x60.11" "656x240x60.11" "648x504x28.58" "648x502x28.69" "648x498x28.79" "648x240x60.11" "640x482x30.00" "640x480x30.00" "640x478x30.00" "640x288x50.00" "640x256x56.25" "640x240x60.11" "632x496x29.01" "632x478x30.00" "624x524x27.58" "624x486x29.66" "624x480x30.00" "624x478x30.00" "616x558x25.78" "616x480x30.00" "616x288x50.00" "608x480x30.00" "600x288x50.00" "600x240x60.11" "592x532x27.02" "592x480x30.00" "584x520x27.58" "576x578x25.04" "576x518x27.78" "576x504x28.58" "576x288x50.00" "568x480x30.00" "568x478x30.00" "560x504x28.58" "560x502x28.79" "560x500x28.90" "560x498x28.79" "560x484x29.77" "560x280x51.47" "560x243x59.21" "552x496x29.01" "552x480x30.00" "552x240x60.11" "544x486x29.55" "544x480x30.00" "544x240x60.11" "536x514x28.07" "536x482x29.89" "536x478x30.00" "536x240x60.11" "528x488x29.55" "528x480x30.00" "528x478x30.00" "528x288x50.00" "528x261x55.07" "528x245x58.77" "528x244x58.99" "528x240x60.11" "520x504x28.69" "520x240x60.11" "512x576x24.96" "512x512x28.07" "512x504x28.58" "512x480x30.00" "512x288x50.00" "512x256x56.25" "512x254x56.65" "512x252x57.07" "512x240x60.11" "504x488x29.55" "504x486x29.66" "504x484x29.66" "504x482x30.00" "504x482x29.89" "504x288x50.00" "504x250x57.69" "496x480x30.00" "496x478x30.00" "496x240x60.11" "488x576x24.96" "488x488x29.66" "488x480x30.00" "480x480x30.00" "480x478x30.00" "480x288x50.00" "480x240x60.11" "472x262x54.88" "472x243x59.21" "464x288x50.00" "464x261x55.07" "464x248x58.12" "464x240x60.11" "456x578x24.96" "456x576x24.96" "456x512x28.07" "456x480x30.00" "456x288x50.00" "456x256x56.25" "456x255x56.45" "456x252x57.07" "448x252x57.07" "448x251x57.48" "448x240x60.11" "440x257x56.05" "440x256x56.25" "440x253x56.86" "440x252x57.07" "432x512x28.07" "432x288x50.00" "432x280x51.47" "432x276x52.15" "432x264x54.50" "432x257x56.05" "432x256x56.25" "432x253x56.86" "432x252x57.07" "432x251x57.48" "432x248x58.12" "432x240x60.11" "424x512x28.07" "424x480x30.00" "424x288x50.00" "424x272x52.85" "416x288x50.00" "416x267x53.94" "416x266x54.12" "416x262x54.88" "416x256x56.25" "416x243x59.21" "416x241x59.66" "416x240x60.11" "408x266x54.12" "408x253x56.86" "408x252x57.07" "408x240x60.11" "400x512x28.07" "400x288x50.00" "400x280x51.47" "400x272x52.85" "400x264x54.50" "400x260x55.46" "400x257x56.05" "400x256x56.25" "400x253x56.86" "400x252x57.07" "400x251x57.48" "400x250x57.69" "400x248x58.12" "400x240x60.11" "392x243x59.21" "392x240x60.11" "384x576x24.96" "384x288x50.00" "384x256x56.25" "384x248x58.12" "384x240x60.11" "376x288x50.00" "376x280x51.47" "376x259x55.65" "376x240x60.11" "368x266x54.12" "368x257x56.05" "368x256x56.25" "368x240x60.11" "360x288x50.00" "360x272x52.85" "360x266x54.12" "360x251x57.27" "360x250x57.69" "360x248x58.12" "360x240x60.11" "352x288x50.00" "352x261x55.26" "352x261x55.07" "352x256x56.25" "352x248x58.12" "352x244x58.99" "352x243x59.21" "352x242x59.43" "352x240x60.11" "344x512x28.07" "344x258x55.85" "344x256x56.25" "344x241x59.66" "344x240x60.11" "344x240x59.89" "336x257x56.05" "336x252x57.07" "336x251x57.48" "336x250x57.69" "336x248x58.12" "336x244x58.99" "336x243x59.21" "336x240x60.11" "336x240x59.89" "328x244x58.99" "328x243x59.21" "328x241x59.66" "328x240x60.11" "320x256x56.25" "320x255x56.45" "320x248x58.12" "320x240x60.11" "312x288x50.00" "312x243x59.21" "312x241x59.66" "312x240x60.11" "312x240x59.89" "304x266x54.12" "304x241x59.66" "304x240x60.11" "296x288x50.00" "296x260x55.46" "296x257x56.05" "296x256x56.25" "296x255x56.45" "296x253x56.86" "296x240x60.11" "288x288x50.00" "288x266x54.12" "288x252x57.07" "288x250x57.69" "288x248x58.12" "288x240x60.11" "280x258x55.85" "280x243x59.21" "280x242x59.43" "280x241x59.66" "280x240x60.11" "280x240x59.89" "272x256x56.25" "272x252x57.07" "272x251x57.48" "272x248x58.12" "272x241x59.66" "272x240x60.11" "264x261x55.07" "264x248x58.12" "264x243x59.21" "264x241x59.66" "264x240x60.11"
        EndSubSection
EndSection

Would be correct?

I have seen that there is a folder called modes where might modelines (modes_mame.txt modes.txt) in 2 different formats, this folder is used for something? I mean, the used the genre to make the xorg.conf or you have to use those modelines in the xorg.conf manually?




Greetings.

lrmc.conf can be generated with lrmc -default, it output's the file and you place it in /etc/lrmc.conf adding that Clock line to it.

xorg.conf right now isn't using modelines, so I don't put them into it because they are just wasting space and it ignores them.  Hopefully I can fix it so it reads them and we can do it that way eventually, but for now it uses lrmc to calculate the modelines using those labels in the Modes sections (same as input would be to lrmc).

Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: bitbytebit on October 11, 2010, 07:23:40 am
Hi, I have everything compiled but I can not even try, I have several questions, where is the lrm.conf? I have not found on any site, when you say to try the "Clock = 3.75 - 25 / 15625-16650 / 49.50 - 65.00" This is put in the xorg.conf, right?
I would have to change
Code: [Select]
HorizSync    15.625 - 16.650
VertRefresh  49.00 - 65.00
--------------------------------------------
Option           "ForceMinDotClock" "3.75MHz"


When creating the xorg.conf me to believe so, I have given the following options "genres -cga -ff"

Code: [Select]
Section "ServerLayout"
        Identifier     "X.org Configured"
        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 "Files"
        ModulePath   "/usr/lib/xorg/modules"
        FontPath     "/usr/share/fonts/misc/"
        FontPath     "/usr/share/fonts/TTF/"
        FontPath     "/usr/share/fonts/OTF"
        FontPath     "/usr/share/fonts/Type1/"
        FontPath     "/usr/share/fonts/100dpi/"
        FontPath     "/usr/share/fonts/75dpi/"
EndSection

Section "Module"
        #Load  "FGL.renamed.libglx"
        Load  "glx"
        Load  "extmod"
        Load  "dbe"
        Load  "dri2"
        Load  "dri"
        Load  "record"
        SubSection "extmod"
                Option          "omit DPMS"
        EndSubSection
EndSection

Section "ServerFlags"
        Option          "AIGLX" "on"
        AllowMouseOpenFail
    Option       "Dont Zoom"
    Option         "NoDDC"
    Option         "UseEdidFreqs" "0"
    Option         "IgnoreEDID" "1"
    Option         "TMDS" "0"
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

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Wells Gardner"
        ModelName    "D9800"
        HorizSync    15.250 - 16.75, 24.00 - 26.00, 31.00 - 32.00, 37-40
        VertRefresh  47.00 - 85.00

    Option "DPMS"        "false"
EndSection

Section "Device"
        Option           "ForceMinDotClock" "5MHz"
    Option              "ModeDebug" "true"
    Option         "NoDDC"
    Option         "IgnoreEDID" "on"
    #
    Option          "ArcadeMonitor"  "d9800"
        #
        Identifier  "Card0"
        Driver      "radeon"
        VendorName  "ATI Technologies Inc"
        BoardName   "Unknown Board"
        BusID       "PCI:1:0:0"

EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        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

                Modes "800x576x24.96" "792x480x30.00" "768x256x56.25" "768x240x60.11" "760x576x25.04" "744x486x29.66" "744x288x50.00" "744x240x60.11" "736x264x54.50" "720x480x30.00" "720x240x60.11" "712x512x28.07" "712x288x50.00" "704x480x30.00" "704x240x60.11" "696x488x29.66" "696x480x30.00" "688x512x28.07" "688x500x28.79" "672x524x27.49" "672x506x28.58" "672x480x30.00" "672x240x60.11" "656x240x60.11" "648x504x28.58" "648x502x28.69" "648x498x28.79" "648x240x60.11" "640x482x30.00" "640x480x30.00" "640x478x30.00" "640x288x50.00" "640x256x56.25" "640x240x60.11" "632x496x29.01" "632x478x30.00" "624x524x27.58" "624x486x29.66" "624x480x30.00" "624x478x30.00" "616x558x25.78" "616x480x30.00" "616x288x50.00" "608x480x30.00" "600x288x50.00" "600x240x60.11" "592x532x27.02" "592x480x30.00" "584x520x27.58" "576x578x25.04" "576x518x27.78" "576x504x28.58" "576x288x50.00" "568x480x30.00" "568x478x30.00" "560x504x28.58" "560x502x28.79" "560x500x28.90" "560x498x28.79" "560x484x29.77" "560x280x51.47" "560x243x59.21" "552x496x29.01" "552x480x30.00" "552x240x60.11" "544x486x29.55" "544x480x30.00" "544x240x60.11" "536x514x28.07" "536x482x29.89" "536x478x30.00" "536x240x60.11" "528x488x29.55" "528x480x30.00" "528x478x30.00" "528x288x50.00" "528x261x55.07" "528x245x58.77" "528x244x58.99" "528x240x60.11" "520x504x28.69" "520x240x60.11" "512x576x24.96" "512x512x28.07" "512x504x28.58" "512x480x30.00" "512x288x50.00" "512x256x56.25" "512x254x56.65" "512x252x57.07" "512x240x60.11" "504x488x29.55" "504x486x29.66" "504x484x29.66" "504x482x30.00" "504x482x29.89" "504x288x50.00" "504x250x57.69" "496x480x30.00" "496x478x30.00" "496x240x60.11" "488x576x24.96" "488x488x29.66" "488x480x30.00" "480x480x30.00" "480x478x30.00" "480x288x50.00" "480x240x60.11" "472x262x54.88" "472x243x59.21" "464x288x50.00" "464x261x55.07" "464x248x58.12" "464x240x60.11" "456x578x24.96" "456x576x24.96" "456x512x28.07" "456x480x30.00" "456x288x50.00" "456x256x56.25" "456x255x56.45" "456x252x57.07" "448x252x57.07" "448x251x57.48" "448x240x60.11" "440x257x56.05" "440x256x56.25" "440x253x56.86" "440x252x57.07" "432x512x28.07" "432x288x50.00" "432x280x51.47" "432x276x52.15" "432x264x54.50" "432x257x56.05" "432x256x56.25" "432x253x56.86" "432x252x57.07" "432x251x57.48" "432x248x58.12" "432x240x60.11" "424x512x28.07" "424x480x30.00" "424x288x50.00" "424x272x52.85" "416x288x50.00" "416x267x53.94" "416x266x54.12" "416x262x54.88" "416x256x56.25" "416x243x59.21" "416x241x59.66" "416x240x60.11" "408x266x54.12" "408x253x56.86" "408x252x57.07" "408x240x60.11" "400x512x28.07" "400x288x50.00" "400x280x51.47" "400x272x52.85" "400x264x54.50" "400x260x55.46" "400x257x56.05" "400x256x56.25" "400x253x56.86" "400x252x57.07" "400x251x57.48" "400x250x57.69" "400x248x58.12" "400x240x60.11" "392x243x59.21" "392x240x60.11" "384x576x24.96" "384x288x50.00" "384x256x56.25" "384x248x58.12" "384x240x60.11" "376x288x50.00" "376x280x51.47" "376x259x55.65" "376x240x60.11" "368x266x54.12" "368x257x56.05" "368x256x56.25" "368x240x60.11" "360x288x50.00" "360x272x52.85" "360x266x54.12" "360x251x57.27" "360x250x57.69" "360x248x58.12" "360x240x60.11" "352x288x50.00" "352x261x55.26" "352x261x55.07" "352x256x56.25" "352x248x58.12" "352x244x58.99" "352x243x59.21" "352x242x59.43" "352x240x60.11" "344x512x28.07" "344x258x55.85" "344x256x56.25" "344x241x59.66" "344x240x60.11" "344x240x59.89" "336x257x56.05" "336x252x57.07" "336x251x57.48" "336x250x57.69" "336x248x58.12" "336x244x58.99" "336x243x59.21" "336x240x60.11" "336x240x59.89" "328x244x58.99" "328x243x59.21" "328x241x59.66" "328x240x60.11" "320x256x56.25" "320x255x56.45" "320x248x58.12" "320x240x60.11" "312x288x50.00" "312x243x59.21" "312x241x59.66" "312x240x60.11" "312x240x59.89" "304x266x54.12" "304x241x59.66" "304x240x60.11" "296x288x50.00" "296x260x55.46" "296x257x56.05" "296x256x56.25" "296x255x56.45" "296x253x56.86" "296x240x60.11" "288x288x50.00" "288x266x54.12" "288x252x57.07" "288x250x57.69" "288x248x58.12" "288x240x60.11" "280x258x55.85" "280x243x59.21" "280x242x59.43" "280x241x59.66" "280x240x60.11" "280x240x59.89" "272x256x56.25" "272x252x57.07" "272x251x57.48" "272x248x58.12" "272x241x59.66" "272x240x60.11" "264x261x55.07" "264x248x58.12" "264x243x59.21" "264x241x59.66" "264x240x60.11"
        EndSubSection
EndSection

Would be correct?

I have seen that there is a folder called modes where might modelines (modes_mame.txt modes.txt) in 2 different formats, this folder is used for something? I mean, the used the genre to make the xorg.conf or you have to use those modelines in the xorg.conf manually?




Greetings.

lrmc.conf can be generated with lrmc -default, it output's the file and you place it in /etc/lrmc.conf adding that Clock line to it.

xorg.conf right now isn't using modelines, so I don't put them into it because they are just wasting space and it ignores them.  Hopefully I can fix it so it reads them and we can do it that way eventually, but for now it uses lrmc to calculate the modelines using those labels in the Modes sections (same as input would be to lrmc).


Code: [Select]
diff --git a/xf86-video-ArcadeVGA-6.13.0/src/radeon_driver.c b/xf86-video-ArcadeVGA-6.13.0/src/radeon_driver.c
index 0c1ca7b..a1f2c3b 100644
--- a/xf86-video-ArcadeVGA-6.13.0/src/radeon_driver.c
+++ b/xf86-video-ArcadeVGA-6.13.0/src/radeon_driver.c
@@ -1269,7 +1269,10 @@ static void RADEONGetClockInfo(ScrnInfoPtr pScrn)
      * clocks.  Allow users to override the detected minimum dot clock
      * value (e.g., and allow it to be suitable for TV sets).
      */
-    if (xf86GetOptValFreq(info->Options, OPTION_MIN_DOTCLOCK,
+    if (info->ArcadeMonitor != RADEON_ARCADE_NONE) {
+           /*  Using an arcade monitor */
+           pll->pll_out_min = 1 * 1000;
+    } else if (xf86GetOptValFreq(info->Options, OPTION_MIN_DOTCLOCK,
                          OPTUNITS_MHZ, &min_dotclock)) {
        if (min_dotclock < 5 || min_dotclock*100 >= pll->pll_out_max) {
            xf86DrvMsg(pScrn->scrnIndex, X_INFO,

This patch allows that setting of force minimum dotclock to not be necessary, and also work no matter what you put in that option.  Currently without this patch when you go below 5 Mhz it ignores the value completely.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: Calamity on October 11, 2010, 07:36:47 am
Hopefully with this new patches things will be even more straightforward, having to calculate modelines just once, placing them again in xorg.conf (as everyone is doing without realizing it's useless), and keeping monitor related stuff in lrmc.conf.

So, maybe we should wait until these new things are done before building it yet.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: ves on October 11, 2010, 08:43:05 am
Hi, I have 2 problems to compile the ati driver, I step log.

Code: [Select]
make  all-recursive
make[1]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b'
Making all in src
make[2]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/src'
/bin/bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I./AtomBios/includes  -Wall -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/X11/dri -DDISABLE_EASF -DENABLE_ALL_SERVICE_FUNCTIONS -DATOM_BIOS -DATOM_BIOS_PARSER -DDRIVER_PARSER -g -O2 -MT lrmc.lo -MD -MP -MF .deps/lrmc.Tpo -c -o lrmc.lo lrmc.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./AtomBios/includes -Wall -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/X11/dri -DDISABLE_EASF -DENABLE_ALL_SERVICE_FUNCTIONS -DATOM_BIOS -DATOM_BIOS_PARSER -DDRIVER_PARSER -g -O2 -MT lrmc.lo -MD -MP -MF .deps/lrmc.Tpo -c lrmc.c  -fPIC -DPIC -o .libs/lrmc.o
In file included from lrmc.c:25:
radeon.h:76:23: error: GL/glxint.h: No existe el fichero Ăł directorio
In file included from lrmc.c:25:
radeon.h:579: error: expected specifier-qualifier-list before â__GLXvisualConfigâ
lrmc.c: In function âlrmcâ:
lrmc.c:3932: warning: unused variable âinfoâ
make[2]: *** [lrmc.lo] Error 1
make[2]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/src'
make[1]: *** [all-recursive] Error 1
make[1]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b'
make: *** [all] Error 2

By the way as it applies the last diff, with patch -p0 -E <diff.diff fails.

Greetings.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: bitbytebit on October 11, 2010, 09:19:09 am
Hi, I have 2 problems to compile the ati driver, I step log.

Code: [Select]
make  all-recursive
make[1]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b'
Making all in src
make[2]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/src'
/bin/bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I./AtomBios/includes  -Wall -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/X11/dri -DDISABLE_EASF -DENABLE_ALL_SERVICE_FUNCTIONS -DATOM_BIOS -DATOM_BIOS_PARSER -DDRIVER_PARSER -g -O2 -MT lrmc.lo -MD -MP -MF .deps/lrmc.Tpo -c -o lrmc.lo lrmc.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./AtomBios/includes -Wall -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/X11/dri -DDISABLE_EASF -DENABLE_ALL_SERVICE_FUNCTIONS -DATOM_BIOS -DATOM_BIOS_PARSER -DDRIVER_PARSER -g -O2 -MT lrmc.lo -MD -MP -MF .deps/lrmc.Tpo -c lrmc.c  -fPIC -DPIC -o .libs/lrmc.o
In file included from lrmc.c:25:
radeon.h:76:23: error: GL/glxint.h: No existe el fichero Ăł directorio
In file included from lrmc.c:25:
radeon.h:579: error: expected specifier-qualifier-list before â__GLXvisualConfigâ
lrmc.c: In function âlrmcâ:
lrmc.c:3932: warning: unused variable âinfoâ
make[2]: *** [lrmc.lo] Error 1
make[2]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/src'
make[1]: *** [all-recursive] Error 1
make[1]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b'
make: *** [all] Error 2

By the way as it applies the last diff, with patch -p0 -E <diff.diff fails.

Greetings.

Did you run ./configure --prefix=/usr before running make?   It seems the error is not finding the OpenGL or mesa libraries on your system (the GL/glxint.h file).  You probably want to have opengl support, and either configure wasn't run or it really is missing from the system, at least from what I can tell.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: ves on October 11, 2010, 10:06:44 am
Bitbytebit Hi, I've been able to compile the driver, but it is assumed that in ubuntu / debian the ati driver are radeon.ko ati.ko etc. .., but when I compiled your driver does not create these files, it may be because geeton are different drivers?
make install to make it out.

Code: [Select]
root@Arcade:/home/retro/xf86-video-ArcadeVGA-6.13.0b# make install
Making install in src
make[1]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/src'
make[2]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/src'
make[2]: No se hace nada para `install-exec-am'.
test -z "/usr/local/lib/xorg/modules/drivers" || /bin/mkdir -p "/usr/local/lib/x                                                                                                                               org/modules/drivers"
 /bin/bash ../libtool   --mode=install /usr/bin/install -c  'ati_drv.la' '/usr/l                                                                                                                               ocal/lib/xorg/modules/drivers/ati_drv.la'
libtool: install: /usr/bin/install -c .libs/ati_drv.so /usr/local/lib/xorg/modul                                                                                                                               es/drivers/ati_drv.so
libtool: install: /usr/bin/install -c .libs/ati_drv.lai /usr/local/lib/xorg/modu                                                                                                                               les/drivers/ati_drv.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/                                                                                                                               bin:/usr/games:/sbin" ldconfig -n /usr/local/lib/xorg/modules/drivers
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib/xorg/modules/drivers

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
test -z "/usr/local/lib/xorg/modules/drivers" || /bin/mkdir -p "/usr/local/lib/x                                                                                                                               org/modules/drivers"
 /bin/bash ../libtool   --mode=install /usr/bin/install -c  'radeon_drv.la' '/us                                                                                                                               r/local/lib/xorg/modules/drivers/radeon_drv.la'
libtool: install: /usr/bin/install -c .libs/radeon_drv.so /usr/local/lib/xorg/mo                                                                                                                               dules/drivers/radeon_drv.so
libtool: install: /usr/bin/install -c .libs/radeon_drv.lai /usr/local/lib/xorg/m                                                                                                                               odules/drivers/radeon_drv.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/                                                                                                                               bin:/usr/games:/sbin" ldconfig -n /usr/local/lib/xorg/modules/drivers
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib/xorg/modules/drivers

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
test -z "/usr/local/lib/xorg/modules/multimedia" || /bin/mkdir -p "/usr/local/li                                                                                                                               b/xorg/modules/multimedia"
 /bin/bash ../libtool   --mode=install /usr/bin/install -c  'theatre200_drv.la'                                                                                                                                '/usr/local/lib/xorg/modules/multimedia/theatre200_drv.la'
libtool: install: /usr/bin/install -c .libs/theatre200_drv.so /usr/local/lib/xor                                                                                                                               g/modules/multimedia/theatre200_drv.so
libtool: install: /usr/bin/install -c .libs/theatre200_drv.lai /usr/local/lib/xo                                                                                                                               rg/modules/multimedia/theatre200_drv.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/                                                                                                                               bin:/usr/games:/sbin" ldconfig -n /usr/local/lib/xorg/modules/multimedia
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib/xorg/modules/multimedia

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
test -z "/usr/local/lib/xorg/modules/multimedia" || /bin/mkdir -p "/usr/local/li                                                                                                                               b/xorg/modules/multimedia"
 /bin/bash ../libtool   --mode=install /usr/bin/install -c  'theatre_detect_drv.                                                                                                                               la' '/usr/local/lib/xorg/modules/multimedia/theatre_detect_drv.la'
libtool: install: /usr/bin/install -c .libs/theatre_detect_drv.so /usr/local/lib                                                                                                                               /xorg/modules/multimedia/theatre_detect_drv.so
libtool: install: /usr/bin/install -c .libs/theatre_detect_drv.lai /usr/local/li                                                                                                                               b/xorg/modules/multimedia/theatre_detect_drv.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/                                                                                                                               bin:/usr/games:/sbin" ldconfig -n /usr/local/lib/xorg/modules/multimedia
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib/xorg/modules/multimedia

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
test -z "/usr/local/lib/xorg/modules/multimedia" || /bin/mkdir -p "/usr/local/li                                                                                                                               b/xorg/modules/multimedia"
 /bin/bash ../libtool   --mode=install /usr/bin/install -c  'theatre_drv.la' '/u                                                                                                                               sr/local/lib/xorg/modules/multimedia/theatre_drv.la'
libtool: install: /usr/bin/install -c .libs/theatre_drv.so /usr/local/lib/xorg/m                                                                                                                               odules/multimedia/theatre_drv.so
libtool: install: /usr/bin/install -c .libs/theatre_drv.lai /usr/local/lib/xorg/                                                                                                                               modules/multimedia/theatre_drv.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/                                                                                                                               bin:/usr/games:/sbin" ldconfig -n /usr/local/lib/xorg/modules/multimedia
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib/xorg/modules/multimedia

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
make[2]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/src'
make[1]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/src'
Making install in man
make[1]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/man'
make[2]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/man'
make[2]: No se hace nada para `install-exec-am'.
test -z "/usr/local/share/man/man4" || /bin/mkdir -p "/usr/local/share/man/man4"
 /usr/bin/install -c -m 644 'ati.4' '/usr/local/share/man/man4/ati.4'
 /usr/bin/install -c -m 644 'radeon.4' '/usr/local/share/man/man4/radeon.4'
make[2]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/man'
make[1]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/man'
make[1]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b'
make[2]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b'
make[2]: No se hace nada para `install-exec-am'.
make[2]: No se hace nada para `install-data-am'.
make[2]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b'
make[1]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b'
root@Arcade:/home/retro/xf86-video-ArcadeVGA-6.13.0b#

What am I doing wrong?

Greetings.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: bitbytebit on October 11, 2010, 10:12:34 am
Bitbytebit Hi, I've been able to compile the driver, but it is assumed that in ubuntu / debian the ati driver are radeon.ko ati.ko etc. .., but when I compiled your driver does not create these files, it may be because geeton are different drivers?
make install to make it out.

Code: [Select]
root@Arcade:/home/retro/xf86-video-ArcadeVGA-6.13.0b# make install
Making install in src
make[1]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/src'
make[2]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/src'
make[2]: No se hace nada para `install-exec-am'.
test -z "/usr/local/lib/xorg/modules/drivers" || /bin/mkdir -p "/usr/local/lib/x                                                                                                                               org/modules/drivers"
 /bin/bash ../libtool   --mode=install /usr/bin/install -c  'ati_drv.la' '/usr/l                                                                                                                               ocal/lib/xorg/modules/drivers/ati_drv.la'
libtool: install: /usr/bin/install -c .libs/ati_drv.so /usr/local/lib/xorg/modul                                                                                                                               es/drivers/ati_drv.so
libtool: install: /usr/bin/install -c .libs/ati_drv.lai /usr/local/lib/xorg/modu                                                                                                                               les/drivers/ati_drv.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/                                                                                                                               bin:/usr/games:/sbin" ldconfig -n /usr/local/lib/xorg/modules/drivers
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib/xorg/modules/drivers

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
test -z "/usr/local/lib/xorg/modules/drivers" || /bin/mkdir -p "/usr/local/lib/x                                                                                                                               org/modules/drivers"
 /bin/bash ../libtool   --mode=install /usr/bin/install -c  'radeon_drv.la' '/us                                                                                                                               r/local/lib/xorg/modules/drivers/radeon_drv.la'
libtool: install: /usr/bin/install -c .libs/radeon_drv.so /usr/local/lib/xorg/mo                                                                                                                               dules/drivers/radeon_drv.so
libtool: install: /usr/bin/install -c .libs/radeon_drv.lai /usr/local/lib/xorg/m                                                                                                                               odules/drivers/radeon_drv.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/                                                                                                                               bin:/usr/games:/sbin" ldconfig -n /usr/local/lib/xorg/modules/drivers
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib/xorg/modules/drivers

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
test -z "/usr/local/lib/xorg/modules/multimedia" || /bin/mkdir -p "/usr/local/li                                                                                                                               b/xorg/modules/multimedia"
 /bin/bash ../libtool   --mode=install /usr/bin/install -c  'theatre200_drv.la'                                                                                                                                '/usr/local/lib/xorg/modules/multimedia/theatre200_drv.la'
libtool: install: /usr/bin/install -c .libs/theatre200_drv.so /usr/local/lib/xor                                                                                                                               g/modules/multimedia/theatre200_drv.so
libtool: install: /usr/bin/install -c .libs/theatre200_drv.lai /usr/local/lib/xo                                                                                                                               rg/modules/multimedia/theatre200_drv.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/                                                                                                                               bin:/usr/games:/sbin" ldconfig -n /usr/local/lib/xorg/modules/multimedia
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib/xorg/modules/multimedia

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
test -z "/usr/local/lib/xorg/modules/multimedia" || /bin/mkdir -p "/usr/local/li                                                                                                                               b/xorg/modules/multimedia"
 /bin/bash ../libtool   --mode=install /usr/bin/install -c  'theatre_detect_drv.                                                                                                                               la' '/usr/local/lib/xorg/modules/multimedia/theatre_detect_drv.la'
libtool: install: /usr/bin/install -c .libs/theatre_detect_drv.so /usr/local/lib                                                                                                                               /xorg/modules/multimedia/theatre_detect_drv.so
libtool: install: /usr/bin/install -c .libs/theatre_detect_drv.lai /usr/local/li                                                                                                                               b/xorg/modules/multimedia/theatre_detect_drv.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/                                                                                                                               bin:/usr/games:/sbin" ldconfig -n /usr/local/lib/xorg/modules/multimedia
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib/xorg/modules/multimedia

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
test -z "/usr/local/lib/xorg/modules/multimedia" || /bin/mkdir -p "/usr/local/li                                                                                                                               b/xorg/modules/multimedia"
 /bin/bash ../libtool   --mode=install /usr/bin/install -c  'theatre_drv.la' '/u                                                                                                                               sr/local/lib/xorg/modules/multimedia/theatre_drv.la'
libtool: install: /usr/bin/install -c .libs/theatre_drv.so /usr/local/lib/xorg/m                                                                                                                               odules/multimedia/theatre_drv.so
libtool: install: /usr/bin/install -c .libs/theatre_drv.lai /usr/local/lib/xorg/                                                                                                                               modules/multimedia/theatre_drv.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/                                                                                                                               bin:/usr/games:/sbin" ldconfig -n /usr/local/lib/xorg/modules/multimedia
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib/xorg/modules/multimedia

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
make[2]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/src'
make[1]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/src'
Making install in man
make[1]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/man'
make[2]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/man'
make[2]: No se hace nada para `install-exec-am'.
test -z "/usr/local/share/man/man4" || /bin/mkdir -p "/usr/local/share/man/man4"
 /usr/bin/install -c -m 644 'ati.4' '/usr/local/share/man/man4/ati.4'
 /usr/bin/install -c -m 644 'radeon.4' '/usr/local/share/man/man4/radeon.4'
make[2]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/man'
make[1]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b/man'
make[1]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b'
make[2]: se ingresa al directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b'
make[2]: No se hace nada para `install-exec-am'.
make[2]: No se hace nada para `install-data-am'.
make[2]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b'
make[1]: se sale del directorio `/home/retro/xf86-video-ArcadeVGA-6.13.0b'
root@Arcade:/home/retro/xf86-video-ArcadeVGA-6.13.0b#

What am I doing wrong?

Greetings.

It's installing it in /usr/local/ instead of /usr, should run './configure --prefix=/usr' and then run make and make install.  The .ko are kernel modules, this installs to /usr/lib/xorg/modules/drivers/  the files ati_drv.so and radeon_drv.so which xorg uses.  So running configure again with --prefix=/usr should install them into /usr/lib/xorg/modules/drivers and then X Windows should use the new radeon driver.  You might want to backup the /usr/lib/xorg/modules/drivers directory before installing.
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: ahofle on October 11, 2010, 02:45:40 pm
This is a highly interesting project, I hope we can share some stuff. I also wrote a program to generate modelines + .inis from Mame XML, for the Windows platform. Mine is called VideoModeMaker, and can be downloaded here (in Spanish):

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


Hi Calamity.
Is there a similar tool available which will simply calculate a modeline for you (instead of requiring MAME, modifying registry, etc)?  It would be very useful for users of Soft15khz.  I don't understand the values like porch enough to create my own. 
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: Calamity on October 11, 2010, 02:59:33 pm
This is a highly interesting project, I hope we can share some stuff. I also wrote a program to generate modelines + .inis from Mame XML, for the Windows platform. Mine is called VideoModeMaker, and can be downloaded here (in Spanish):

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


Hi Calamity.
Is there a similar tool available which will simply calculate a modeline for you (instead of requiring MAME, modifying registry, etc)?  It would be very useful for users of Soft15khz.  I don't understand the values like porch enough to create my own. 

Yes, several indeed. The one I made (link above) can calculate one or more modelines. Just disable all the Mame XML processing and driver updating from the app ini file, and you'll have a plain modeline calculator. Edit "ResList.txt" to add/remove the resolutions you want the program to calculate. Modelines will be stored in "Modeline.txt". I believe you can use them with Soft15Khz.

There is also a very nice program called Winmodelines, that has a modeline calculator for several monitor types.

And of course lrmc, there's a Win32 binary.


Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file MAME generation
Post by: ahofle on October 11, 2010, 04:55:38 pm
Thanks I'll give it a shot!
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: bitbytebit on October 11, 2010, 09:31:13 pm
Version 0.8 has improved things considerably, now the actual modelines are really read from xorg.conf and only uses the lrmc code in there if no modeline is listed for the "HxWxR" label in the Modes section (just like how all X drivers do but it uses the LRMC and not Vesa method unless you don't have the Option "ArcadeMonitor" set to a valid monitor name).  Also bug fixes and other issues hopefully are fixed and works better now, should be easier to use and get working now.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: Calamity on October 12, 2010, 05:21:30 am
Version 0.8 has improved things considerably, now the actual modelines are really read from xorg.conf and only uses the lrmc code in there if no modeline is listed for the "HxWxR" label in the Modes section (just like how all X drivers do but it uses the LRMC and not Vesa method unless you don't have the Option "ArcadeMonitor" set to a valid monitor name).  Also bug fixes and other issues hopefully are fixed and works better now, should be easier to use and get working now.

I'd like to summarize and see if I've understood right:

- We start running genres with proper params to get modelines and .inis done (at this point, I'm not sure if lrmc will use options from xorg.conf or from lrmc.conf). Modelines will be added to xorg.conf, and available when we restart.
- Now, we'll have ini files for Mame games with the resolution in the format WxH@R where R is a double (not integer anymore). When starting Mame, it'll push this resolution to the driver.
- The driver will parse texts labels in the Modes section of xorg.conf until it finds one that matches "WxHxR" values.
- Then, the driver will use this label to get the proper modeline from the Monitor section of xorg.conf, and use this modeline to program Radeon hardware  :applaud:
- If the driver didn't find the mode we're asking for in the modeline table, it will produce a brand new modeline on the fly by calling lrmc.

This is exactly what we needed, even more.

When I have the time, I'd like to have a look at lrmc and see how things are done. I've been playing with Win32 lrmc and noticed a strange behaviour with some resolutions. I'd like to build a Win32 binary of your version, to be able to perform some tests. Eventually, I might add some of my stuff to lrmc, though I lack the C knowlegde.

Thanks again for the good work!



Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: ves on October 12, 2010, 05:33:40 am
Hi, I'm going in parts
1 The ATI driver is not for the kernel (so not created radeon.ko) is for the manager Xorg (radeon.so are created) does not?
2 The driver must be installed in /usr/lib/xorg/modules/drivers/, right?
3 Once installed the driver, lrm and mame, what we should do?
 1 Creating the lrmc.conf in / etc (to be configured here?)
 2 Configure mame.
 3 Generate the modelines and ini.
 4 Create the xorg.conf (now creates all here, right?)

What else would have to do or configure? that would fail that test want to try doing?

Because making genres -cga -ff -ini xorg.conf is not configured to cga monitor, always set to d9800



Greetings.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: Calamity on October 12, 2010, 06:14:21 am
What else would have to do or configure? that would fail that test want to try doing?

Hi VeS, it will work, the tests I meant are secondary (once we have it running we'll think about it).

Because making genres -cga -ff -ini xorg.conf is not configured to cga monitor, always set to d9800

First we need to run lmrc --default to produce our lrmc.conf file.
Then edit lrmc.conf with the params of Hantarex MTC9110 (the ones I posted before).
Then run genres -ff -ini (no monitor params). This will produce .inis + modelines (added in xorg.conf).


Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: bitbytebit on October 12, 2010, 09:36:11 am

Version 0.8 has improved things considerably, now the actual modelines are really read from xorg.conf and only uses the lrmc code in there if no modeline is listed for the "HxWxR" label in the Modes section (just like how all X drivers do but it uses the LRMC and not Vesa method unless you don't have the Option "ArcadeMonitor" set to a valid monitor name).  Also bug fixes and other issues hopefully are fixed and works better now, should be easier to use and get working now.

I'd like to summarize and see if I've understood right:

- We start running genres with proper params to get modelines and .inis done (at this point, I'm not sure if lrmc will use options from xorg.conf or from lrmc.conf). Modelines will be added to xorg.conf, and available when we restart.


lrmc will use the options from /etc/lrmc.conf or lrmc.conf in the working directory, I've left that the same while now the X server just reads the modelines and Hsync/Vsync ranges from xorg.conf (which really just serve to limit bad modelines and the default modelines from being used).  There are default modelines that the X server part likes to force on us, not so bad since the Hsync/Vsync settings eliminate any ones out of range but also is a little annoying it does that, would be nice to figure out how to only have our modelines available.

- Now, we'll have ini files for Mame games with the resolution in the format WxH@R where R is a double (not integer anymore). When starting Mame, it'll push this resolution to the driver.


In Windows it'd be WxH@R but in Linux it uses WxHxD@R and it well R is a double on my local tree here but I haven't put that patch in yet.  It's here, it's very simple actually for the Linux side but of course the Windows one looks limited by Windows (unless using SDL there I guess).  Also I am now wanting to investigate that more that I got the X Driver behaving properly, and figure out if it really only is SDL 1.3 that listens to the refresh rate, or if I can change it so both SDL1.2 and other methods all use it.  Might want to figure out ways to have MAME change the resolution with xrandr since it seems like the new and upcoming method of doing changes and possibly why they removed modeline support (xrandr can add modelines itself, and can call ours or the ones it added.  The issue is that modelines it adds aren't callable by SDL for some odd reason).

Linux patch:

Code: [Select]
diff -ru ../Mame_vanilla_0139u3_local/src/osd/sdl/video.c ./src/osd/sdl/video.c
--- ../Mame_vanilla_0139u3_local/src/osd/sdl/video.c    2010-10-08 14:10:30.000000000 -0500
+++ ./src/osd/sdl/video.c       2010-10-08 17:32:14.000000000 -0500
@@ -898,7 +898,8 @@
        const char *defdata = options_get_string(mame_options(), SDLOPTION_RESOLUTION(""));
        const char *data = options_get_string(mame_options(), name);

-       config->width = config->height = config->depth = config->refresh = 0;
+       config->width = config->height = config->depth = 0;
+       config->refresh = 0.0;
        if (strcmp(data, SDLOPTVAL_AUTO) == 0)
        {
                if (strcmp(defdata, SDLOPTVAL_AUTO) == 0)
@@ -909,7 +910,7 @@
                data = defdata;
        }

-       if (sscanf(data, "%dx%dx%d@%d", &config->width, &config->height, &config->depth, &config->refresh) < 2 && report_error)
+       if (sscanf(data, "%dx%dx%d@%lf", &config->width, &config->height, &config->depth, &config->refresh) < 2 && report_error)
                mame_printf_error("Illegal resolution value for %s = %s\n", name, data);
 }

diff -ru ../Mame_vanilla_0139u3_local/src/osd/sdl/video.h ./src/osd/sdl/video.h
--- ../Mame_vanilla_0139u3_local/src/osd/sdl/video.h    2010-02-14 12:59:50.000000000 -0600
+++ ./src/osd/sdl/video.h       2010-10-08 17:29:09.000000000 -0500
@@ -82,7 +82,7 @@
        int                                     width;                                          // decoded width
        int                                     height;                                         // decoded height
        int                                     depth;                                          // decoded depth
-       int                                     refresh;                                        // decoded refresh
+       double                                  refresh;                                        // decoded refresh

        int                                     totalColors;             // total colors from machine
 };
diff -ru ../Mame_vanilla_0139u3_local/src/osd/sdl/window.h ./src/osd/sdl/window.h
--- ../Mame_vanilla_0139u3_local/src/osd/sdl/window.h   2010-10-08 14:10:30.000000000 -0500
+++ ./src/osd/sdl/window.h      2010-10-08 17:26:46.000000000 -0500
@@ -63,7 +63,7 @@
        int                                     minwidth, minheight;
        int                                     maxwidth, maxheight;
        int                                     depth;
-       int                                     refresh;
+       double                                  refresh;
        int                                     windowed_width;
        int                                     windowed_height;
        int                                     startmaximized;

Windows patch:
Code: [Select]
diff -ru ../Mame_vanilla_0139u3_local/src/osd/windows/video.c ./src/osd/windows/video.c
--- ../Mame_vanilla_0139u3_local/src/osd/windows/video.c        2010-10-08 14:09:59.000000000 -0500
+++ ./src/osd/windows/video.c   2010-10-08 17:33:05.000000000 -0500
@@ -553,13 +553,14 @@
        const char *defdata = options_get_string(mame_options(), WINOPTION_RESOLUTION);
        const char *data = options_get_string(mame_options(), name);

-       config->width = config->height = config->refresh = 0;
+       config->width = config->height = 0;
+       config->refresh = 0.0;
        if (strcmp(data, "auto") == 0)
        {
                if (strcmp(defdata, "auto") == 0)
                        return;
                data = defdata;
        }
-       if (sscanf(data, "%dx%d@%d", &config->width, &config->height, &config->refresh) < 2 && report_error)
+       if (sscanf(data, "%dx%d@%lf", &config->width, &config->height, &config->refresh) < 2 && report_error)
                mame_printf_error("Illegal resolution value for %s = %s\n", name, data);
 }
diff -ru ../Mame_vanilla_0139u3_local/src/osd/windows/video.h ./src/osd/windows/video.h
--- ../Mame_vanilla_0139u3_local/src/osd/windows/video.h        2009-10-12 01:45:26.000000000 -0500
+++ ./src/osd/windows/video.h   2010-10-08 17:34:11.000000000 -0500
@@ -78,7 +78,7 @@
        float                           aspect;                                         // decoded aspect ratio
        int                                     width;                                          // decoded width
        int                                     height;                                         // decoded height
-       int                                     refresh;                                        // decoded refresh
+       double                                  refresh;                                        // decoded refresh
 };


diff -ru ../Mame_vanilla_0139u3_local/src/osd/windows/window.h ./src/osd/windows/window.h
--- ../Mame_vanilla_0139u3_local/src/osd/windows/window.h       2010-10-08 14:09:59.000000000 -0500
+++ ./src/osd/windows/window.h  2010-10-08 17:33:51.000000000 -0500
@@ -92,7 +92,7 @@
        int                                     fullscreen;
        int                                     fullscreen_safe;
        int                                     maxwidth, maxheight;
-       int                                     refresh;
+       double                                  refresh;
        float                           aspect;

        // rendering info


- The driver will parse texts labels in the Modes section of xorg.conf until it finds one that matches "WxHxR" values.


In theory yes, but still to be proven if it really always makes the right decision which depends on the above patch and figuring out SDL 1.3 possibly.  Which 1.3 has been in development for years, and doesn't look like they plan on ever really releasing something that is stable, I hope it happens soon because I think it solves all these issues.  I need to test it more to see if it is usable or not.

- Then, the driver will use this label to get the proper modeline from the Monitor section of xorg.conf, and use this modeline to program Radeon hardware  :applaud:
- If the driver didn't find the mode we're asking for in the modeline table, it will produce a brand new modeline on the fly by calling lrmc.


Yep, that's the nice thing about how lrmc fits in and basically does the same as they do following the use a modeline calculator in X method.  They have CVT and UMG actually available in the X Server for drivers to use, now we have lrmc support in at least the radeon driver.  So you in theory could totally trust lrmc and just do a line of Mode labels with "HxWxR" formats and it'll run those using the method you choose with the "ArcadeMonitor" Option set to either using /etc/lrmc.conf if it is set to "lrmc" or one of the supported types of monitors by lrmc like cga,ega,d9800 etc.

This is exactly what we needed, even more.

When I have the time, I'd like to have a look at lrmc and see how things are done. I've been playing with Win32 lrmc and noticed a strange behaviour with some resolutions. I'd like to build a Win32 binary of your version, to be able to perform some tests. Eventually, I might add some of my stuff to lrmc, though I lack the C knowlegde.



That would be great, because I know lrmc isn't always making the best decisions and can tell from your program that you could probably really shape it up and get things working much nicer with better modelines generated.  With that, this version of lrmc improved would be very useful to both Windows Soft15Khz users to make .ini files and modelines there and Linux users with the Radeon driver.  I'm just glad that now that the Radeon driver will play ball with us and use our Modelines, we now can figure out the actual modeline generation and vsync issues.  Which is the more exciting part of course, that Radeon driver was quite crazy to figure out how to read the Modelines and now looking at what I had to do it was not terribly complicated but totally undocumented and I see no other driver in X doing what I did.  The modelines from the config file are all there and available to the driver but it just never took the time to get them, compare them to the Modes section, and pick the ones that matched.

Thanks again for the good work!


Thanks,  Now I'm planning on looking through your modeline generator some and also the MAME sources to figure out more about how to make better modelines and make sure MAME can pick the right modeline, see about vsync and how that is done with SDL.

You help would be great, understand about the C code knowledge but if you had time it would be really helpful if you possibly could write out the general procedure you go through to take a games resolution from the MAME xml file, and turn that into the final .ini file resolution and modeline.  Just basic outline type stuff, because I am reading but it's definitely hard to fully grasp it quickly though.  I can put things into code in C but since you know the algorithms so well then will definitely be nice to combine that knowledge.  Will see how quickly I can grasp from your program what your doing, think I can but may take a week of looking each day to start catching on better.   Looking at what lrmc is something I need to do too because it's rather complicated from what I can tell, and seeing both compared together may be able to help me get the idea of how these modelines are computed to come up with the best final modeline. 



Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: bitbytebit on October 12, 2010, 01:17:59 pm
I've confirmed that it does not always set the right refresh rate with MAME and SDL 1.2 so it picks the first modeline it sees.  This has two issues, one of course it's the wrong modeline, two since the X driver throws in a set of default resolutions it seems to want us to have of basic "WxH" values they always override when there's one available for that size resolution.  So I'm guessing possibly SDL 1.3 doesn't have this issue, but of course we aren't there yet.  So I like your idea of incrementing the first W size by one for each of our custom modelines to allow mame to call the correct ones with the .ini files referencing them.  I don't know if it's possible to remove those default resolutions from X because it does that in the main xorg-server part and not the radeon driver itself.  Also even if I get those to stop it, it's not a change they'd ever accept to include in the official driver (not sure they'd accept these ones I'm doing for arcade monitors, maybe just lrmc integration and an arcade setting but otherwise the philosophy of the Xorg seems to be not to let users touch modelines).  Also then we'd still be needing to do your fix too for references modelines properly.

On a good note I have been able to get doublescan and interlacing support fixed since the newer radeon driver supports those and now I can display 192 Vertical resolution games perfectly with doublescan, like the transformers one.  There's a few changes I have done to lrmc last night after the last 8a version of genres which allow this to work, by checking to see if it should do doublescan or not else by default enabling it allows it to do it for games it should probably not do it for.  I think lrmc seems a bit untamed and sometimes goes overbounds with things like interlacing and doublescan or making the wxh too large and so I've been adding rules to fixup the wxhxr and settings it normally would choose.  Hopefully it can be made to really properly calculate things a bit more controlled eventually the first time and not have to use second passes on the output.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: Calamity on October 12, 2010, 03:43:34 pm
Hi bitbytebit,

We also have that problem with default video modes appearing on us in Windows. Fortunately custom modelines override default modes when they match. But as room for video modes is very limited (60 by default, 200 with my hacked drivers) and these modes waste space we have to "restrict" them, there's a registry key to do this.

It would be great you got SDL to properly deal with vertical refresh. In Windows we have this "integer bottleneck" in the DirectX functions (who would ever want to deal with double precission vfreq values?), that lead me to use that system for differencing modelines. However, this system has a drawback: as variety of video modes reported by Mame xml increases with each new version, you can eventually run out of "x-labels", as fake increased xres reaches the next 8-multiple. Thus, it becomes a need to control the total number of produced modelines - which by the way I must do in Windows to keep the number below the limit - Writing an algorithm that does a good job reducing a resolution list while keeping the most important ones, is not a trivial matter, I'd say it's the most difficult part of the game. I believe lrmc has an implementation of this. There's something more to care about when using this system: Mame tries to center the game frame on the screen, so if you use a fake xres increased more than one pixel you will start loosing pixels on frame's right side, as you'll have a hardware vs logic resolution issue (Mame would work with a logical frame bigger than the screen resolution, so a patch on this would be needed). If SDL thing can be figured out, all this would not be necessary.

It's good news you have doublescan working! I haven't been able to turn it on for custom modelines in Windows (though the card is capable and it works for default modes). This is due to buggy Catalyst drivers.

By the tests done by VeS and me, lrmc seems a little twisted when dealing with low resolutions. We couldn't force it to produce an exact 256x224 resolution for Toki, using lrmc.conf to store our Hantarex settings. Maybe we're missing something?

I've devoted a lot of time to think about the best way of selecting resolutions for games. I don't believe there's a "perfect way". The selection is monitor dependent. In many cases you just have go for the less bad option, and even then it depends on taste. Now I regret all the development I've done is focused on lowres arcade monitors, but I think it won't be difficult to extend the logic to multisync monitors, and it's a good chance to do it. When I have the time I'll sketch the basic idea, it's not so complicated after all.

Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: bitbytebit on October 12, 2010, 04:03:33 pm
Hi bitbytebit,

We also have that problem with default video modes appearing on us in Windows. Fortunately custom modelines override default modes when they match. But as room for video modes is very limited (60 by default, 200 with my hacked drivers) and these modes waste space we have to "restrict" them, there's a registry key to do this.

It would be great you got SDL to properly deal with vertical refresh. In Windows we have this "integer bottleneck" in the DirectX functions (who would ever want to deal with double precission vfreq values?), that lead me to use that system for differencing modelines. However, this system has a drawback: as variety of video modes reported by Mame xml increases with each new version, you can eventually run out of "x-labels", as fake increased xres reaches the next 8-multiple. Thus, it becomes a need to control the total number of produced modelines - which by the way I must do in Windows to keep the number below the limit - Writing an algorithm that does a good job reducing a resolution list while keeping the most important ones, is not a trivial matter, I'd say it's the most difficult part of the game. I believe lrmc has an implementation of this. There's something more to care about when using this system: Mame tries to center the game frame on the screen, so if you use a fake xres increased more than one pixel you will start loosing pixels on frame's right side, as you'll have a hardware vs logic resolution issue (Mame would work with a logical frame bigger than the screen resolution, so a patch on this would be needed). If SDL thing can be figured out, all this would not be necessary.

It's good news you have doublescan working! I haven't been able to turn it on for custom modelines in Windows (though the card is capable and it works for default modes). This is due to buggy Catalyst drivers.

By the tests done by VeS and me, lrmc seems a little twisted when dealing with low resolutions. We couldn't force it to produce an exact 256x224 resolution for Toki, using lrmc.conf to store our Hantarex settings. Maybe we're missing something?

I've devoted a lot of time to think about the best way of selecting resolutions for games. I don't believe there's a "perfect way". The selection is monitor dependent. In many cases you just have go for the less bad option, and even then it depends on taste. Now I regret all the development I've done is focused on lowres arcade monitors, but I think it won't be difficult to extend the logic to multisync monitors, and it's a good chance to do it. When I have the time I'll sketch the basic idea, it's not so complicated after all.



I'm thinking about hacking at the actual xserver itself, because then I can just stop it from shoving in extra modelines and also might be better to have it and the radeon driver always at the same level.  It's an idea at least, I'm still not certain how practical it is to have an alternate version of it.  just having the radeon driver makes sense, but the whole xserver is saying there's something really wrong.  Interestingly though doing that would allow me to fix the modeline issue for all cards because that is where we could insert them for anybody.  That is where they seem to have possibly removed the functionality I am guessing, and then told the drivers to all create them with the Vesa cvt program.  Also I have found that it definitely isn't labels, but actual sizes that the SDL layer is commanding the X server to change to, so I can't just change the label.  I have just wrote code to test this changing by 1 pixel the horizontal resolution per refresh rate.  So far seems like there's really no more than up to 4-5 duplicate resolutions, but is concerning about how it has to do it this way with SDL 1.2.  So from what I can tell, only SDL 1.3 fixes the refresh issue, I think it also does the vsync stuff too.  Possibly looking at that next and seeing if it works at all, I think I had SDL 1.3 running before but may not have been using switchres and that might be where it is broken actually.  That of course is the only reason we would want to use it, so then would negate any positives about it.

LRMC is odd, because unless you specify the -n option for no stretch, it will add tons to the low resolutions, then make sure you have -l set too for a 5Mhz pixel clock.  Oddly what happens, is when you set things with the lrmc.conf file you don't get the full changes of a CGA monitor as you would with the predefined -cga option.  Since it only changes those values in the config file and not the other key values for the modeline.  If you can get a few good modelines, or one at least, and put it into lrmc.conf it does better at guessing the frontporch and other values like that.  I definitely think lrmc could use a lot of little fixups in how it calculates things, the doublescan works well with the newest ati radeon driver it seems and was broken with the older version I had (it was a month or two old, they just fixed it in the last couple weeks from the change log).   I have to basically keep lrmc under control and only say try doublescan if the resolution is <= 192, else it would do it for everything it can that wants a large resolution.  It will go out of range of the proper Vsync values willingly when using doublescan, can double what you put into the config or the preset values.  At least from what I can tell, I might be wrong on that, but the xrandr program says they are big.  Also I have tried using xrandr and it is just very unstable and terrible at doing the resolution switching, won't even work with this ati radeon driver possibly because it's newer than the xserver I'm using.  So another reason I want to look at the xserver and see about hacking at it to fix the default resolutions.  overriding them is an option but it get's tricky because then you've got a resolution that isn't incremented by 1 and have to be exact while right now I'm by default incrementing them by one to avoid the default resolutions.  I need to figure out how to avoid that, I have some ideas, probably just make the first label not include the refresh rate which will override the default ones.  Although those default ones are annoying because it'll put 3 sometimes possibly of one resolution all with the basic label like "640x480" and I'm not sure it really will override all 3 if I add one more to that mess.  So hacking the xserver would allow me to trust the resolutions to have the first one at the right Horizontal size and additional ones increment from there.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: bitbytebit on October 12, 2010, 04:51:52 pm
Hi bitbytebit,

We also have that problem with default video modes appearing on us in Windows. Fortunately custom modelines override default modes when they match. But as room for video modes is very limited (60 by default, 200 with my hacked drivers) and these modes waste space we have to "restrict" them, there's a registry key to do this.

It would be great you got SDL to properly deal with vertical refresh. In Windows we have this "integer bottleneck" in the DirectX functions (who would ever want to deal with double precission vfreq values?), that lead me to use that system for differencing modelines. However, this system has a drawback: as variety of video modes reported by Mame xml increases with each new version, you can eventually run out of "x-labels", as fake increased xres reaches the next 8-multiple. Thus, it becomes a need to control the total number of produced modelines - which by the way I must do in Windows to keep the number below the limit - Writing an algorithm that does a good job reducing a resolution list while keeping the most important ones, is not a trivial matter, I'd say it's the most difficult part of the game. I believe lrmc has an implementation of this. There's something more to care about when using this system: Mame tries to center the game frame on the screen, so if you use a fake xres increased more than one pixel you will start loosing pixels on frame's right side, as you'll have a hardware vs logic resolution issue (Mame would work with a logical frame bigger than the screen resolution, so a patch on this would be needed). If SDL thing can be figured out, all this would not be necessary.

It's good news you have doublescan working! I haven't been able to turn it on for custom modelines in Windows (though the card is capable and it works for default modes). This is due to buggy Catalyst drivers.

By the tests done by VeS and me, lrmc seems a little twisted when dealing with low resolutions. We couldn't force it to produce an exact 256x224 resolution for Toki, using lrmc.conf to store our Hantarex settings. Maybe we're missing something?

I've devoted a lot of time to think about the best way of selecting resolutions for games. I don't believe there's a "perfect way". The selection is monitor dependent. In many cases you just have go for the less bad option, and even then it depends on taste. Now I regret all the development I've done is focused on lowres arcade monitors, but I think it won't be difficult to extend the logic to multisync monitors, and it's a good chance to do it. When I have the time I'll sketch the basic idea, it's not so complicated after all.



I'm thinking about hacking at the actual xserver itself, because then I can just stop it from shoving in extra modelines and also might be better to have it and the radeon driver always at the same level.  It's an idea at least, I'm still not certain how practical it is to have an alternate version of it.  just having the radeon driver makes sense, but the whole xserver is saying there's something really wrong.  Interestingly though doing that would allow me to fix the modeline issue for all cards because that is where we could insert them for anybody.  That is where they seem to have possibly removed the functionality I am guessing, and then told the drivers to all create them with the Vesa cvt program.  Also I have found that it definitely isn't labels, but actual sizes that the SDL layer is commanding the X server to change to, so I can't just change the label.  I have just wrote code to test this changing by 1 pixel the horizontal resolution per refresh rate.  So far seems like there's really no more than up to 4-5 duplicate resolutions, but is concerning about how it has to do it this way with SDL 1.2.  So from what I can tell, only SDL 1.3 fixes the refresh issue, I think it also does the vsync stuff too.  Possibly looking at that next and seeing if it works at all, I think I had SDL 1.3 running before but may not have been using switchres and that might be where it is broken actually.  That of course is the only reason we would want to use it, so then would negate any positives about it.

LRMC is odd, because unless you specify the -n option for no stretch, it will add tons to the low resolutions, then make sure you have -l set too for a 5Mhz pixel clock.  Oddly what happens, is when you set things with the lrmc.conf file you don't get the full changes of a CGA monitor as you would with the predefined -cga option.  Since it only changes those values in the config file and not the other key values for the modeline.  If you can get a few good modelines, or one at least, and put it into lrmc.conf it does better at guessing the frontporch and other values like that.  I definitely think lrmc could use a lot of little fixups in how it calculates things, the doublescan works well with the newest ati radeon driver it seems and was broken with the older version I had (it was a month or two old, they just fixed it in the last couple weeks from the change log).   I have to basically keep lrmc under control and only say try doublescan if the resolution is <= 192, else it would do it for everything it can that wants a large resolution.  It will go out of range of the proper Vsync values willingly when using doublescan, can double what you put into the config or the preset values.  At least from what I can tell, I might be wrong on that, but the xrandr program says they are big.  Also I have tried using xrandr and it is just very unstable and terrible at doing the resolution switching, won't even work with this ati radeon driver possibly because it's newer than the xserver I'm using.  So another reason I want to look at the xserver and see about hacking at it to fix the default resolutions.  overriding them is an option but it get's tricky because then you've got a resolution that isn't incremented by 1 and have to be exact while right now I'm by default incrementing them by one to avoid the default resolutions.  I need to figure out how to avoid that, I have some ideas, probably just make the first label not include the refresh rate which will override the default ones.  Although those default ones are annoying because it'll put 3 sometimes possibly of one resolution all with the basic label like "640x480" and I'm not sure it really will override all 3 if I add one more to that mess.  So hacking the xserver would allow me to trust the resolutions to have the first one at the right Horizontal size and additional ones increment from there.

Just did some tests, got my incrementing code so it only does it when needed, I also had to make it back off and decrease by 1 for duplicates when they were at the maximum horizontal size like 640x480.  Would decreasing it be an option that at least wouldn't go off screen and instead just slightly reduce the picture by a pixel or two?  Basically I am now just making my modeline labels the "HxW" format to try and beat the default ones X inserts (there's only two really with my Hsync/Vsync values low enough, there's a  640x480 and 320x240, which work but the 320x240 one has too high of Vrefresh and also is off center).  It looks like from what I can tell I can't really override the default ones this way, it'll just force them in there still and then it's up the the sorting process which one wins out and is on top. The duplicating method beats them it seems because they are always one pixel more and it seems to sort them by H values.  I guess that's a downfall of the decreasing method, unless we can really knock those things out of there.

Also I've found that lrmc really is no good at anything besides EGA/VGA calculations, the VGA are off and then the SVGA are way off.  The default resolution X windows uses seems to have been what overrides my default screen for X normally, because when I incremented them it got all warped and it turns out that the lrmc VGA resolutions are just bad.  It also shows how X aggressively replaces and prioritizes the resolutions it has over your own, at least with that one it did because it's always been used even when I thought it couldn't be.  This I guess is yet another sign I might need to change the xserver itself, which I know where exactly the code is to do it.  Calling that function from the Radeon driver itself and redoing it might work, but I'm not sure all the code from that function can port into the Radeon driver and still work.  It's the basic X xf86InitialConfiguration() function where it takes are modelines we added and the default ones it chose for us and combines them all together.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: bitbytebit on October 13, 2010, 04:00:51 am
Version .9 is up, now on sourceforge or my website since it got larger with the additional optional xserver source with default modeline setup removed to avoid useless ones we don't ever use on an arcade monitor.  It also has an xrandr resolution switching wrapper script that solves the issue with having multiple resolutions with the same height and width but different refresh rate.  Lots of bug fixes, read the first post on the thread for more details.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: Calamity on October 13, 2010, 04:40:24 am
Hi bitbytebit,

I'ts so good you figured out how to fix the built-in modelines issue and also included xrandr functionallity.

It's funny that the x server messes with modelines, that's not what it's supposed to do according to this:

http://www.x.org/archive/X11R6.8.1/doc/xorg.conf.5.html (http://www.x.org/archive/X11R6.8.1/doc/xorg.conf.5.html)

Quote
The Identifier entry specifies the unique name for this monitor. The Monitor section provides information about the specifications of the monitor, monitor-specific Options, and information about the video modes to use with the monitor. Specifying video modes is optional because the server now has a built-in list of VESA standard modes. When modes are specified explicitly in the Monitor section (with the Modes, ModeLine, or UseModes keywords), built-in modes with the same names are not included. Built-in modes with different names are, however, still implicitly included.

As for the increasing/decreasing method, I think decreasing is not an option, as you must consider xres to be measured by characters (8 pixel block) instead of pixels. When passing xres values to the hardware, at some point I believe Xres is rounded to its lower 8-multiple, as VGA registers work with characters (btw, that's why the horizontal part of the modeline must use 8-multiples). So if you decrease xres you might loose 8 pixels instead of one (I haven't tested this).

Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: bitbytebit on October 13, 2010, 04:46:54 am
Hi bitbytebit,

I'ts so good you figured out how to fix the built-in modelines issue and also included xrandr functionallity.

It's funny that the x server messes with modelines, that's not what it's supposed to do according to this:

http://www.x.org/archive/X11R6.8.1/doc/xorg.conf.5.html (http://www.x.org/archive/X11R6.8.1/doc/xorg.conf.5.html)

Quote
The Identifier entry specifies the unique name for this monitor. The Monitor section provides information about the specifications of the monitor, monitor-specific Options, and information about the video modes to use with the monitor. Specifying video modes is optional because the server now has a built-in list of VESA standard modes. When modes are specified explicitly in the Monitor section (with the Modes, ModeLine, or UseModes keywords), built-in modes with the same names are not included. Built-in modes with different names are, however, still implicitly included.

As for the increasing/decreasing method, I think decreasing is not an option, as you must consider xres to be measured by characters (8 pixel block) instead of pixels. When passing xres values to the hardware, at some point I believe a "Xres MOD 8" operation is performed, as VGA registers work with characters (btw, that's why the horizontal part of the modeline must use 8-multiples). So if you decrease xres you might loose 8 pixels instead of one (I haven't tested this).


Yeah, this xrandr stuff is just really strange though because it worked pretty well then crashed and after reboot it really didn't act like I expected.  So I guess it's some hope, but now looking like 50% better than waiting for SDL 1.3 to arrive, which claims to fix the vsync issues (although seems if it isn't working yet then it hasn't yet, but that must be why it's taking so long).  The incremental stuff at least works quite well, I get the best overall look of the games from it so far, definitely my favorite right now.  I don't know if this xrandr is really unstable or I just need to update all of my X Windows to the current versions, but that seems pretty crazy and not expecting everyone to do that because it's a big task.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: elvis on October 16, 2010, 08:29:00 am
I just want to say thanks especially to Calamity and bitbytebit for all their open discussion in this thread.  It's explained a hell of a lot for me, and why I've been having so many dramas with recent Xorg builds (the forced 60.00Hz issue and Xorg ignoring my modeline refresh was driving me nuts).

I'll be playing with xrandr over the next week myself (based on the perl script in the GenRes stuff) to see if that solves my issue.  I'm using NVidia hardware and hacked nv_drv.so myself to force pclocks lower than 12MHz (which is hard set in the nv drivers). 

But yeah, thanks again to you both.  This thread has shone a lot of light on a few issue for me. 
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: bitbytebit on October 16, 2010, 12:38:09 pm
There's a lot of brick walls it seems in linux for Arcade monitors, which I'm finding and working on breaking.  First the Xorg servers all seem to not have options for CGA/EGA or anything below 31Khz, plus the pclock lock and moving away from modelines and to CVT.  On top of that I'm finding that there is also the kernel framebuffer which has similar issues where the drivers force a higher minimum pclock.  Last night I changed uvesafb to allow a lower pclock and finally got mame to modeswitch using an fb.modes file to arcade resolutions.  Still working out issues there, but it at least finally responded unlike the default vesa framebuffer which is useless for an arcade monitor or the radeon one which seems to ignore my ArcadeVGA card (still not sure why about that).  Also there's the fact we aren't into the Vertical Refresh rate being accurate till SDL 1.3 which currently the newest build is broken with mame.  I have a patch which makes it work, and it's really nice how it truly can choose the right modeline by both resolution and refresh rate.  It also has a vsync support I guess, so it all looks neat.  The only issue though is they haven't implemented the ability to hide the mouse cursor or turn it into a full  non-limited mouse.  So any game needing a mouse, trackball, spinner has limits of the mouse movement to the sides of the screen and you see a huge mouse all the time.  SDL 1.3 though is nice for games like pacman or any other simpler classic games, just avoids the incrementing the horizontal frame size hack.  I've got a newer version of genres coming which I'm now mainly working on besides some odds n ends for bug fixes, getting the vertical refresh rates as perfectly accurate as possible (to avoid needing as many vsync hacks).  Of course this really is mostly geared at Wells Gardner D9x00 monitors which can somewhat go into odd Horizontal refresh rates above 15.725 so I can actually run pacman at Vertial 60.61Hz and 252x288 by going into 19.2Khz horizontal refresh rates (which I've really notices the games act so much nicer when they match the right refresh rate). With this I've also been working on learning the modeline voodoo to be able to improve lrmc, studying the modelines from Soft 15Khz to try and learn what they are doing because those modelines are always really nice examples to go by.  I have actually found some tweaks to lrmc which seems like it is creating modelines much more like the ones I see people using in Windows/Soft15Khz, one is the vertical game aspect ratio/horizontal width sizing which in lrmc is different and I think I figured out how to correct it.  I'm still trying to figure out though how to make sure the refresh rates are good enough for people with just arcade monitors, yet be able to get them exact for people with this multisync able to do 15-40Khz WG type monitors.  Hopefully I post a new genres by the end of the weekend with those general fixes, and the SDL 1.3 patch to mame for those who want to play with it.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: Calamity on October 16, 2010, 06:04:32 pm
Hi there,

I've been out for some days and, I'll try to catch up with the new info. I'd like to thank bitbytebit again and the others.

These days I've been thinking about the vfreq ignoring issue with SDL 1.2. There is a way to overcome it, I believe. Maybe you've already tested this and I didn't follow. We can use a resolution table for xorg.conf, without explicit vfreq. This table would be created condensating the whole Mame video mode list by omitting vfreq values. Mame inis would just include WxH values. For each of these resolutions we should create a sample modeline, (say 60Hz) which will be included in xorg.conf. Mame already knows the valid vfreq values for each game, so we just need to patch Mame so it invokes lrmc for the right values before it tryes to switch video mode. A new "throw-away" modeline would be created which should be made available for Radeon driver by any means (could it overwrite the sample one in xorg.conf?). Now, Mame would invoke video mode switching without pushing vfreq. As there is just one modeline defined for this resolution, the one we just created, the proper video mode should be invoked.

I'm not sure how this can colide with the built-in video mode list, but the general idea of having a fixed resolution table with default vfreq values and tuning the existing mode to the refresh we request before switching video mode is the approach I'd like to implement for Windows in the near future.

Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: Calamity on October 16, 2010, 07:10:52 pm
I'm still trying to figure out though how to make sure the refresh rates are good enough for people with just arcade monitors, yet be able to get them exact for people with this multisync able to do 15-40Khz WG type monitors.

I've never touched a multisync monitor, I need to get one of these WG. I wonder if 15-40KHz sync range is continuous or it has some gaps (I think so). If you have several separate intervals, I think the best approach would be to consider each one as a single monitor, with it's own HfreqMin - HfreqMax valid interval, then choose the best one for the mode we want to produce, or the only one we have if it's a non multisync monitor. Otherwise you'll get a lot of hardcoded conditionals for each particular case. The definitive approach is to produce our modeline for all of those virtual monitors: for some of them it'll be necessarily degradated (doublescaned, interlaced-stretched, bad vfreq, bad res), depending on the valid hsync interval and the general conditions we set in the algorithm, so we'll get a score that accounts for this degradation. This score will be used to choose the best modeline and discard the others. I'd like to go more into this when I have some time. If you need any help with modeline calculation just let me know.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: bitbytebit on October 16, 2010, 10:27:55 pm
I'm still trying to figure out though how to make sure the refresh rates are good enough for people with just arcade monitors, yet be able to get them exact for people with this multisync able to do 15-40Khz WG type monitors.

I've never touched a multisync monitor, I need to get one of these WG. I wonder if 15-40KHz sync range is continuous or it has some gaps (I think so). If you have several separate intervals, I think the best approach would be to consider each one as a single monitor, with it's own HfreqMin - HfreqMax valid interval, then choose the best one for the mode we want to produce, or the only one we have if it's a non multisync monitor. Otherwise you'll get a lot of hardcoded conditionals for each particular case. The definitive approach is to produce our modeline for all of those virtual monitors: for some of them it'll be necessarily degradated (doublescaned, interlaced-stretched, bad vfreq, bad res), depending on the valid hsync interval and the general conditions we set in the algorithm, so we'll get a score that accounts for this degradation. This score will be used to choose the best modeline and discard the others. I'd like to go more into this when I have some time. If you need any help with modeline calculation just let me know.


I've asked the Wells Gardner support guy about the range, and if it's continuous or if not what are the tolerance levels.  The lrmc guy seems to have gone through this with the 9200 but it was different and the 9400/9800 seem to have both extended the range to include SVGA and also seems more robust about handling that entire range.  In lrmc it is built to do this, basically can define how ever many ranges of details and it scores each and usually seems to pick the right one.  So this is a good thing about lrmc, the trick is that you can't really define them in the config like the hard coded structures in linked list setup used for the -cga/ega/d9200 etc. predefines.  I actually think the way it is setup in lrmc should in theory be pretty good at working for basic CGA monitors where you know the values, as long as a user can input the complete setup into the config or on the command line.  There are details with the calculations for the 9200/9800 I'm trying to work out and the Wells Gardner guy hopefully will help with that, knowing the true limits.  Although I can make it do anything in that range and it seems to work fine, I just want to make sure they approve.  I think in lrmc the main issues with it's calculations are the centering or back/front porch calculations, and that may just be when it comes to these Wells Gardner type monitors since they are very tricky to pin down what they are since they are all types of monitors in one.

The X windows thing is interesting, having mame create the modelines itself.  The tricky part though is, at least from what I've seen, the stuff that dynamically puts modelines into X windows isn't stable, kind of slow, and often crashes it.  I've seen it using xrandr and also read threads of people saying that xrandr often will either not work or crash X randomly on them.   The other issue is that the whole window centering and general management of SDL onto the X display doesn't work as well outside of letting SDL do it.  I can use xrandr, but then I have to really work to get the games to position themselves inside the visible screen area since X likes to be virtual windowed when changing modes to smaller display sizes.  I am guessing SDL takes care of all this usually, and without it doing that part things just seem way less stable and smooth.  SDL 1.3 really looks exciting because of that, and the Vsync stuff it seems to have, although I'm not sure if it's 100% perfect or as good as triplebuffer (although I've read that seems to be slightly imperfect at times for some too).  Also I saw logs on the Soft 15Khz threads which seem to indicate that in Windows it can actually utilize the refresh rate of modelines, at least seemed like it prints out the information which it does for SDL 1.3 but not for SDL 1.2. So I assumed doing that it was  able to at least pick it somewhat, much better than totally ignoring it in SDL 1.2 and X just picking the first modeline that matches the height and width.  Sounds like the best solution would be to dynamically create them for X though, if only X windows was stable in that area.  It seems like the right way to do it according to the X windows stuff, use xrandr protocol and add/choose them that way, and would think that SDL at least could do that for us and we wouldn't need modelines or mess with them in mame at all either.  I think SDL is doing it the most stable current way though and that seems to require modelines, I've looked at the idea of porting SDL 1.3 code into 1.2 just to include Vsync and/or taking code from SDL 1.3 and including it in mame.  They look really complicated though, both options would require a lot of heavy lifting and end up having something probably hard to maintain through releases and become out dated as soon as SDL 1.3 is done.  It really seems like SDL 1.3 is close with just needing the mouse hiding to be done, but then again I'm not sure, but from the mailing lists it looks like it may be settling down sooner or later into a stable fully working release.  Is using SDL on Windows a bad thing compared to the other options there?  Would think that SDL 1.3 would fix both Linux and Windows, if it also works well in Windows that is.  Possibly just adding some type of fixes to be like triplebuffer or proper vsync.  I also have read that the vsync issues are really an X windows one and they have indicated in a future release they will have some option for vsync with the X server.  I'm not sure if that's in newer ones, distributions use 1.7.7 currently and they are on 1.9.0 right now so not sure if it's been done yet (and 1.9.0 doesn't compile the radeon driver so guessing it's not stable and not all parts have caught up to it yet).
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: Calamity on October 17, 2010, 05:53:53 pm
Is using SDL on Windows a bad thing compared to the other options there?  Would think that SDL 1.3 would fix both Linux and Windows, if it also works well in Windows that is.  Possibly just adding some type of fixes to be like triplebuffer or proper vsync.  I also have read that the vsync issues are really an X windows one and they have indicated in a future release they will have some option for vsync with the X server.

I'm right now testing Win32 SDLMame in my laptop, after some tweaking it's running perfectly smooth and vsyncronized, the right settings in Windows seem to be: video opengl, keepaspect 0, unevenstretch 0, waitvsync 1, throttle 0, switchres 1. If 'video soft' is used, I can't get vsync working. I still have to test it using custom video modes in my cabinet, but it's quite probable it can replicate DirectX functionallity managing modes. However, there's still this inherent limitation of integer values for refresh rates, imposed by the system and drivers inner calls. In Windows, any API we use for going fullscreen will be conditioned by that.

From Windows point of mind, Linux way of using xrandr method seems strange, it looks like resizing the desktop before maximizing the window, affecting all applications. Although we have Win32 APIs to resize the desktop resolution, they are not used in this context, DirectX api (and SDL I suppose) are used to switch video modes instead and use the screen in exclusive mode, so you can access the advanced video features. The method I suggested would just use plain SDL to go fullscreen, i.e. "320x224", but we'll make sure the proper refresh will be used by making an unique modeline available to the driver at the 320x224 resolution, so it should not fail... anyway this is just theory.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: bitbytebit on October 18, 2010, 02:43:19 am
Is using SDL on Windows a bad thing compared to the other options there?  Would think that SDL 1.3 would fix both Linux and Windows, if it also works well in Windows that is.  Possibly just adding some type of fixes to be like triplebuffer or proper vsync.  I also have read that the vsync issues are really an X windows one and they have indicated in a future release they will have some option for vsync with the X server.

I'm right now testing Win32 SDLMame in my laptop, after some tweaking it's running perfectly smooth and vsyncronized, the right settings in Windows seem to be: video opengl, keepaspect 0, unevenstretch 0, waitvsync 1, throttle 0, switchres 1. If 'video soft' is used, I can't get vsync working. I still have to test it using custom video modes in my cabinet, but it's quite probable it can replicate DirectX functionallity managing modes. However, there's still this inherent limitation of integer values for refresh rates, imposed by the system and drivers inner calls. In Windows, any API we use for going fullscreen will be conditioned by that.

From Windows point of mind, Linux way of using xrandr method seems strange, it looks like resizing the desktop before maximizing the window, affecting all applications. Although we have Win32 APIs to resize the desktop resolution, they are not used in this context, DirectX api (and SDL I suppose) are used to switch video modes instead and use the screen in exclusive mode, so you can access the advanced video features. The method I suggested would just use plain SDL to go fullscreen, i.e. "320x224", but we'll make sure the proper refresh will be used by making an unique modeline available to the driver at the 320x224 resolution, so it should not fail... anyway this is just theory.


Are you testing SDL 1.3 or 1.2 in Windows?  I can't get the throttle setting to work at 0, it just goes full speed in Linux and I'm using 1.2 opengl and also tried 1.3 but have been using -video sdl13 there. 

There's quite a few bugs I've found with my method of width size incrementing, but have fixed them somewhat and now it kind of works as a work around but definitely hopeful it can be avoided. 

I also found a big bug/memory leak in the radeon driver I introduced by the way I was getting the modelines, I think that was the instability I was seeing in xrandr since it calls that function each and every call to re-add the modelines.  I am pretty sure it should work smooth now without issue, and it sounds interesting to just add the modeline for each game upon start and remove after finish.  My perl script would be easy to do this with, using lrmc to calculate the modeline add it and switch to it, switch back to the default and delete that modeline on exit.  This seems like the cleanest way to do things to me, and avoid needing to patch mame as much as patching the radeon driver and possibly the xserver  to avoid annoying extra modelines that override custom ones.  It would be nice to have mame call the xrandr stuff itself but I get the feeling it's really tied into SDL  and we'd get the same functionality through the perl script method, and avoid having to pack lrmc and xrandr into mame code and maintain it.  Plus SDL 1.3 pretty much will do the same, and should be able to use  refresh rates as doubles (I think my patch allows this, but I haven't inspected it to check for SDL possibly having the limitation to integers).  Again it goes back I guess to using the xrandr perl script and external lrmc being the most universal solution if SDL 1.3 still doesn't allow it to perfectly call xrandr functions. 

   
Hopefully tomorrow I'll have an updated genres with the fixed radeon drivers memory leak, lrmc that increments horizontal size for SDL 1.2, and possibly try to get the xrandr perl script to dynamically generate and force modelines from the ini files (which should be able to avoid the ini files, maybe build a DB of resolutions from the mame.xml for it to use so it knows each games needs).  I have also possibly gotten lrmc to output a lot better aspect ratios for the vertical games, which before I think the calculation for that was kinda strange.  It at least never matched the modelines I saw others generate and made it hard to match refresh rates without getting odd sizes.  For some reason it divided the horizontal size on a vertical game by .5625 and now I'm multiplying the vertical size by 1.33333 for a 4x3 screen (which seems to work better, really curious though, seems a lot of people use 1.22222 and not sure why).  Here's the code basically how that's done...
Code: [Select]
if (mode->aspect3x4 == 1) {
+      /* Vertical games */
+      //mode->hres = mode->hres / 0.5625;
+      mode->hres = align(mode->vres * (1.33333), 8);
+    } else if (!mode->aspect3x4 && (mode->hres < mode->vres)) {
+      /* Odd games */
+      if (mode->refreshrate <= 30.5) {
+        mode->refreshrate = mode->refreshrate * 2.0;
+       //mode->vres = align(mode->vres / 2.0, 8);
+      } else {
+       //mode->hres = mode->hres / 0.5625;
+        mode->hres = align(mode->vres * (1.33333), 8);
+      }
+    }
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation
Post by: bitbytebit on October 18, 2010, 06:35:31 am
Is using SDL on Windows a bad thing compared to the other options there?  Would think that SDL 1.3 would fix both Linux and Windows, if it also works well in Windows that is.  Possibly just adding some type of fixes to be like triplebuffer or proper vsync.  I also have read that the vsync issues are really an X windows one and they have indicated in a future release they will have some option for vsync with the X server.

I'm right now testing Win32 SDLMame in my laptop, after some tweaking it's running perfectly smooth and vsyncronized, the right settings in Windows seem to be: video opengl, keepaspect 0, unevenstretch 0, waitvsync 1, throttle 0, switchres 1. If 'video soft' is used, I can't get vsync working. I still have to test it using custom video modes in my cabinet, but it's quite probable it can replicate DirectX functionallity managing modes. However, there's still this inherent limitation of integer values for refresh rates, imposed by the system and drivers inner calls. In Windows, any API we use for going fullscreen will be conditioned by that.

From Windows point of mind, Linux way of using xrandr method seems strange, it looks like resizing the desktop before maximizing the window, affecting all applications. Although we have Win32 APIs to resize the desktop resolution, they are not used in this context, DirectX api (and SDL I suppose) are used to switch video modes instead and use the screen in exclusive mode, so you can access the advanced video features. The method I suggested would just use plain SDL to go fullscreen, i.e. "320x224", but we'll make sure the proper refresh will be used by making an unique modeline available to the driver at the 320x224 resolution, so it should not fail... anyway this is just theory.


I have xrandr working great now, doing it the way your suggesting and dynamically creating the modelines when starting each game so it knows what it will get.  This seems to work great, and after fixing the radeon driver memory leak it's very fast and not unstable anymore.  It works better than anything I've seen yet and very good a getting the vertical refresh as close as possible depending on the monitor.  Still need to look into if SDL 1.3 really fixes Vsync when it's not exact, or what other options there are in Linux SDL.  I do see this option "-refreshspeed        automatically adjusts the speed of gameplay to keep the refresh rate lower than the screen" which looks like it might help with that when games aren't able to get a perfect refresh rate.  Also I have an xrandr patch, and it requires the newest GIT of xrandr, because older versions used integers for the dotclock modeline value and the newest doesn't but I modified it to really get it exact, was a slight bit of rounding decimal places still.  There's an xrandr.diff patch for that now, and the mame_xrandr.pl script takes the game and monitor type like "mame_xrandr.pl pacman -m d9800" or if no monitor is given it uses lrmc.conf.  It does take advancemame type clock lines supposedly to get the right blanking times, so that is something interesting rather than using example modelines.  The source seems to have that info in it, haven't seen that talked about anywhere else and using it kinda worked for me but either I had a bad line for it or it's a bit buggy.  I think in general the xrandr method is really a good way to go, avoids messy modelines and does exactly like you had thought in really forcing the exact resolution.  I'm thinking that building this into MAME might be interesting, but then again it also might really not get us much more than we have using a perl script.  Also you still have to create the .ini files, I'm thinking that's best because it's basically a database anyways and we are actually letting MAME do the modeswitching and just adding modelines with X to have mame find.  Also the .ini files have extra info for games that need keepaspect and unevenstretch when they either are at the default resolution or can't calculate a modeline which has a large enough vertical height for them.  This version really ought to be interesting because it brings in a lot more possibilities using xrandr, and also makes it a lot easier and might eventually allow us to drop needing any modified X servers/drivers (I'm not fully sure they are needed anymore, probably nicer for an arcade monitor since the modified ones prevent stray odd  resolutions from being generated, but then again most of those can be removed by just setting the Vsync/Hsync values correctly in xorg.conf.  Although with a WG 9800 since it has a big range X goes a bit crazy with the defaults).

Also another thing I can't figure out is how to get good console support, all the frame buffer drivers seem aimed at vesa from the bios and will not allow fully alterable modelines.  I think they actually are forcing the pixelclock to be a decimal or something, same as old xrandr versions did.  The uvesafb seems close in working, the radeonfb seems not to detect the newer ArcadeVGA cards since they have RV600 chips and the linux fb driver only goes up to the RV400 chips.  So my linux console is always a bit out of wack for even a d9800 and I'm sure a normal arcade monitor would just hate the mode it's in.  Not sure how this is done in the distributions exactly for arcade linux systems, but it's something I've been trying to figure out too.

So your theory looks pretty good following my xrandr perl script prototype/working model :).   I'm quite amazed actually, because I had been seeing unstableness with xrandr and the modelines weren't right but those ended up being the memory leak and the older xrandr versions.  Once fixing those two things, xrandr works great (plus figuring out how to exactly use the utility, the perl script definitely is interesting in doing all the dirty work for you to get xrandr to add/delete modelines).

Version .10 is up, and it hopefully is working well with xrandr, even decent with the sdl 1.2 hres fix although I can see what you mean about the screen getting pushed right more and more.  I did do something where I recalculate the modeline with the new values without having it align to 8 bytes.  I found a problem though in general with this method where you basically in mame get a chopped right side even on vertical games of the difference of 8 pixel alignment.  So I guess that makes the xrandr even better and necessary, otherwise you would have to move 8 pixels per modeline to really keep mame from chopping pixels.
Title: Re: Radeon X Driver for ArcadeVGA capability and lrmc .ini file generation (ver .10)
Post by: bitbytebit on October 18, 2010, 09:48:34 am
Got confirmation from Wells Gardner about the D9800 Horizontal Freq ranges.  He says they are not fixed, no danger to the monitor, and basically it can do anywhere in the range of 15.250 - 40.00 Khz.  Pretty interesting, seems it isn't like the d9200 then where it sounds like it's fixed points for CGA/EGA/VGA areas.  That's good because I've been really getting close exact vertical refresh rates for most games now by allowing the Horiz Khz to go up to  19Khz, so with the d9800 it should be able to natively handle the vsync issues just by setting the modeline up right.  I need to figure out how to get a few of the modelines that get up closer to 20Khz from being skewed left a little, although it's mostly vertical games like pacman where it's not a big issue.  I seem to possibly need an extra displaymode in lrmc for the range right above CGA mode between that and EGA mode with different horizontal timing for the blanking and stuff.  I have a set where I changed the horizontal values and it seems to shift it back but I need to separate it and have it only used for those specific areas in 17-20Khz since when it's used for lower ones then it can skew them the opposite way.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: bitbytebit on October 20, 2010, 12:36:50 am
Version 0.11   Now makes this a much simpler solution, and universal for all graphics cards, best for ones with low dotclock abilities. 
* no longer need any .ini files or modelines in the xorg.conf file, can dynamically generate modelines and put them into X with xrandr, removing them when done.
* now can run any emulator with the dynamic modelines and switchres wrapper.
* removed all the Xorg/Radeon stuff, just patches for each now since it's not really necessary to install/patch X anymore.
* big improvements to lrmc decisions in modeline creation, good general modeline creator and should be useful for Soft15Khz modeline creation or any other system.
* much easier to get to working immediately, simpler, just install the modified lrmc, install the newest xrandr wtih my patch applied and wrap MAME with switchres or MESS or any other emulator.
* should be much easier to eventually get this working in Windows too, just need to figure out ways to add custom modelines dynamically to the drivers and remove them I guess.  The lrmc
   program compiles under Windows and switchres is Perl so will run in Windows.  Not working yet, but it is a goal to eventually make this a universal dynamic modeline generator across all platforms
   for emulators to use.
* can attach zip file again to this message because it's now very small from not including all the extra X org stuff.
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 20, 2010, 02:09:45 am
I've wondered about the games not all having correct information, definitely can see some that the info just doesn't seem right and it's hard to get the to display nicely.  Also the pixelclock values are there for some, but when I try to use that in my calculations which I can do in lrmc as a minimum, it just makes some games become too small on the screen.

Pixelclock values in mame.xml as well as porch values are precious information by their own, and also if we intended to replicate the exact original video signal, but I'm afraid this is not the way to go if we want to have hundreds of games simultaneously centered on the monitor, so we must redefine the pixelclock for each video mode resulting for the porchs (borders) we want to have, which should be as constant as possible among different video modes, to avoid having to be adjusting our monitor all the time (this is only possible with horizontal borders, vertical amplitud must be adjusted manually). At the same time we have to keep our vertical frequency as close as possible to the original.

It's definitely fun to work on this, started this arcade cabinet as a project for myself and had to use Linux cause that's all I ever have used for anything, which has led me on a mission to share what I am doing for myself which I want to basically make this stuff work on Linux as good as Windows.  Oddly I'm surprised that it seems we probably already  have surpassed Windows in some ways because of the ability to really access the hardware directly through the X server, have unlimited modelines, and not have any doors permanently closed so pretty much should only be limited by what the hardware really can do and time it takes to program it.

Definitely that functionallity is not available in Windows. Well, I have managed to trick the Catalsyt video driver to "reset" itself on the fly so it will read the registry modelines without the need of rebooting, so I would eventually have unlimited modelines also in Windows, but I still have to figure out how to make this available for different emulators (I believe the only option is a sort of loader), and definitely your Linux method is much cleaner and straightforward.

My biggest concern with Linux and the X Radeon driver is if you can really achieve a proper Vsync functionallity. I have heard there were problems with these cards and vsync, I hope it's been solved. Some folks had problems with this in the Spanish forum:

http://www.retrovicio.com/foro/showthread.php?t=8250&highlight=investigaci%C3%B3n (http://www.retrovicio.com/foro/showthread.php?t=8250&highlight=investigaci%C3%B3n)

Thanks for the good work!





Guessing from reading this, that you could probably trick the radeon driver in Windows to take the lrmc generated modeline of my new switchres script and use your method in Windows instead of xrandr in Linux.  This sounds quite interesting, do you think other Windows graphics drivers can be tricked this way, or have they, how exactly would I need to go about adapting switchres to do this when run in windows?  From the amazing functionality I'm having in Linux with switchres now, being able to generate modelines dynamically and get pretty good modelines and not rely on .ini files, seems this would be great now combined with your ability to push modlines into the radeon driver in Windows.  If only this could be done for even more video cards in Windows too, then we'd really have something extra interesting.  If we can make switchres work exactly the same in both Windows and Linux, that would be great, and I think at least with the radeon driver this seems very possible.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: elvis on October 20, 2010, 08:02:22 am
I'm having troubles patching XRandR with the 0.11 download above.

I do:

# unzip GenRes-0.11.zip
# cd GenRes-0.11
# git clone git://anongit.freedesktop.org/xorg/app/xrandr
# cd xrandr
# git apply --stat ../patches/xrandr.diff
 xrandr.c |   18 ++++++++++--------
 1 files changed, 10 insertions(+), 8 deletions(-)
# git apply --check ../patches/xrandr.diff
error: patch failed: xrandr.c:1426
error: xrandr.c: patch does not apply

Have I done something wrong?
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: bitbytebit on October 20, 2010, 08:40:32 am
I'm having troubles patching XRandR with the 0.11 download above.

I do:

# unzip GenRes-0.11.zip
# cd GenRes-0.11
# git clone git://anongit.freedesktop.org/xorg/app/xrandr
# cd xrandr
# git apply --stat ../patches/xrandr.diff
 xrandr.c |   18 ++++++++++--------
 1 files changed, 10 insertions(+), 8 deletions(-)
# git apply --check ../patches/xrandr.diff
error: patch failed: xrandr.c:1426
error: xrandr.c: patch does not apply

Have I done something wrong?

Try to patch it like this when in the xrandr directory...


cat ../patches/xrandr.diff | patch -p1 -E -l

This most likely should do it, I think I did something odd there and that avoids whitespaces and such.  I'll maybe include xrandr from now on because it's small and actually would like to sort of merge it and lrmc somewhat perhaps in functionality in the future.


Thanks for catching that and letting me know the patch is a bit off :)
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: elvis on October 20, 2010, 09:09:00 am
cat ../patches/xrandr.diff | patch -p1 -E -l
Yup, the "-l" flag fixed it.  Cheers.  I'd also tried "patch" before without "-l" and it failed too, but all good now. 
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: elvis on October 20, 2010, 10:54:56 pm
I have one lingering problem.  I don't think it's related to your switchres program, but something else.

I have a default 640x480@60Hz interlaced modeline in Xorg (if I have no modeline, Xorg won't start).  Running Ubuntu 10.04.

Whether I run switchres, or put the following in .xinitrc manually:

xrandr --newmode "416x241"  7812000 416 424 464 496 241 245 248 264 -HSync -VSync
xrandr --addmode default "416x241"
xrandr --verbose --output default --mode "416x241"
mame -verbose -resolution 416x241x32@59.66 mvsc

I get the following output in my log file (with a few extra "xrandr -q" statements to make sure things are sane):

Screen 0: minimum 640 x 480, current 640 x 480, maximum 640 x 480
default connected 640x480+0+0 0mm x 0mm
   640x480       60.00*

(pre xrandr --newmode)

Screen 0: minimum 416 x 241, current 640 x 480, maximum 640 x 480
default connected 640x480+0+0 0mm x 0mm
   640x480       60.00*
   416x241       59.66  

(new mode added successfully)

xrandr: Configure crtc 0 failed
crtc 0:      416x241  59.66 +0+0 "default"
crtc 0: disable
screen 0: revert
crtc 0: revert

Now this is the bit that's driving me nuts.  XRandR for some reason can't switch to the new mode.  MAME's verbose output confirms the mode remains in the 640x480 interlaced mode, and it has not switched over (with or without "switchres" makes no difference).

I'm using the nv_drv.so module (2.1.15), which I've hacked to allow low pclocks (default was 12, and I've dropped mine down to 6MHz).

xrandr has been giving me this issue previously before I used your hacked version too.

If I set a modeline manually in /etc/X11/xorg.conf, I can get the resolution fine (although the screen tearing is there due to the rounded vertrefresh issues above).  If I can get xrandr to switch resolutions, I'm home free.  This is the last hurdle for me before I can get this working properly.

Any advice?
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: bitbytebit on October 20, 2010, 11:10:12 pm
I have one lingering problem.  I don't think it's related to your switchres program, but something else.

I have a default 640x480@60Hz interlaced modeline in Xorg (if I have no modeline, Xorg won't start).  Running Ubuntu 10.04.

Whether I run switchres, or put the following in .xinitrc manually:

xrandr --newmode "416x241"  7812000 416 424 464 496 241 245 248 264 -HSync -VSync
xrandr --addmode default "416x241"
xrandr --verbose --output default --mode "416x241"
mame -verbose -resolution 416x241x32@59.66 mvsc

I get the following output in my log file (with a few extra "xrandr -q" statements to make sure things are sane):

Screen 0: minimum 640 x 480, current 640 x 480, maximum 640 x 480
default connected 640x480+0+0 0mm x 0mm
   640x480       60.00*

(pre xrandr --newmode)

Screen 0: minimum 416 x 241, current 640 x 480, maximum 640 x 480
default connected 640x480+0+0 0mm x 0mm
   640x480       60.00*
   416x241       59.66  

(new mode added successfully)

xrandr: Configure crtc 0 failed
crtc 0:      416x241  59.66 +0+0 "default"
crtc 0: disable
screen 0: revert
crtc 0: revert

Now this is the bit that's driving me nuts.  XRandR for some reason can't switch to the new mode.  MAME's verbose output confirms the mode remains in the 640x480 interlaced mode, and it has not switched over (with or without "switchres" makes no difference).

I'm using the nv_drv.so module (2.1.15), which I've hacked to allow low pclocks (default was 12, and I've dropped mine down to 6MHz).

xrandr has been giving me this issue previously before I used your hacked version too.

If I set a modeline manually in /etc/X11/xorg.conf, I can get the resolution fine (although the screen tearing is there due to the rounded vertrefresh issues above).  If I can get xrandr to switch resolutions, I'm home free.  This is the last hurdle for me before I can get this working properly.

And advice?

Try the newest nvidia driver, hack it for low pclocks and see if it fixes things, may also need a newer xorg-server but hopefully not because they are a pain to update all the many parts.  What version is your xorg-server?  Mine is 1.7.7, but not sure about what versions work best with xrandr.  It seems that the xrandr source indicates the change in resolution isn't being accepted and I assume that it's talking to the nvidia driver.  Possibly the xrandr support in there has improved recently, seems they have done some changes to it in the current git logs but not sure if those are really fixing this issue.
http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/ (http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/)
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: elvis on October 20, 2010, 11:34:11 pm
What version is your xorg-server?  Mine is 1.7.7

root@lowboy:~# dpkg -l xorg xserver-xorg-core
ii  xorg                      1:7.5+5ubuntu1            X.Org X Window System
ii  xserver-xorg-core         2:1.7.6-2ubuntu7.3        Xorg X server - core server

1.7.6 according to that.

The supplied version of nv_drv was 2.1.15.  I've just tried 2.1.18 (latest stable release, dated July 2010) and it gave the same error.   I tried to build from git, but it said a required tool (specifically xorg-macros) was too old.

Next stop might be dist-upgrading to Maverick (10.10) and trying again.  According to packages.ubuntu.com it uses xserver-xorg-core 1.9.0.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: bitbytebit on October 20, 2010, 11:47:59 pm
What version is your xorg-server?  Mine is 1.7.7

root@lowboy:~# dpkg -l xorg xserver-xorg-core
ii  xorg                      1:7.5+5ubuntu1            X.Org X Window System
ii  xserver-xorg-core         2:1.7.6-2ubuntu7.3        Xorg X server - core server

1.7.6 according to that.

The supplied version of nv_drv was 2.1.15.  I've just tried 2.1.18 (latest stable release, dated July 2010) and it gave the same error.   I tried to build from git, but it said a required tool (specifically xorg-macros) was too old.

Next stop might be dist-upgrading to Maverick (10.10) and trying again.  According to packages.ubuntu.com it uses xserver-xorg-core 1.9.0.
Yeah I can't see any direct xrandr support in the drivers, looks like it's talking to the xorg-server directly and it calls the drivers get_modelines function from there but the xrandr stuff is completely handled within the xorg-server I guess.  Hopefully it's just that they didn't have the xrandr working as well in that version as they did in 1.7.7, I do think possibly my version of xorg-server with the default gentoo install didn't work till I updated to the vanilla 1.7.7 one.  Looks nice, getting version 1.9.0, would be interested if that fixes it.  I really want to try the newest version but not sure when Gentoo is going to move to that high of version, and I've spent a lot of time building this box with gentoo but it's tempting seeing ubuntu is using the newest one.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: elvis on October 20, 2010, 11:55:54 pm
Upgrading to Maverick as I type.

There's also the "nouveau" drivers now too, which do support my TNT2 (and apparently work fine in 2D/"soft").  However it's using this new fangled kernel modeline stuff, so I'm not sure where to hack the minimum pclocks (or even if I can!).  But that will be my next step if Maverick doesn't play ball.

[edit]

Maverick upgrade is in.  Same issues as before with the nv_drv.so (even the latest from git).  It definitely looks like that driver can't understand XRandR requests.

nouveau certainly understands them (I can see the resize requests coming through in the log file), but the pixel clocks limits must be too high because it's throwing errors.

So, now I'm off to hack the nouveau drivers (and hopefully just the userspace stuff, and not kernel stuff too).

Maybe it's time to order an old ATI card off eBay? :)
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: Calamity on October 21, 2010, 05:12:13 am
Guessing from reading this, that you could probably trick the radeon driver in Windows to take the lrmc generated modeline of my new switchres script and use your method in Windows instead of xrandr in Linux.  This sounds quite interesting, do you think other Windows graphics drivers can be tricked this way, or have they, how exactly would I need to go about adapting switchres to do this when run in windows?  From the amazing functionality I'm having in Linux with switchres now, being able to generate modelines dynamically and get pretty good modelines and not rely on .ini files, seems this would be great now combined with your ability to push modlines into the radeon driver in Windows.  If only this could be done for even more video cards in Windows too, then we'd really have something extra interesting.  If we can make switchres work exactly the same in both Windows and Linux, that would be great, and I think at least with the radeon driver this seems very possible.

Hi bitbytebit,

I keep following this thread, it's getting really interesting, though I've just become a father this week and it's really hard to catch up  ;D

Now that you bring that post back about the 'loader' thing I had in mind, I see that it's exactly what you have succeeded to implement for Linux, it's fantastic. Think of the endless possibilities of using dynamic modelines, for instance you can write a new 'advv' clone to allow you to find your monitor ranges, centering/tweaking modes, and use the results as feed back for lrmc so it can create even better modelines for your hardware. This is why I made this Arcade_OSD program, to test this functionality, though it will only work with my hacked Catalyst (CRT_Emudriver). I understand you've used a video mode DB to get rid of inis, good.

The same scheme would work for Windows, that's sure, but it's complicated to make a general method for all cards, as I'll explain. Windows video drivers just parse the registry for custom modelines at startup. That's why you need to restart the system all the time to test changes... annoying. If only we could reset the driver by unloading and reloading it so it went through it's initialization routines again and read the registry keys after we modify them, there would be a chance to get it. Accidentaly, there is a documented way of doing this! Here is it:

http://msdn.microsoft.com/en-us/library/ff568527%28VS.85%29.aspx (http://msdn.microsoft.com/en-us/library/ff568527%28VS.85%29.aspx)

Basically, it works by setting 640x480x16 colors (4 bits) and inmediately restoring the original mode. This is because 640x480x16 is usually implemented by Windows default video driver, thus by calling it the specific video driver is unloaded from memory. To get it working for me, after that, I need to request Windows for available video modes. It's stable, works really well and is reasonably fast. Unfortunately, I only got it working with my hacked Catalyst 6.5, and (very strange) just when the amount of defined modelines is big enough (I still have to find the reason for this). No luck with Catalyst 8.x in my office computer, nor with ForceWare in my laptop, but I haven't tested it so much. I believe, as the article says, it's because these drivers have native support for 640x480x16 colors, so they never get unloaded :( However, it's a matter of testing and investigating it, I unfortunately have so little time to do this, I hope someone will use this stuff to do it.

There's a limitation to this method: you can modify existing modes, but not create new ones on the fly (you need restart). The reason, I believe, is that Windows internally only requests the driver for available video modes during startup sequence, so it won't modify it's internal mode table until we restart. But this limitation can be easily overcome by preparing a general mode table of needed resolutions (no vfreq defined) and tweaking the chosen modeline before calling the emulator, following the loader-wrapper scheme.

At this point, I'd really would consider to have a look at lrmc method for calculating modelines. It's funny because I wrote VMMaker from scratch figuring out all calculations and for me, lrmc is still a black box, if only I had more time to study it. I'm convinced the way I use in VMMaker is better. However, this is a secondary matter.

Definitely, your D9800 is a fantastic monitor, it's incredible it has a continuous range. But it's hard for me to imagine how this works from the hardware part. At the end of the day the intervals must exist, because porchs and sync pulses need to be smaller as hfreq increases, and there should be jumps somewhere (maybe that's why you experiment centering shifts at some points). It seems to work as an automatic car, you just have to put your foot on the accelarator, but the car does change gears inside.

I'm also concerned about the vsync stuff in Linux. Now that I've tested SDLMame for Windows, which I believe is the same code for Linux, I think that you should be able to turn throttle off as I do, and if it gets full speed is because vsync is not really working. This also happened to me if I used 'video software' instead of opengl. Think that vsync is a must, because even if you can get really accurate vfreqs (you'll normally be 2 cents of Hz above or below in the best cases), if throttle is on, Mame will keep its internal clock on, and it will produce regular hiccups in scrolls. We don't want Mame to do that, we want it to hang off our vfreq to be as smooth as possible.

There's a lot I should check, fist of all I'm not sure what version of SDL I have, or if SDLMame is using SDL in any way, what's the role of opengl in all this, so I need to clarify some concepts for me. Also, how to run perl scripts in Windows, etc.
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 21, 2010, 10:18:54 am
Guessing from reading this, that you could probably trick the radeon driver in Windows to take the lrmc generated modeline of my new switchres script and use your method in Windows instead of xrandr in Linux.  This sounds quite interesting, do you think other Windows graphics drivers can be tricked this way, or have they, how exactly would I need to go about adapting switchres to do this when run in windows?  From the amazing functionality I'm having in Linux with switchres now, being able to generate modelines dynamically and get pretty good modelines and not rely on .ini files, seems this would be great now combined with your ability to push modlines into the radeon driver in Windows.  If only this could be done for even more video cards in Windows too, then we'd really have something extra interesting.  If we can make switchres work exactly the same in both Windows and Linux, that would be great, and I think at least with the radeon driver this seems very possible.

Hi bitbytebit,

I keep following this thread, it's getting really interesting, though I've just become a father this week and it's really hard to catch up  ;D

Now that you bring that post back about the 'loader' thing I had in mind, I see that it's exactly what you have succeeded to implement for Linux, it's fantastic. Think of the endless possibilities of using dynamic modelines, for instance you can write a new 'advv' clone to allow you to find your monitor ranges, centering/tweaking modes, and use the results as feed back for lrmc so it can create even better modelines for your hardware. This is why I made this Arcade_OSD program, to test this functionality, though it will only work with my hacked Catalyst (CRT_Emudriver). I understand you've used a video mode DB to get rid of inis, good.

The same scheme would work for Windows, that's sure, but it's complicated to make a general method for all cards, as I'll explain. Windows video drivers just parse the registry for custom modelines at startup. That's why you need to restart the system all the time to test changes... annoying. If only we could reset the driver by unloading and reloading it so it went through it's initialization routines again and read the registry keys after we modify them, there would be a chance to get it. Accidentaly, there is a documented way of doing this! Here is it:

http://msdn.microsoft.com/en-us/library/ff568527%28VS.85%29.aspx (http://msdn.microsoft.com/en-us/library/ff568527%28VS.85%29.aspx)

Basically, it works by setting 640x480x16 colors (4 bits) and inmediately restoring the original mode. This is because 640x480x16 is usually implemented by Windows default video driver, thus by calling it the specific video driver is unloaded from memory. To get it working for me, after that, I need to request Windows for available video modes. It's stable, works really well and is reasonably fast. Unfortunately, I only got it working with my hacked Catalyst 6.5, and (very strange) just when the amount of defined modelines is big enough (I still have to find the reason for this). No luck with Catalyst 8.x in my office computer, nor with ForceWare in my laptop, but I haven't tested it so much. I believe, as the article says, it's because these drivers have native support for 640x480x16 colors, so they never get unloaded :( However, it's a matter of testing and investigating it, I unfortunately have so little time to do this, I hope someone will use this stuff to do it.

There's a limitation to this method: you can modify existing modes, but not create new ones on the fly (you need restart). The reason, I believe, is that Windows internally only requests the driver for available video modes during startup sequence, so it won't modify it's internal mode table until we restart. But this limitation can be easily overcome by preparing a general mode table of needed resolutions (no vfreq defined) and tweaking the chosen modeline before calling the emulator, following the loader-wrapper scheme.

At this point, I'd really would consider to have a look at lrmc method for calculating modelines. It's funny because I wrote VMMaker from scratch figuring out all calculations and for me, lrmc is still a black box, if only I had more time to study it. I'm convinced the way I use in VMMaker is better. However, this is a secondary matter.

Definitely, your D9800 is a fantastic monitor, it's incredible it has a continuous range. But it's hard for me to imagine how this works from the hardware part. At the end of the day the intervals must exist, because porchs and sync pulses need to be smaller as hfreq increases, and there should be jumps somewhere (maybe that's why you experiment centering shifts at some points). It seems to work as an automatic car, you just have to put your foot on the accelarator, but the car does change gears inside.

I'm also concerned about the vsync stuff in Linux. Now that I've tested SDLMame for Windows, which I believe is the same code for Linux, I think that you should be able to turn throttle off as I do, and if it gets full speed is because vsync is not really working. This also happened to me if I used 'video software' instead of opengl. Think that vsync is a must, because even if you can get really accurate vfreqs (you'll normally be 2 cents of Hz above or below in the best cases), if throttle is on, Mame will keep its internal clock on, and it will produce regular hiccups in scrolls. We don't want Mame to do that, we want it to hang off our vfreq to be as smooth as possible.

There's a lot I should check, fist of all I'm not sure what version of SDL I have, or if SDLMame is using SDL in any way, what's the role of opengl in all this, so I need to clarify some concepts for me. Also, how to run perl scripts in Windows, etc.


Congratulations on becoming a father :). 

Yeah it's nice now without using ini's, not really a video DB but actually just quickly doing a mame -listdev game and grabbing the display section.  I've been able to start testing multiple monitor types much easier just changing the command line to cga or ega, so has been interesting to compare each ones limitations and what happens when it's more restricted.  That windows stuff sounds promising, glad there is a possible way to somewhat do it there.  I suspect your methods are probably better than lrmc, I can see what your saying about the gear changing as you climb the Horz Freq up higher.  I think there needs to be some sort of dynamic altering of the porches as it gets higher values instead of what it does now with multiple static display sets with values for each.  I've been finding basically as it moves higher in Freq the divisor it is using has to be larger for each of the porches.  I'm still learning how that works, but from what I can tell if it dynamically generated the display values for a d9800 depending on what you asked it in screen size and refresh rates then it could very likely always center the screen.  I actually have it pretty much doing this for most games with my current set which has chunks through like 15.250-17.499, 17.500-20.000,20.001-23.899,23.900-25.500,27-30.99,31-32,32.001-40   that has some places in there which need some perfecting but it's more for really odd games and most really are centered and full without boarders with the right refresh rate.  So if that was able to be adjusted dynamically without all those preset areas possibly then the oddball games would work better.  I've been running into one issue with a few games that are widescreen it seems like the DBZ game which seems to be a 1.5 aspect ratio and I have some odd recalculating of the framesize which kind of makes it work but haven't been satisfied with any method to automatically calculate any games that go above the 1.3333333 normal monitor aspect ratio. 

I found something odd about the waitvsync setting though, I'm starting to think it's my video card can't handle it properly or the X drivers for my video card/opengl implementation.  I got the vsync working on another computer using an nvidia quadro fx 3400, my arcade system uses the newer arcadeVGA3000 which is just a radeon 2600HD I guess and has the RV630 on it.  When I start mame on the radeon it always says OpenGL: FBO not supported and also about IRQ's not enabled falling back to busy waits: 2 0.  I am guessing this is the problem, that the card isn't able to do interrupts with opengl so it can't do vsync stuff through opengl correctly.  I'm thinking of using an nvidia quadro, testing if it can do the low pixclocks which I'm guessing it can?  It's sad if that's really true about the arcadeVGA actually not supporting waitforvsync in Linux, when it's supposed to be specifically for arcade systems, and yet this older nvidia card can do it just fine.  Although that's also with the proprietary nvidia drivers so I'm not sure if it's the same for the open ones which I'd have to use for the lower dotclock stuff.  Am now planning on possibly testing these nvidia cards and seeing if they are at all better than the radeon, although it just doesn't seem to make sense that they would be but if the vsync to refresh rates works on them in Linux and dotclocks can go low then I guess they pretty much are more suited for this.

In windows just getting active perl, it installs from the http://www.activestate.com/activeperl (http://www.activestate.com/activeperl) website pretty easy and then you can run perl scripts in windows just like any other program there.
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: Calamity on October 21, 2010, 12:10:16 pm
I found something odd about the waitvsync setting though, I'm starting to think it's my video card can't handle it properly or the X drivers for my video card/opengl implementation.  I got the vsync working on another computer using an nvidia quadro fx 3400, my arcade system uses the newer arcadeVGA3000 which is just a radeon 2600HD I guess and has the RV630 on it. 

I'm afraid the problem is with the Radeon driver not implementing waitvsync properly, as the folks in the Spanish forum thought, as with nVidia they were able to make waitvsync work without problem.

Regarding porches and sync pulses, I am positive they keep constant through the range covered by my monitor: 15.625 - 16.670 KHz, so in order to keep my modes centered I have to use the same values all the time. This stuff is related to the speed of the electron beam, which is constant in my monitor regardless of hfreq. There's a visible effect due to this: when you increase hfreq, the picture becomes narrower in width, as the extra lines, being the beam speed constant, need to come from somewhere: the sides of the picture! Your monitor must have more complex electronics, to be able to program the electrom beam at different speeds according to some previously defined hfreq intervals (you would notice the explained narrowing effect somewhere), or... have a really progresive beam speed, which would allow to interpolate the porch values for the whole range.
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 21, 2010, 12:29:33 pm
I found something odd about the waitvsync setting though, I'm starting to think it's my video card can't handle it properly or the X drivers for my video card/opengl implementation.  I got the vsync working on another computer using an nvidia quadro fx 3400, my arcade system uses the newer arcadeVGA3000 which is just a radeon 2600HD I guess and has the RV630 on it. 

I'm afraid the problem is with the Radeon driver not implementing waitvsync properly, as the folks in the Spanish forum thought, as with nVidia they were able to make waitvsync work without problem.

Regarding porches and sync pulses, I am positive they keep constant through the range covered by my monitor: 15.625 - 16.670 KHz, so in order to keep my modes centered I have to use the same values all the time. This stuff is related to the speed of the electron beam, which is constant in my monitor regardless of hfreq. There's a visible effect due to this: when you increase hfreq, the picture becomes narrower in width, as the extra lines, being the beam speed constant, need to come from somewhere: the sides of the picture! Your monitor must have more complex electronics, to be able to program the electrom beam at different speeds according to some previously defined hfreq intervals (you would notice the explained narrowing effect somewhere), or... have a really progresive beam speed, which would allow to interpolate the porch values for the whole range.


Interesting, good to know and now I guess I'm going to try my nvidia cards, sounds like I need that for vsync and sounds great to finally get it working right with all these resolutions having the right refresh rate. 

I'm currently realizing I can now do all the odd calculations that lrmc was doing, like the vertical game resizing or dual screen adjustment, inside switchres now.  That is going to make it a lot simpler doing all the pre-work inside the perl script and just let lrmc take a resolution and refresh rate and expect it to not do any fiddling with it other than perfecting the modeline.  This makes it much easier to have dual monitor support, which switchres should basically have now with some changes I just made, and testing.  I had thought of the advv utility ability actually before, and have it right now just bringing up xvidtune in -testmode, but we need a better program than xvidtune I think.  Seems that xvidtune is under the same spell the X drivers have gotten into where it doesn't listen to custom modelines very easily, or maybe it's just ignoring the xrandr modelines possibly.  At any rate it basically will only come up with the modeline in the config xorg.conf and even then won't allow altering it claiming it is out of range unless it's a VESA compliant modline. 

I am really interested in this aspect ratio issue though, because from what I can tell it's calculated different by everybody, some using 1.22222 some 1.333333 and lrmc was doing some odd division of the width by .56 on vertical games.  Some games you have to leave alone, some need some tweaking (like dbz or virtua racer, mortal kombat).  Seems it may be a range of vertical resolutions that have either larger than 1.3 or smaller aspect ratios, but never below 1.25.  I'm not sure if it's something I'm doing, but from what I can tell I can get dbz at the exact original resolution and refresh but it's off the sides and I have to do some odd calculations to make it be in a letter box type screen and it fits then.  Same with Virtua Racer but opposite, It's a smaller than 1.3, like 1.28 aspect ratio and It needs a slight different screen size I have to calculate weirdly.  I have found algorithms that seem to work with these games mostly consistent but trying to see the deeper logic in it and if it really translates to all games and/or what ranges.  So far if the vertical size is above 224 and below 400 and the aspect is above 1.3 I do one thing, while if below 1.3 but above 1.25 I do another.  Seems to mostly work, and possibly only other unique thing is that maybe the ones above 1.3 only qualify for my change if they are below 56 Hz vertical refresh rates.  So that's something I've been trying to wrap my brain around the last day or so,  seems like it's a pixel aspect ratio vs. screen aspect ratio thing and not sure if lrmc might be a culprit and I'm fighting it or this information isn't in mame for the games and makes it hard to get exact display output that matches all parameters and fits perfect/refreshes perfectly.  This of course isn't practical for normal arcade monitors to do all the games that way, but for the d9800 this seems to be an issue because you can actually match most and so it starts to get somewhat tricky because unlike the AVGA card or in Windows you don't just have a set of 30 modelines and know the games are going to have boarders sometimes and so leave extra which seems to make up for these odd aspect ratio games.
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: Calamity on October 21, 2010, 01:13:00 pm
You may have already checked this, but just in case:

http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=46353&page=1 (http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=46353&page=1)

I'm currently realizing I can now do all the odd calculations that lrmc was doing, like the vertical game resizing or dual screen adjustment, inside switchres now.  That is going to make it a lot simpler doing all the pre-work inside the perl script and just let lrmc take a resolution and refresh rate and expect it to not do any fiddling with it other than perfecting the modeline.

Definitely YES, I recommend you to keep all the mode adaptation stuff in your script, and just pass lrmc a plain modeline to calculate it - as your project progresses, you might get rid of lrmc at all ;)

I am really interested in this aspect ratio issue though, because from what I can tell it's calculated different by everybody, some using 1.22222 some 1.333333 and lrmc was doing some odd division of the width by .56 on vertical games.  Some games you have to leave alone, some need some tweaking (like dbz or virtua racer, mortal kombat).  Seems it may be a range of vertical resolutions that have either larger than 1.3 or smaller aspect ratios, but never below 1.25.  I'm not sure if it's something I'm doing, but from what I can tell I can get dbz at the exact original resolution and refresh but it's off the sides and I have to do some odd calculations to make it be in a letter box type screen and it fits then.  Same with Virtua Racer but opposite, It's a smaller than 1.3, like 1.28 aspect ratio and It needs a slight different screen size I have to calculate weirdly.  I have found algorithms that seem to work with these games mostly consistent but trying to see the deeper logic in it and if it really translates to all games and/or what ranges.  So far if the vertical size is above 224 and below 400 and the aspect is above 1.3 I do one thing, while if below 1.3 but above 1.25 I do another.  Seems to mostly work, and possibly only other unique thing is that maybe the ones above 1.3 only qualify for my change if they are below 56 Hz vertical refresh rates.  So that's something I've been trying to wrap my brain around the last day or so,  seems like it's a pixel aspect ratio vs. screen aspect ratio thing and not sure if lrmc might be a culprit and I'm fighting it or this information isn't in mame for the games and makes it hard to get exact display output that matches all parameters and fits perfect/refreshes perfectly.  This of course isn't practical for normal arcade monitors to do all the games that way, but for the d9800 this seems to be an issue because you can actually match most and so it starts to get somewhat tricky because unlike the AVGA card or in Windows you don't just have a set of 30 modelines and know the games are going to have boarders sometimes and so leave extra which seems to make up for these odd aspect ratio games.

I am not sure if I follow you here, but... I wouldn't care about pixel aspect at all. Think that arcade games picture was stretched using monitor potenciometers to cover the 4:3 full screen, regardless they had 192, 224, 240, 256 or whatever vertical resolution, so speaking of pixel aspect there doesn't make sense, unless you intend to add artificial side bordes to keep the picture 4:3 without adjusting monitor controls (something I would understand if you use a TV with no service mode, but not with an arcade monitor). So if DBZ asks you for 416x224, just make that exact resolution, then adjust your monitor's v-amp to cover the screen, it works for me this way. For vertical games it's a different story.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: Gray_Area on October 21, 2010, 01:42:23 pm
AdvanceMAME did dynamic modeline generation at game start-up, and was initially Linux-based. Maybe you want to look at the source?

http://advancemame.sourceforge.net/ (http://advancemame.sourceforge.net/)
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: bitbytebit on October 21, 2010, 01:51:51 pm
AdvanceMAME did dynamic modeline generation at game start-up, and was initially Linux-based. Maybe you want to look at the source?

http://advancemame.sourceforge.net/ (http://advancemame.sourceforge.net/)

Thanks for reminding me, I actually have wanted to do that and tried awhile back but now should take another look.  I have learned a lot more since I last tried and suspect I can spot the stuff I need much easier now.  Definitely seems like what this is turning into is a wrapper for the normal mame/mess or other emulators that can give them the ability that advancemame has/had when it was up to date.  Hopefully can be a little less dependent on hardware, but I am starting to see how that is really a brick wall with certain cards with either the physical chips or the knowledge of how to get the chips to do what we need. 
Title: Re: lrmc patched to use modern mame.xml files, generate ini files and modelines
Post by: bitbytebit on October 21, 2010, 02:13:55 pm
You may have already checked this, but just in case:

http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=46353&page=1 (http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=46353&page=1)

I'm currently realizing I can now do all the odd calculations that lrmc was doing, like the vertical game resizing or dual screen adjustment, inside switchres now.  That is going to make it a lot simpler doing all the pre-work inside the perl script and just let lrmc take a resolution and refresh rate and expect it to not do any fiddling with it other than perfecting the modeline.

Definitely YES, I recommend you to keep all the mode adaptation stuff in your script, and just pass lrmc a plain modeline to calculate it - as your project progresses, you might get rid of lrmc at all ;)

I am really interested in this aspect ratio issue though, because from what I can tell it's calculated different by everybody, some using 1.22222 some 1.333333 and lrmc was doing some odd division of the width by .56 on vertical games.  Some games you have to leave alone, some need some tweaking (like dbz or virtua racer, mortal kombat).  Seems it may be a range of vertical resolutions that have either larger than 1.3 or smaller aspect ratios, but never below 1.25.  I'm not sure if it's something I'm doing, but from what I can tell I can get dbz at the exact original resolution and refresh but it's off the sides and I have to do some odd calculations to make it be in a letter box type screen and it fits then.  Same with Virtua Racer but opposite, It's a smaller than 1.3, like 1.28 aspect ratio and It needs a slight different screen size I have to calculate weirdly.  I have found algorithms that seem to work with these games mostly consistent but trying to see the deeper logic in it and if it really translates to all games and/or what ranges.  So far if the vertical size is above 224 and below 400 and the aspect is above 1.3 I do one thing, while if below 1.3 but above 1.25 I do another.  Seems to mostly work, and possibly only other unique thing is that maybe the ones above 1.3 only qualify for my change if they are below 56 Hz vertical refresh rates.  So that's something I've been trying to wrap my brain around the last day or so,  seems like it's a pixel aspect ratio vs. screen aspect ratio thing and not sure if lrmc might be a culprit and I'm fighting it or this information isn't in mame for the games and makes it hard to get exact display output that matches all parameters and fits perfect/refreshes perfectly.  This of course isn't practical for normal arcade monitors to do all the games that way, but for the d9800 this seems to be an issue because you can actually match most and so it starts to get somewhat tricky because unlike the AVGA card or in Windows you don't just have a set of 30 modelines and know the games are going to have boarders sometimes and so leave extra which seems to make up for these odd aspect ratio games.

I am not sure if I follow you here, but... I wouldn't care about pixel aspect at all. Think that arcade games picture was stretched using monitor potenciometers to cover the 4:3 full screen, regardless they had 192, 224, 240, 256 or whatever vertical resolution, so speaking of pixel aspect there doesn't make sense, unless you intend to add artificial side bordes to keep the picture 4:3 without adjusting monitor controls (something I would understand if you use a TV with no service mode, but not with an arcade monitor). So if DBZ asks you for 416x224, just make that exact resolution, then adjust your monitor's v-amp to cover the screen, it works for me this way. For vertical games it's a different story.


Yeah that is a thought I had too, it's definitely going to be possible eventually to either avoid lrmc, and we could also support any modeline generator too.  I like the idea of trying to get the modeline generation put into perl code so it's easy to modify and more people could alter it easier.  

Yeah I'd seen that thread about the radeon directfb support, odd thing is that it seems this ArcadeVGA 3 radeon isn't compatible with the linux kernels radeonfb framebuffer because the RV630 isn't supported I guess.  It doesn't allow the KMS stuff in newers kernels either, because it doesn't know the atom bios signature.  I assume it's because it's modified, it isn't really the same as those other radeon cards to the linux code.  

This pixel aspect thing is also odd because the way I figured out the formula I'm using for virtua racer was to look at what the -verbose output of mame for the GL shader was saying about the pitch values I guess.  It came up with 520x400 I think or something instead of the 496x384 it is said to be normally.  So I came up with that value through doing some calculating and seeing it was the difference of the 1.3 aspect ratio from the 1.29 reported times the height, and then the game aspect ratio of 1.29 times that new height.  Somehow that calculates it out and I think it works on other games, for dbz I can do a similar calculation and it works for the mortal kombat too and possibly others.  I'm still testing, figuring, but here's the basic formula which for some reason seems to mostly work... (Game aspect vs. monitor aspect as 1.3333333)
Code: [Select]
               } elsif ($GASPECT > $MASPECT) {
                        my $ADIFF = $GASPECT - $MASPECT;
                        $o_width = $o_width + ($o_height / 3);
                        $o_height = $o_width / $MASPECT;
                        $o_width = sprintf("%.0f", $o_width);
                        $o_height = sprintf("%.0f", $o_height);
                } elsif ($GASPECT >= 1.25 && $GASPECT < $MASPECT) {
                        my $ADIFF = $MASPECT - $GASPECT;
                        $o_height = $o_height + ($ADIFF * $o_height);
                        $o_width = $GASPECT * $o_height;
                        $o_width = sprintf("%.0f", $o_width);
                        $o_height = sprintf("%.0f", $o_height);
                }


I really hope it's something else, since it does seem odd to have to deal with the aspect ratio at all, but so far seems like this really is necessary for some reason with the modelines.  Actually I'm surprised that it seems to be working somewhat for the most part, and making these games look good now, I didn't think it'd actually be able to universally work but so far it might just be doing that with the code above.  I don't totally understand why dividing by 3 for that one calculation works, but that was the way to get the right value and it seems to be working also on other games too.  I think it might be something about the 4/3 ratio, but I just saw that it seemed to make the height/width come out to display the game without side boarders and not stretched at all vertically.  I also have keepaspect at 0 and unevenstretch at 0 too, which of course with those the screen will fit any resolution but alter things, another odd thing I've seen with the arcadeVGA sight instructions where they tell you to turn those on but I can't see how that would be a good idea unless the game is just too big and you have to fit it into a smaller resolution.

Edit:

Yeah I now see issues with doing this, hmmm, seems like it may be a side effect of lrmc possibly causing the issue with some games that I am trying to fix through this.  Will have to look at what it's doing and see.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: Calamity on October 21, 2010, 04:17:49 pm
The right settings as you say are: unevenstretch 0, keepaspect 0, unless you are stretching, which it's not going to be necessary with your monitor as it accepts any resolution. Streching is only interesting in addition to interlace, i.e. to show vertical games with more than 288 lines on a horizontal lowres monitor. Stretching helps reducing the flicker introduced by interlace, at the cost of ruining sharpness.

I've seen the problem with DBZ, it also happens with Golden Axe: Revenge of Death Adder (SEGA too). I have seen this before, the problem is that Mame reports a wrong resolution, active xres is not 416 but maybe around 320 or so. Then you get big side borders. I've also seen the opposite problem, Mame reports xres = 256 where it should be 320, i.e. Thunderforce AC or Bonanza Bros. so you get a chopped picture. It would good to have a list of resolution patches for these games to check before creating video modes.

Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: bitbytebit on October 22, 2010, 04:57:57 am
Upgrading to Maverick as I type.

There's also the "nouveau" drivers now too, which do support my TNT2 (and apparently work fine in 2D/"soft").  However it's using this new fangled kernel modeline stuff, so I'm not sure where to hack the minimum pclocks (or even if I can!).  But that will be my next step if Maverick doesn't play ball.

[edit]

Maverick upgrade is in.  Same issues as before with the nv_drv.so (even the latest from git).  It definitely looks like that driver can't understand XRandR requests.

nouveau certainly understands them (I can see the resize requests coming through in the log file), but the pixel clocks limits must be too high because it's throwing errors.

So, now I'm off to hack the nouveau drivers (and hopefully just the userspace stuff, and not kernel stuff too).

Maybe it's time to order an old ATI card off eBay? :)
I tried the nv driver with an nvidia card I have, and confirmed what your seeing.  It doesn't support Xrandr at all for mode switching, mine didn't even allow the custom modes because of the vertical refresh rate being out of bounds (which it isn't).  So from what I can tell that driver is just not able to do this, it does do vsync though with openGL but unfortunately we can't call it to switch modes we choose.

Now the trick it seems is to install that http://nouveau.freedesktop.org/wiki/InstallDRM#Installationnotes (http://nouveau.freedesktop.org/wiki/InstallDRM#Installationnotes) nouveau driver and all the additional stuff with it, like reinstall drm, mesa sdl and recompile mame too.  It needs some changes, but not the driver itself which is not where the pixelclock limitations come from but instead the drm part of the driver in the kernel.  I had to make changes so it chose a frame buffer console I could use, I had to do a lot of stuff and it wasn't simple unfortunately but it may just work.  I've at least got modeswitching working so equal to the radeon card, I'm seeing if I can get the vsync stuff working for it too.  It looks promising and is already a better driver than the nv one, but I'm not sure how stable it is when really fully using OpenGL yet.  

Here's the patch I had to make to the kernel directory for it...
Code: [Select]
diff -ru master/drivers/gpu/drm/drm_crtc_helper.c nouveau/drivers/gpu/drm/drm_crtc_helper.c
--- master/drivers/gpu/drm/drm_crtc_helper.c    2010-10-21 00:12:37.000000000 -0500
+++ nouveau/drivers/gpu/drm/drm_crtc_helper.c   2010-10-22 02:20:57.000000000 -0500
@@ -116,7 +116,7 @@

        count = (*connector_funcs->get_modes)(connector);
        if (count == 0 && connector->status == connector_status_connected)
-               count = drm_add_modes_noedid(connector, 1024, 768);
+               count = drm_add_modes_noedid(connector, 640, 480);
        if (count == 0)
                goto prune;

diff -ru master/drivers/gpu/drm/nouveau/nouveau_connector.c nouveau/drivers/gpu/drm/nouveau/nouveau_connector.c
--- master/drivers/gpu/drm/nouveau/nouveau_connector.c  2010-10-21 00:12:37.000000000 -0500
+++ nouveau/drivers/gpu/drm/nouveau/nouveau_connector.c 2010-10-22 02:40:41.000000000 -0500
@@ -666,7 +666,7 @@
        struct nouveau_connector *nv_connector = nouveau_connector(connector);
        struct nouveau_encoder *nv_encoder = nv_connector->detected_encoder;
        struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
-       unsigned min_clock = 25000, max_clock = min_clock;
+       unsigned min_clock = 3000, max_clock = min_clock;
        unsigned clock = mode->clock;

        switch (nv_encoder->dcb->type) {

That allowed the frame buffer to come up and show up on my monitor, but I'm not sure if it may need more hacking to add a modeline in the default modes when no EDID is detected for an Arcade monitor that isn't  a WG d9800 that can do VGA.  It complains about no EDID, I had to compile opengl and opendrm with support for it, and had to remove the dri module for it that opengl created because it caused a kernel oops.  But without that module, it looks better than the nv driver, and I'm recompiling mame now to see if it can do vsync.  For some reason, figure it's the newer opengl I just updated to from git with support for this card, mame now segfaults so I'll know in a bit if it just needs recompiled or it's a bigger issue.  I think something about the opengl support with the gallium support is not allowing things to use opengl.  So if that new Ubuntu supports this then by all means give it a try because maybe they have a working stable build of this.  Let me know how that goes, and if it can also do the vsync support, which is the main issue with the radeon cards which don't seem to support vsync.  If they do, it'd be with these newer kernels and the KMS support for the DRM driver.  Definitely a pain that it seems each driver and card combination has caveats and haven't found the perfect combo it seems since each one is missing a part, either vsync with no mode switching or mode switching without vsync support.

Thanks,
Chris

Edit:  Yeah it seems it can't do vsync like the nv driver can, but it does do modeswitching at least and works fine if you avoid the gallium support in opengl, that seems to be what causes the oops for me.  I'm hoping that when that works, then it'll do vsync with openGL.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: Calamity on October 22, 2010, 05:58:52 am
AdvanceMAME did dynamic modeline generation at game start-up, and was initially Linux-based. Maybe you want to look at the source?

http://advancemame.sourceforge.net/ (http://advancemame.sourceforge.net/)

Thanks for reminding me, I actually have wanted to do that and tried awhile back but now should take another look.  I have learned a lot more since I last tried and suspect I can spot the stuff I need much easier now.  Definitely seems like what this is turning into is a wrapper for the normal mame/mess or other emulators that can give them the ability that advancemame has/had when it was up to date.  Hopefully can be a little less dependent on hardware, but I am starting to see how that is really a brick wall with certain cards with either the physical chips or the knowledge of how to get the chips to do what we need. 

AdvanceMame, at least Windows version, performs direct video hardware access, by installing it's own video driver stuff that is able to work on the hardware layer. It's the same that Powerstrip does. The problem with this approach is that it's very difficult to mantain, as newer versions of Mame and video hardware keep coming. The wrapper solution is much more elegant, provided we had drivers that worked as intended.

It's a shame that these drivers haven't implemented the basic vsync stuff. From the hardware point of view, it's one of the easiest things one can do, I believe any chip must support this:

Code: [Select]
mov dx, 03DAh
@@:
in al,dx
test al,8
jnz @B
@@:
in al,dx
test al,8
jz @B
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .11)
Post by: bitbytebit on October 22, 2010, 07:19:34 pm
Version 0.12
* Should work better with nvidia cards, if you use the nouveau version because the xf86-nv driver does not work with xrandr mode switching.
* lots of improvements in the way that switchres chooses the resolution, lrmc improved in being more separate and generic as a modeline generator
   for arcade monitors.
* make sure to read the README and README_xrandr files for more details, they have changed quite  a bit.



Goals and focus right now are on finding what is stopping vsync from working in the nvidia nouveau and radeon ati drivers.  If these two drivers did vsync properly they would fully do resolution mode switching and refresh rate accuracy with vsync capability.  I think the radeon driver will do it as long as you enable KMS in the drm module in the kernel.  This is an issue for the AVGA cards though because the ATOM bios in them is altered and it seems to make the drm module barf when choosing kms to be enabled.  I have filed a bug report about this to the drm people, hopefully they know what is going on, I have dumped the BIOS from the AVGA 3000 card for them and have a kernel null pointer oops debug log. 

The nvidia drivers for the nouveau are interesting, but a bit unstable unless you disable the newer GL stuff so then they don't do vsync yet they do modeswitching with xrandr so you get the same as if you used the radeon ati drivers.  I have patches included now for the nvidia drm kernel module, which allow lower pixclocks and set the default resolution it chooses to 640x480 although it's VGA VESA and may still be bad for arcade monitors.  There's not a real good ability right now in that driver to choose the default bootup mode and it says it in the source that is something they need to work on.  One could go in there and hardcode a modeline for their card and force it as the default, but it'd depend on your card.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: bitbytebit on October 25, 2010, 05:24:06 am
I've been working on gettnig switchres working decent in Windows, at least able to generate a modeline and launch mame with that resolution on the command line.  So you can avoid using .ini files in theory in Windows too, just need to get the modelines put into the driver like using the usermodes for Soft15Khz.  There's a new lrmc.exe binary too so it can be used under Windows now to generate modelines and read the mame.xml file to do that or just custom ones on the command line.  New switchres.conf config file allows you to set your settings and not have to call them on the command line, or put them into the frontend calling switchres when you want to change the command line.

No luck on waitforvsync support in X Windows, but do see they are possibly working on it right now in development of the linux kernel drm stuff for the r500-r700 chipsets for ATI radeon cards. 

I am eventually going to get the xrandr support in switchres to be able to do all the setup for dual monitors, maybe it'll work now but I've currently got it turning off all extra monitors since otherwise things get weird or it won't switch resolutions unless you have 2 arcade monitors.  Hopefully can get that working eventually so it's all done automatically and uses dual monitors either as one being the game and other being the extra screen or if not a dual game then possibly show the marquee art or something.

Version 0.13
* can run switchres on Windows, prints out lrmc generated modeline and runs with that on the command line for resolution (so shouldn't need .ini files anymore in Windows for Soft15Khz).  This is a start at Windows support and
   still needs to have a better method of putting the modelines into the driver.  Right now you can generate modelines this way or with lrmc itself for Soft15Khz usermodes setup. 
* Have a version of lrmc for Windows in binary form, should be able to generate modelines now in Windows either from the mame.xml or for any chosen resolution on the command line. 
* Can use a config file with switchres now, switchres.conf, and it can be either in /etc/switchres.conf or ~/switchres.conf or ~/.config/switchres.conf (on Linux), in Windows it's in C:\\etc\switchres.conf
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: Calamity on October 25, 2010, 08:02:10 am
Hi bitbytebit,

I've been testing your lrmc for Windows, I'd like to paste the results I'm getting to make sure we both get the same. I've done two tests, one with -D9800 (no lrmc.conf), and another with lrmc.conf set for Hantarex MTC9110. Using mame.xml v0.131. I'm only copying the first modelines to keep the message short. Here they are:

lrmc mame.xml -D9800

Code: [Select]

        # 256x224x60.00 @ 29.400kHz
        Modeline "256x448x60.00"  9.172800  256 264 304 312  448 457 461 490  -HSync -VSync

        # 640x480x60.00 @ 31.500kHz
        Modeline "640x480x60.00"  25.200000  640 656 752 800  480 490 494 525  -HSync -VSync

        # 224x256x60.00 @ 16.620kHz
        Modeline "688x256x60.00"  13.694880  688 704 776 824  256 260 263 277  -HSync -VSync

        # 320x240x60.00 @ 15.600kHz
        Modeline "640x240x60.00"  11.980800  640 656 720 768  240 244 247 260  -HSync -VSync

        # 320x224x60.00 @ 29.400kHz
        Modeline "320x448x60.00"  11.524800  320 328 376 392  448 457 461 490  -HSync -VSync

        # 320x224x59.19 @ 29.001kHz
        Modeline "320x448x59.19"  11.368372  320 328 376 392  448 457 461 490  -HSync -VSync

        # 384x224x59.63 @ 29.218kHz
        Modeline "384x448x59.63"  13.791089  384 392 448 472  448 457 461 490  -HSync -VSync

        # 512x288x60.00 @ 18.720kHz
        Modeline "512x288x60.00"  11.681280  512 520 568 624  288 293 296 312  -HSync -VSync

        # 256x240x60.00 @ 15.600kHz
        Modeline "512x240x60.00"  9.609600  512 528 576 616  240 244 247 260  -HSync -VSync

        # 336x240x59.92 @ 15.580kHz
        Modeline "672x240x59.92"  12.588570  672 688 752 808  240 244 247 260  -HSync -VSync

    # 1024x697x55.01 @ 39.716kHz
    Modeline "1024x697x55.01"  52.107801  1024 1064 1168 1312  697 700 704 722  +HSync +VSync

        # 384x224x59.61 @ 29.209kHz
        Modeline "384x448x59.61"  13.786601  384 392 448 472  448 457 461 490  -HSync -VSync

        # 224x288x60.61 @ 18.909kHz
        Modeline "384x288x60.61"  8.925091  384 392 432 472  288 293 296 312  -HSync -VSync

        # 288x224x60.00 @ 29.400kHz
        Modeline "288x448x60.00"  10.348800  288 296 336 352  448 457 461 490  -HSync -VSync

        # 384x240x60.00 @ 15.600kHz
        Modeline "768x240x60.00"  14.352000  768 784 864 920  240 244 247 260  -HSync -VSync

        # 224x288x60.00 @ 18.720kHz
        Modeline "384x288x60.00"  8.835840  384 392 432 472  288 293 296 312  -HSync -VSync

        # 224x256x60.61 @ 16.788kHz
        Modeline "688x256x60.61"  13.833213  688 704 776 824  256 260 263 277  -HSync -VSync

        # 320x224x60.05 @ 29.427kHz
        Modeline "320x448x60.05"  11.535248  320 328 376 392  448 457 461 490  -HSync -VSync

        # 512x256x60.00 @ 16.620kHz
        Modeline "512x256x60.00"  10.237920  512 528 576 616  256 260 263 277  -HSync -VSync

        # 224x260x59.54 @ 16.791kHz
        Modeline "704x260x59.54"  14.238633  704 728 800 848  260 265 268 282  -HSync -VSync

        # 496x384x60.00 @ 24.960kHz
        Modeline "496x384x60.00"  14.776320  496 512 560 592  384 388 392 416  -HSync -VSync

        # 320x240x58.00 @ 15.250kHz
        Modeline "648x242x58.21"  11.834000  648 664 728 776  242 246 249 262  -HSync -VSync

        # 384x256x60.11 @ 16.650kHz
        Modeline "768x256x60.11"  15.317666  768 784 864 920  256 260 263 277  -HSync -VSync

        # 256x232x60.00 @ 30.480kHz
        Modeline "256x464x60.00"  9.509760  256 264 304 312  464 474 478 508  -HSync -VSync

        # 224x320x60.00 @ 20.820kHz
        Modeline "432x320x60.00"  10.493280  432 440 480 504  320 326 329 347  -HSync -VSync

        # 384x224x60.00 @ 29.400kHz
        Modeline "384x448x60.00"  13.876800  384 392 448 472  448 457 461 490  -HSync -VSync

        # 240x240x57.44 @ 30.159kHz
        Modeline "320x480x57.44"  11.822151  320 328 376 392  480 490 494 525  -HSync -VSync

        # 704x512x60.00 @ 32.040kHz
        Modeline "704x512x60.00"  28.964160  704 736 848 904  512 516 520 534  -HSync +VSync

        # 512x224x60.00 @ 29.400kHz
        Modeline "512x448x60.00"  18.345600  512 520 600 624  448 457 461 490  -HSync -VSync

        # 288x224x60.61 @ 29.697kHz
        Modeline "288x448x60.61"  10.453334  288 296 336 352  448 457 461 490  -HSync -VSync

        # 448x224x60.00 @ 29.400kHz
        Modeline "448x448x60.00"  16.228800  448 464 528 552  448 457 461 490  -HSync -VSync

        # 240x384x60.00 @ 24.960kHz
        Modeline "512x384x60.00"  15.375360  512 528 576 616  384 388 392 416  -HSync -VSync

        # 256x224x60.10 @ 29.447kHz
        Modeline "256x448x60.10"  9.187501  256 264 304 312  448 457 461 490  -HSync -VSync

        # 256x224x60.00 @ 29.400kHz
        Modeline "600x448x60.00"  21.638400  600 616 704 736  448 457 461 490  -HSync -VSync

        # 399x253x54.82 @ 30.415kHz
        Modeline "400x506x55.00"  14.842520  400 408 464 488  506 516 520 553  -HSync -VSync

        # 384x232x60.00 @ 30.480kHz
        Modeline "384x464x60.00"  14.386560  384 392 448 472  464 474 478 508  -HSync -VSync

        # 304x224x60.00 @ 29.400kHz
        Modeline "304x448x60.00"  11.054400  304 312 360 376  448 457 461 490  -HSync -VSync

        # 256x248x60.00 @ 16.140kHz
        Modeline "512x248x60.00"  9.942240  512 528 576 616  248 252 255 269  -HSync -VSync

        # 320x224x58.97 @ 28.895kHz
        Modeline "320x448x58.97"  11.326958  320 328 376 392  448 457 461 490  -HSync -VSync

        # 704x480x59.94 @ 31.469kHz
        Modeline "704x480x59.94"  27.692305  704 720 824 880  480 490 494 525  -HSync -VSync

        # 336x240x60.00 @ 15.600kHz
        Modeline "672x240x60.00"  12.604800  672 688 752 808  240 244 247 260  -HSync -VSync

        # 256x240x58.00 @ 15.250kHz
        Modeline "520x242x58.21"  9.516000  520 536 592 624  242 246 249 262  -HSync -VSync

        # 416x224x60.00 @ 29.400kHz
        Modeline "416x448x60.00"  15.052800  416 432 496 512  448 457 461 490  -HSync -VSync

        # 320x232x58.97 @ 29.957kHz
        Modeline "320x464x58.97"  11.743050  320 328 376 392  464 474 478 508  -HSync -VSync

        # 256x240x59.19 @ 15.388kHz
        Modeline "512x240x59.19"  9.479167  512 528 576 616  240 244 247 260  -HSync -VSync

        # 256x240x57.44 @ 30.159kHz
        Modeline "256x480x57.44"  9.409467  256 264 304 312  480 490 494 525  -HSync -VSync

        # 512x480x30.00 @ 31.500kHz
        Modeline "512x480x60.00"  20.160000  512 528 608 640  480 490 494 525  -HSync -VSync

        # 640x480x57.00 @ 29.925kHz
        Modeline "640x480x57.00"  23.461200  640 656 752 784  480 490 494 525  -HSync -VSync

        # 384x256x55.02 @ 15.250kHz
        Modeline "768x256x55.05"  14.030000  768 784 864 920  256 260 263 277  -HSync -VSync

        # 320x224x59.64 @ 29.222kHz
        Modeline "320x448x59.64"  11.455153  320 328 376 392  448 457 461 490  -HSync -VSync



lrmc mame.xml (using lrmc.conf: Clock = 4 - 25 / 15.625 - 16.650 / 49.50 - 65.00)
Code: [Select]

        # 256x224x60.00 @ 15.625kHz
        Modeline "280x240x60.10"  5.375000  280 288 312 344  240 244 247 260  -HSync -VSync

        # 640x480x60.00 @ 16.650kHz
        Modeline "640x255x60.11"  13.053600  640 656 712 784  255 260 263 277  -HSync -VSync

        # 224x256x60.00 @ 16.650kHz
        Modeline "344x255x60.11"  7.059600  344 352 384 424  255 260 263 277  -HSync -VSync

        # 320x240x60.00 @ 15.625kHz
        Modeline "320x240x60.10"  6.125000  320 328 360 392  240 244 247 260  -HSync -VSync

        # 320x224x60.00 @ 15.625kHz
        Modeline "344x240x60.10"  6.625000  344 352 384 424  240 244 247 260  -HSync -VSync

        # 320x224x59.19 @ 15.625kHz
        Modeline "352x243x59.19"  6.750000  352 360 392 432  243 248 251 264  -HSync -VSync

        # 384x224x59.63 @ 15.625kHz
        Modeline "416x241x59.64"  8.000000  416 432 472 512  241 246 249 262  -HSync -VSync

        # 512x288x60.00 @ 16.650kHz
        Modeline "512x255x60.11"  10.522800  512 528 576 632  255 260 263 277  -HSync -VSync

        # 336x240x59.92 @ 15.625kHz
        Modeline "336x240x60.10"  6.500000  336 344 376 416  240 244 247 260  -HSync -VSync

        # 256x240x60.00 @ 15.625kHz
        Modeline "256x240x60.10"  4.875000  256 264 288 312  240 244 247 260  -HSync -VSync

    # 1024x253x60.50 @ 16.094kHz
    Modeline "1024x253x60.50"  20.600440  1024 1048 1152 1280  253 256 260 266  +HSync +VSync

        # 288x224x60.00 @ 15.625kHz
        Modeline "312x240x60.10"  6.000000  312 320 352 384  240 244 247 260  -HSync -VSync

        # 224x288x60.61 @ 16.650kHz
        Modeline "384x253x60.77"  7.858800  384 392 424 472  253 257 260 274  -HSync -VSync

        # 384x240x60.00 @ 15.625kHz
        Modeline "384x240x60.10"  7.375000  384 392 424 472  240 244 247 260  -HSync -VSync

        # 224x288x60.00 @ 16.650kHz
        Modeline "384x255x60.11"  7.858800  384 392 424 472  255 260 263 277  -HSync -VSync

        # 224x256x60.61 @ 16.650kHz
        Modeline "344x253x60.77"  7.059600  344 352 384 424  253 257 260 274  -HSync -VSync

        # 496x384x60.00 @ 16.650kHz
        Modeline "496x255x60.11"  10.123200  496 512 560 608  255 260 263 277  -HSync -VSync

        # 224x260x59.54 @ 16.650kHz
        Modeline "352x257x59.68"  7.192800  352 360 392 432  257 262 265 279  -HSync -VSync

        # 256x232x60.00 @ 15.625kHz
        Modeline "264x240x60.10"  5.125000  264 272 296 328  240 244 247 260  -HSync -VSync

        # 320x240x58.00 @ 15.625kHz
        Modeline "336x248x58.09"  6.500000  336 344 376 416  248 252 255 269  -HSync -VSync

        # 224x320x60.00 @ 16.650kHz
        Modeline "432x255x60.11"  8.791200  432 440 480 528  255 260 263 277  -HSync -VSync

        # 512x240x60.00 @ 15.625kHz
        Modeline "512x240x60.10"  9.875000  512 528 576 632  240 244 247 260  -HSync -VSync

        # 240x240x57.44 @ 15.625kHz
        Modeline "336x250x57.66"  6.500000  336 344 376 416  250 254 257 271  -HSync -VSync

        # 384x224x60.00 @ 15.625kHz
        Modeline "416x240x60.10"  8.000000  416 432 472 512  240 244 247 260  -HSync -VSync

        # 704x512x60.00 @ 16.650kHz
        Modeline "704x255x60.11"  14.385600  704 720 784 864  255 260 263 277  -HSync -VSync

        # 288x224x60.61 @ 15.625kHz
        Modeline "304x237x60.80"  5.875000  304 312 336 376  237 241 244 257  -HSync -VSync

        # 512x224x60.00 @ 15.625kHz
        Modeline "552x240x60.10"  10.625000  552 568 616 680  240 244 247 260  -HSync -VSync

        # 256x224x60.10 @ 15.625kHz
        Modeline "272x239x60.33"  5.250000  272 280 304 336  239 243 246 259  -HSync -VSync

        # 448x224x60.00 @ 15.625kHz
        Modeline "480x240x60.10"  9.250000  480 496 536 592  240 244 247 260  -HSync -VSync

        # 256x224x60.00 @ 16.650kHz
        Modeline "600x255x60.11"  12.254400  600 616 672 736  255 260 263 277  -HSync -VSync

        # 304x224x60.00 @ 15.625kHz
        Modeline "328x240x60.10"  6.250000  328 336 368 400  240 244 247 260  -HSync -VSync

        # 384x232x60.00 @ 15.625kHz
        Modeline "400x240x60.10"  7.750000  400 416 456 496  240 244 247 260  -HSync -VSync

        # 399x253x54.82 @ 15.625kHz
        Modeline "416x263x54.82"  8.000000  416 432 472 512  263 267 270 285  -HSync -VSync

        # 256x248x60.00 @ 16.140kHz
        Modeline "256x248x60.00"  5.035680  256 264 288 312  248 252 255 269  -HSync -VSync

        # 416x224x60.00 @ 15.625kHz
        Modeline "448x240x60.10"  8.625000  448 464 504 552  240 244 247 260  -HSync -VSync

        # 640x240x60.00 @ 15.625kHz
        Modeline "640x240x60.10"  12.250000  640 656 712 784  240 244 247 260  -HSync -VSync

        # 320x232x58.97 @ 15.625kHz
        Modeline "336x243x59.19"  6.500000  336 344 376 416  243 248 251 264  -HSync -VSync

        # 256x240x58.00 @ 15.625kHz
        Modeline "264x248x58.09"  5.125000  264 272 296 328  248 252 255 269  -HSync -VSync

        # 256x256x60.00 @ 16.650kHz
        Modeline "256x255x60.11"  5.194800  256 264 288 312  255 260 263 277  -HSync -VSync

        # 512x480x30.00 @ 16.650kHz
        Modeline "512x236x65.04"  10.522800  512 528 576 632  236 240 243 256  -HSync -VSync

        # 256x240x59.19 @ 15.625kHz
        Modeline "264x243x59.19"  5.125000  264 272 296 328  243 248 251 264  -HSync -VSync

        # 256x240x57.44 @ 15.625kHz
        Modeline "272x250x57.66"  5.250000  272 280 304 336  250 254 257 271  -HSync -VSync

        # 640x480x57.00 @ 16.650kHz
        Modeline "640x269x57.02"  13.053600  640 656 712 784  269 274 277 292  -HSync -VSync

        # 320x224x59.64 @ 15.625kHz
        Modeline "344x241x59.87"  6.625000  344 352 384 424  241 245 248 261  -HSync -VSync

    # 800x255x59.84 @ 16.038kHz
    Modeline "800x255x59.84"  15.909851  800 816 896 992  255 258 262 268  +HSync +VSync

        # 384x256x55.02 @ 15.625kHz
        Modeline "392x261x55.21"  7.500000  392 400 432 480  261 265 268 283  -HSync -VSync

        # 496x384x57.52 @ 16.650kHz
        Modeline "496x266x57.61"  10.123200  496 512 560 608  266 271 274 289  -HSync -VSync

        # 240x320x54.00 @ 16.650kHz
        Modeline "432x284x54.06"  8.791200  432 440 480 528  284 289 292 308  -HSync -VSync

        # 352x240x60.00 @ 15.625kHz
        Modeline "352x240x60.10"  6.750000  352 360 392 432  240 244 247 260  -HSync -VSync

    # 856x255x59.84 @ 16.038kHz
    Modeline "856x255x59.84"  17.064599  856 872 960 1064  255 258 262 268  +HSync +VSync

        # 320x240x59.60 @ 15.625kHz
        Modeline "328x241x59.64"  6.250000  328 336 368 400  241 246 249 262  -HSync -VSync

        # 384x512x60.10 @ 16.650kHz
        Modeline "688x255x60.11"  14.119200  688 712 776 848  255 260 263 277  -HSync -VSync

        # 256x224x59.19 @ 15.625kHz
        Modeline "280x243x59.19"  5.375000  280 288 312 344  243 248 251 264  -HSync -VSync

        # 240x248x60.00 @ 16.140kHz
        Modeline "336x248x60.00"  6.714240  336 344 376 416  248 252 255 269  -HSync -VSync

        # 256x224x57.50 @ 15.625kHz
        Modeline "288x250x57.66"  5.500000  288 296 320 352  250 254 257 271  -HSync -VSync

        # 256x240x57.41 @ 15.625kHz
        Modeline "272x251x57.44"  5.250000  272 280 304 336  251 255 258 272  -HSync -VSync

        # 208x256x61.04 @ 16.650kHz
        Modeline "344x251x61.21"  7.059600  344 352 384 424  251 255 258 272  -HSync -VSync

        # 256x224x60.61 @ 15.625kHz
        Modeline "272x237x60.80"  5.250000  272 280 304 336  237 241 244 257  -HSync -VSync

        # 260x224x59.54 @ 15.625kHz
        Modeline "280x241x59.64"  5.375000  280 288 312 344  241 246 249 262  -HSync -VSync

        # 360x240x59.92 @ 15.625kHz
        Modeline "360x240x60.10"  6.875000  360 368 400 440  240 244 247 260  -HSync -VSync

        # 256x224x56.00 @ 15.625kHz
        Modeline "296x257x56.00"  5.750000  296 304 328 368  257 262 265 279  -HSync -VSync

        # 224x256x56.00 @ 15.625kHz
        Modeline "344x257x56.00"  6.625000  344 352 384 424  257 262 265 279  -HSync -VSync

        # 512x288x60.31 @ 16.650kHz
        Modeline "512x254x60.33"  10.522800  512 528 576 632  254 259 262 276  -HSync -VSync

        # 544x480x60.00 @ 16.650kHz
        Modeline "544x255x60.11"  11.188800  544 560 608 672  255 260 263 277  -HSync -VSync

        # 384x256x55.00 @ 15.625kHz
        Modeline "392x262x55.02"  7.500000  392 400 432 480  262 266 269 284  -HSync -VSync

        # 292x240x60.10 @ 15.625kHz
        Modeline "296x240x60.10"  5.750001  296 304 328 368  240 244 247 260  -HSync -VSync

        # 671x216x60.00 @ 15.625kHz
        Modeline "744x240x60.10"  14.250000  744 760 824 912  240 244 247 260  -HSync -VSync

        # 240x240x60.00 @ 15.625kHz
        Modeline "240x240x60.10"  4.625000  240 248 272 296  240 244 247 260  -HSync -VSync

        # 512x256x57.00 @ 15.846kHz
        Modeline "512x256x57.00"  10.014672  512 528 576 632  256 261 264 278  -HSync -VSync

        # 488x384x58.00 @ 16.650kHz
        Modeline "488x264x58.01"  9.990000  488 504 552 600  264 269 272 287  -HSync -VSync

        # 294x238x60.10 @ 15.625kHz
        Modeline "296x239x60.33"  5.750000  296 304 328 368  239 243 246 259  -HSync -VSync

        # 288x224x59.19 @ 15.625kHz
        Modeline "312x243x59.19"  6.000000  312 320 352 384  243 248 251 264  -HSync -VSync

        # 224x280x60.00 @ 16.650kHz
        Modeline "376x255x60.11"  7.725600  376 384 416 464  255 260 263 277  -HSync -VSync

        # 288x240x60.00 @ 15.625kHz
        Modeline "288x240x60.10"  5.500000  288 296 320 352  240 244 247 260  -HSync -VSync

        # 256x256x57.00 @ 15.846kHz
        Modeline "344x256x57.00"  6.718704  344 352 384 424  256 261 264 278  -HSync -VSync

        # 256x256x76.29 @ 16.650kHz
        Modeline "344x236x65.04"  7.059600  344 352 384 424  236 240 243 256  -HSync -VSync

        # 480x512x30.00 @ 16.650kHz
        Modeline "688x236x65.04"  14.119200  688 712 776 848  236 240 243 256  -HSync -VSync

        # 384x224x59.19 @ 15.625kHz
        Modeline "416x243x59.19"  8.000000  416 432 472 512  243 248 251 264  -HSync -VSync

        # 236x272x60.00 @ 16.650kHz
        Modeline "368x255x60.11"  7.592400  368 384 416 456  255 260 263 277  -HSync -VSync

        # 240x344x60.00 @ 16.650kHz
        Modeline "464x255x60.11"  9.457200  464 472 512 568  255 260 263 277  -HSync -VSync

        # 256x256x56.31 @ 15.654kHz
        Modeline "344x256x56.31"  6.637191  344 352 384 424  256 261 264 278  -HSync -VSync

        # 240x320x57.55 @ 16.650kHz
        Modeline "432x266x57.61"  8.791200  432 440 480 528  266 271 274 289  -HSync -VSync

        # 400x280x50.00 @ 15.625kHz
        Modeline "416x288x50.08"  8.000000  416 432 472 512  288 293 296 312  -HSync -VSync

        # 288x224x59.70 @ 15.625kHz
        Modeline "312x241x59.87"  6.000000  312 320 352 384  241 245 248 261  -HSync -VSync

        # 432x224x59.00 @ 15.625kHz
        Modeline "472x243x59.19"  9.125000  472 488 528 584  243 248 251 264  -HSync -VSync

        # 240x256x61.42 @ 16.650kHz
        Modeline "344x250x61.44"  7.059600  344 352 384 424  250 254 257 271  -HSync -VSync

        # 224x272x60.61 @ 16.650kHz
        Modeline "368x253x60.77"  7.592400  368 384 416 456  253 257 260 274  -HSync -VSync

        # 224x384x59.63 @ 16.650kHz
        Modeline "512x257x59.68"  10.522800  512 528 576 632  257 262 265 279  -HSync -VSync

        # 256x256x55.00 @ 15.625kHz
        Modeline "264x262x55.02"  5.125000  264 272 296 328  262 266 269 284  -HSync -VSync

        # 512x228x60.20 @ 15.625kHz
        Modeline "536x239x60.33"  10.250000  536 552 600 656  239 243 246 259  -HSync -VSync

        # 376x240x60.00 @ 15.625kHz
        Modeline "376x240x60.10"  7.250000  376 384 416 464  240 244 247 260  -HSync -VSync

        # 320x256x60.00 @ 16.650kHz
        Modeline "320x255x60.11"  6.526800  320 328 360 392  255 260 263 277  -HSync -VSync

        # 512x256x59.19 @ 16.454kHz
        Modeline "512x256x59.19"  10.398675  512 528 576 632  256 261 264 278  -HSync -VSync

        # 224x320x58.97 @ 16.650kHz
        Modeline "432x260x59.04"  8.791200  432 440 480 528  260 264 267 282  -HSync -VSync

        # 512x400x57.35 @ 16.650kHz
        Modeline "512x267x57.41"  10.522800  512 528 576 632  267 272 275 290  -HSync -VSync

        # 400x256x60.00 @ 16.650kHz
        Modeline "400x255x60.11"  8.258400  400 416 456 496  255 260 263 277  -HSync -VSync

        # 224x400x60.00 @ 16.650kHz
        Modeline "536x255x60.11"  10.922400  536 552 600 656  255 260 263 277  -HSync -VSync

        # 240x256x58.00 @ 16.124kHz
        Modeline "344x256x58.00"  6.836576  344 352 384 424  256 261 264 278  -HSync -VSync

        # 224x320x59.30 @ 16.650kHz
        Modeline "432x258x59.46"  8.791200  432 440 480 528  258 263 266 280  -HSync -VSync

        # 256x240x61.42 @ 15.969kHz
        Modeline "256x240x61.42"  4.982312  256 264 288 312  240 244 247 260  -HSync -VSync

        # 672x240x59.92 @ 15.625kHz
        Modeline "672x240x60.10"  12.875000  672 688 752 824  240 244 247 260  -HSync -VSync

        # 319x255x61.04 @ 16.650kHz
        Modeline "320x251x61.21"  6.526800  320 328 360 392  251 255 258 272  -HSync -VSync

Are you getting the same or am I missing something?
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: bitbytebit on October 25, 2010, 08:04:31 am
Hi bitbytebit,

I've been testing your lrmc for Windows, I'd like to paste the results I'm getting to make sure we both get the same. I've done two tests, one with -D9800 (no lrmc.conf), and another with lrmc.conf set for Hantarex MTC9110. Using mame.xml v0.131. Here they are:

lrmc mame.xml -D9800

Code: [Select]

        # 256x224x60.00 @ 29.400kHz
        Modeline "256x448x60.00"  9.172800  256 264 304 312  448 457 461 490  -HSync -VSync

        # 640x480x60.00 @ 31.500kHz
        Modeline "640x480x60.00"  25.200000  640 656 752 800  480 490 494 525  -HSync -VSync

        # 224x256x60.00 @ 16.620kHz
        Modeline "688x256x60.00"  13.694880  688 704 776 824  256 260 263 277  -HSync -VSync

        # 320x240x60.00 @ 15.600kHz
        Modeline "640x240x60.00"  11.980800  640 656 720 768  240 244 247 260  -HSync -VSync

        # 320x224x60.00 @ 29.400kHz
        Modeline "320x448x60.00"  11.524800  320 328 376 392  448 457 461 490  -HSync -VSync

        # 320x224x59.19 @ 29.001kHz
        Modeline "320x448x59.19"  11.368372  320 328 376 392  448 457 461 490  -HSync -VSync

        # 384x224x59.63 @ 29.218kHz
        Modeline "384x448x59.63"  13.791089  384 392 448 472  448 457 461 490  -HSync -VSync

        # 512x288x60.00 @ 18.720kHz
        Modeline "512x288x60.00"  11.681280  512 520 568 624  288 293 296 312  -HSync -VSync

        # 256x240x60.00 @ 15.600kHz
        Modeline "512x240x60.00"  9.609600  512 528 576 616  240 244 247 260  -HSync -VSync

        # 336x240x59.92 @ 15.580kHz
        Modeline "672x240x59.92"  12.588570  672 688 752 808  240 244 247 260  -HSync -VSync

    # 1024x697x55.01 @ 39.716kHz
    Modeline "1024x697x55.01"  52.107801  1024 1064 1168 1312  697 700 704 722  +HSync +VSync

        # 384x224x59.61 @ 29.209kHz
        Modeline "384x448x59.61"  13.786601  384 392 448 472  448 457 461 490  -HSync -VSync

        # 224x288x60.61 @ 18.909kHz
        Modeline "384x288x60.61"  8.925091  384 392 432 472  288 293 296 312  -HSync -VSync

        # 288x224x60.00 @ 29.400kHz
        Modeline "288x448x60.00"  10.348800  288 296 336 352  448 457 461 490  -HSync -VSync

        # 384x240x60.00 @ 15.600kHz
        Modeline "768x240x60.00"  14.352000  768 784 864 920  240 244 247 260  -HSync -VSync

        # 224x288x60.00 @ 18.720kHz
        Modeline "384x288x60.00"  8.835840  384 392 432 472  288 293 296 312  -HSync -VSync

        # 224x256x60.61 @ 16.788kHz
        Modeline "688x256x60.61"  13.833213  688 704 776 824  256 260 263 277  -HSync -VSync

        # 320x224x60.05 @ 29.427kHz
        Modeline "320x448x60.05"  11.535248  320 328 376 392  448 457 461 490  -HSync -VSync

        # 512x256x60.00 @ 16.620kHz
        Modeline "512x256x60.00"  10.237920  512 528 576 616  256 260 263 277  -HSync -VSync

        # 224x260x59.54 @ 16.791kHz
        Modeline "704x260x59.54"  14.238633  704 728 800 848  260 265 268 282  -HSync -VSync

        # 496x384x60.00 @ 24.960kHz
        Modeline "496x384x60.00"  14.776320  496 512 560 592  384 388 392 416  -HSync -VSync

        # 320x240x58.00 @ 15.250kHz
        Modeline "648x242x58.21"  11.834000  648 664 728 776  242 246 249 262  -HSync -VSync

        # 384x256x60.11 @ 16.650kHz
        Modeline "768x256x60.11"  15.317666  768 784 864 920  256 260 263 277  -HSync -VSync

        # 256x232x60.00 @ 30.480kHz
        Modeline "256x464x60.00"  9.509760  256 264 304 312  464 474 478 508  -HSync -VSync

        # 224x320x60.00 @ 20.820kHz
        Modeline "432x320x60.00"  10.493280  432 440 480 504  320 326 329 347  -HSync -VSync

        # 384x224x60.00 @ 29.400kHz
        Modeline "384x448x60.00"  13.876800  384 392 448 472  448 457 461 490  -HSync -VSync

        # 240x240x57.44 @ 30.159kHz
        Modeline "320x480x57.44"  11.822151  320 328 376 392  480 490 494 525  -HSync -VSync

        # 704x512x60.00 @ 32.040kHz
        Modeline "704x512x60.00"  28.964160  704 736 848 904  512 516 520 534  -HSync +VSync

        # 512x224x60.00 @ 29.400kHz
        Modeline "512x448x60.00"  18.345600  512 520 600 624  448 457 461 490  -HSync -VSync

        # 288x224x60.61 @ 29.697kHz
        Modeline "288x448x60.61"  10.453334  288 296 336 352  448 457 461 490  -HSync -VSync

        # 448x224x60.00 @ 29.400kHz
        Modeline "448x448x60.00"  16.228800  448 464 528 552  448 457 461 490  -HSync -VSync

        # 240x384x60.00 @ 24.960kHz
        Modeline "512x384x60.00"  15.375360  512 528 576 616  384 388 392 416  -HSync -VSync

        # 256x224x60.10 @ 29.447kHz
        Modeline "256x448x60.10"  9.187501  256 264 304 312  448 457 461 490  -HSync -VSync

        # 256x224x60.00 @ 29.400kHz
        Modeline "600x448x60.00"  21.638400  600 616 704 736  448 457 461 490  -HSync -VSync

        # 399x253x54.82 @ 30.415kHz
        Modeline "400x506x55.00"  14.842520  400 408 464 488  506 516 520 553  -HSync -VSync

        # 384x232x60.00 @ 30.480kHz
        Modeline "384x464x60.00"  14.386560  384 392 448 472  464 474 478 508  -HSync -VSync

        # 304x224x60.00 @ 29.400kHz
        Modeline "304x448x60.00"  11.054400  304 312 360 376  448 457 461 490  -HSync -VSync

        # 256x248x60.00 @ 16.140kHz
        Modeline "512x248x60.00"  9.942240  512 528 576 616  248 252 255 269  -HSync -VSync

        # 320x224x58.97 @ 28.895kHz
        Modeline "320x448x58.97"  11.326958  320 328 376 392  448 457 461 490  -HSync -VSync

        # 704x480x59.94 @ 31.469kHz
        Modeline "704x480x59.94"  27.692305  704 720 824 880  480 490 494 525  -HSync -VSync

        # 336x240x60.00 @ 15.600kHz
        Modeline "672x240x60.00"  12.604800  672 688 752 808  240 244 247 260  -HSync -VSync

        # 256x240x58.00 @ 15.250kHz
        Modeline "520x242x58.21"  9.516000  520 536 592 624  242 246 249 262  -HSync -VSync

        # 416x224x60.00 @ 29.400kHz
        Modeline "416x448x60.00"  15.052800  416 432 496 512  448 457 461 490  -HSync -VSync

        # 320x232x58.97 @ 29.957kHz
        Modeline "320x464x58.97"  11.743050  320 328 376 392  464 474 478 508  -HSync -VSync

        # 256x240x59.19 @ 15.388kHz
        Modeline "512x240x59.19"  9.479167  512 528 576 616  240 244 247 260  -HSync -VSync

        # 256x240x57.44 @ 30.159kHz
        Modeline "256x480x57.44"  9.409467  256 264 304 312  480 490 494 525  -HSync -VSync

        # 512x480x30.00 @ 31.500kHz
        Modeline "512x480x60.00"  20.160000  512 528 608 640  480 490 494 525  -HSync -VSync

        # 640x480x57.00 @ 29.925kHz
        Modeline "640x480x57.00"  23.461200  640 656 752 784  480 490 494 525  -HSync -VSync

        # 384x256x55.02 @ 15.250kHz
        Modeline "768x256x55.05"  14.030000  768 784 864 920  256 260 263 277  -HSync -VSync

        # 320x224x59.64 @ 29.222kHz
        Modeline "320x448x59.64"  11.455153  320 328 376 392  448 457 461 490  -HSync -VSync



lrmc mame.xml (using lrmc.conf: Clock = 4 - 25 / 15.625 - 16.650 / 49.50 - 65.00)
Code: [Select]

        # 256x224x60.00 @ 15.625kHz
        Modeline "280x240x60.10"  5.375000  280 288 312 344  240 244 247 260  -HSync -VSync

        # 640x480x60.00 @ 16.650kHz
        Modeline "640x255x60.11"  13.053600  640 656 712 784  255 260 263 277  -HSync -VSync

        # 224x256x60.00 @ 16.650kHz
        Modeline "344x255x60.11"  7.059600  344 352 384 424  255 260 263 277  -HSync -VSync

        # 320x240x60.00 @ 15.625kHz
        Modeline "320x240x60.10"  6.125000  320 328 360 392  240 244 247 260  -HSync -VSync

        # 320x224x60.00 @ 15.625kHz
        Modeline "344x240x60.10"  6.625000  344 352 384 424  240 244 247 260  -HSync -VSync

        # 320x224x59.19 @ 15.625kHz
        Modeline "352x243x59.19"  6.750000  352 360 392 432  243 248 251 264  -HSync -VSync

        # 384x224x59.63 @ 15.625kHz
        Modeline "416x241x59.64"  8.000000  416 432 472 512  241 246 249 262  -HSync -VSync

        # 512x288x60.00 @ 16.650kHz
        Modeline "512x255x60.11"  10.522800  512 528 576 632  255 260 263 277  -HSync -VSync

        # 336x240x59.92 @ 15.625kHz
        Modeline "336x240x60.10"  6.500000  336 344 376 416  240 244 247 260  -HSync -VSync

        # 256x240x60.00 @ 15.625kHz
        Modeline "256x240x60.10"  4.875000  256 264 288 312  240 244 247 260  -HSync -VSync

    # 1024x253x60.50 @ 16.094kHz
    Modeline "1024x253x60.50"  20.600440  1024 1048 1152 1280  253 256 260 266  +HSync +VSync

        # 288x224x60.00 @ 15.625kHz
        Modeline "312x240x60.10"  6.000000  312 320 352 384  240 244 247 260  -HSync -VSync

        # 224x288x60.61 @ 16.650kHz
        Modeline "384x253x60.77"  7.858800  384 392 424 472  253 257 260 274  -HSync -VSync

        # 384x240x60.00 @ 15.625kHz
        Modeline "384x240x60.10"  7.375000  384 392 424 472  240 244 247 260  -HSync -VSync

        # 224x288x60.00 @ 16.650kHz
        Modeline "384x255x60.11"  7.858800  384 392 424 472  255 260 263 277  -HSync -VSync

        # 224x256x60.61 @ 16.650kHz
        Modeline "344x253x60.77"  7.059600  344 352 384 424  253 257 260 274  -HSync -VSync

        # 496x384x60.00 @ 16.650kHz
        Modeline "496x255x60.11"  10.123200  496 512 560 608  255 260 263 277  -HSync -VSync

        # 224x260x59.54 @ 16.650kHz
        Modeline "352x257x59.68"  7.192800  352 360 392 432  257 262 265 279  -HSync -VSync

        # 256x232x60.00 @ 15.625kHz
        Modeline "264x240x60.10"  5.125000  264 272 296 328  240 244 247 260  -HSync -VSync

        # 320x240x58.00 @ 15.625kHz
        Modeline "336x248x58.09"  6.500000  336 344 376 416  248 252 255 269  -HSync -VSync

        # 224x320x60.00 @ 16.650kHz
        Modeline "432x255x60.11"  8.791200  432 440 480 528  255 260 263 277  -HSync -VSync

        # 512x240x60.00 @ 15.625kHz
        Modeline "512x240x60.10"  9.875000  512 528 576 632  240 244 247 260  -HSync -VSync

        # 240x240x57.44 @ 15.625kHz
        Modeline "336x250x57.66"  6.500000  336 344 376 416  250 254 257 271  -HSync -VSync

        # 384x224x60.00 @ 15.625kHz
        Modeline "416x240x60.10"  8.000000  416 432 472 512  240 244 247 260  -HSync -VSync

        # 704x512x60.00 @ 16.650kHz
        Modeline "704x255x60.11"  14.385600  704 720 784 864  255 260 263 277  -HSync -VSync

        # 288x224x60.61 @ 15.625kHz
        Modeline "304x237x60.80"  5.875000  304 312 336 376  237 241 244 257  -HSync -VSync

        # 512x224x60.00 @ 15.625kHz
        Modeline "552x240x60.10"  10.625000  552 568 616 680  240 244 247 260  -HSync -VSync

        # 256x224x60.10 @ 15.625kHz
        Modeline "272x239x60.33"  5.250000  272 280 304 336  239 243 246 259  -HSync -VSync

        # 448x224x60.00 @ 15.625kHz
        Modeline "480x240x60.10"  9.250000  480 496 536 592  240 244 247 260  -HSync -VSync

        # 256x224x60.00 @ 16.650kHz
        Modeline "600x255x60.11"  12.254400  600 616 672 736  255 260 263 277  -HSync -VSync

        # 304x224x60.00 @ 15.625kHz
        Modeline "328x240x60.10"  6.250000  328 336 368 400  240 244 247 260  -HSync -VSync

        # 384x232x60.00 @ 15.625kHz
        Modeline "400x240x60.10"  7.750000  400 416 456 496  240 244 247 260  -HSync -VSync

        # 399x253x54.82 @ 15.625kHz
        Modeline "416x263x54.82"  8.000000  416 432 472 512  263 267 270 285  -HSync -VSync

        # 256x248x60.00 @ 16.140kHz
        Modeline "256x248x60.00"  5.035680  256 264 288 312  248 252 255 269  -HSync -VSync

        # 416x224x60.00 @ 15.625kHz
        Modeline "448x240x60.10"  8.625000  448 464 504 552  240 244 247 260  -HSync -VSync

        # 640x240x60.00 @ 15.625kHz
        Modeline "640x240x60.10"  12.250000  640 656 712 784  240 244 247 260  -HSync -VSync

        # 320x232x58.97 @ 15.625kHz
        Modeline "336x243x59.19"  6.500000  336 344 376 416  243 248 251 264  -HSync -VSync

        # 256x240x58.00 @ 15.625kHz
        Modeline "264x248x58.09"  5.125000  264 272 296 328  248 252 255 269  -HSync -VSync

        # 256x256x60.00 @ 16.650kHz
        Modeline "256x255x60.11"  5.194800  256 264 288 312  255 260 263 277  -HSync -VSync

        # 512x480x30.00 @ 16.650kHz
        Modeline "512x236x65.04"  10.522800  512 528 576 632  236 240 243 256  -HSync -VSync

        # 256x240x59.19 @ 15.625kHz
        Modeline "264x243x59.19"  5.125000  264 272 296 328  243 248 251 264  -HSync -VSync

        # 256x240x57.44 @ 15.625kHz
        Modeline "272x250x57.66"  5.250000  272 280 304 336  250 254 257 271  -HSync -VSync

        # 640x480x57.00 @ 16.650kHz
        Modeline "640x269x57.02"  13.053600  640 656 712 784  269 274 277 292  -HSync -VSync

        # 320x224x59.64 @ 15.625kHz
        Modeline "344x241x59.87"  6.625000  344 352 384 424  241 245 248 261  -HSync -VSync

    # 800x255x59.84 @ 16.038kHz
    Modeline "800x255x59.84"  15.909851  800 816 896 992  255 258 262 268  +HSync +VSync

        # 384x256x55.02 @ 15.625kHz
        Modeline "392x261x55.21"  7.500000  392 400 432 480  261 265 268 283  -HSync -VSync

        # 496x384x57.52 @ 16.650kHz
        Modeline "496x266x57.61"  10.123200  496 512 560 608  266 271 274 289  -HSync -VSync

        # 240x320x54.00 @ 16.650kHz
        Modeline "432x284x54.06"  8.791200  432 440 480 528  284 289 292 308  -HSync -VSync

        # 352x240x60.00 @ 15.625kHz
        Modeline "352x240x60.10"  6.750000  352 360 392 432  240 244 247 260  -HSync -VSync

    # 856x255x59.84 @ 16.038kHz
    Modeline "856x255x59.84"  17.064599  856 872 960 1064  255 258 262 268  +HSync +VSync

        # 320x240x59.60 @ 15.625kHz
        Modeline "328x241x59.64"  6.250000  328 336 368 400  241 246 249 262  -HSync -VSync

        # 384x512x60.10 @ 16.650kHz
        Modeline "688x255x60.11"  14.119200  688 712 776 848  255 260 263 277  -HSync -VSync

        # 256x224x59.19 @ 15.625kHz
        Modeline "280x243x59.19"  5.375000  280 288 312 344  243 248 251 264  -HSync -VSync

        # 240x248x60.00 @ 16.140kHz
        Modeline "336x248x60.00"  6.714240  336 344 376 416  248 252 255 269  -HSync -VSync

        # 256x224x57.50 @ 15.625kHz
        Modeline "288x250x57.66"  5.500000  288 296 320 352  250 254 257 271  -HSync -VSync

        # 256x240x57.41 @ 15.625kHz
        Modeline "272x251x57.44"  5.250000  272 280 304 336  251 255 258 272  -HSync -VSync

        # 208x256x61.04 @ 16.650kHz
        Modeline "344x251x61.21"  7.059600  344 352 384 424  251 255 258 272  -HSync -VSync

        # 256x224x60.61 @ 15.625kHz
        Modeline "272x237x60.80"  5.250000  272 280 304 336  237 241 244 257  -HSync -VSync

        # 260x224x59.54 @ 15.625kHz
        Modeline "280x241x59.64"  5.375000  280 288 312 344  241 246 249 262  -HSync -VSync

        # 360x240x59.92 @ 15.625kHz
        Modeline "360x240x60.10"  6.875000  360 368 400 440  240 244 247 260  -HSync -VSync

        # 256x224x56.00 @ 15.625kHz
        Modeline "296x257x56.00"  5.750000  296 304 328 368  257 262 265 279  -HSync -VSync

        # 224x256x56.00 @ 15.625kHz
        Modeline "344x257x56.00"  6.625000  344 352 384 424  257 262 265 279  -HSync -VSync

        # 512x288x60.31 @ 16.650kHz
        Modeline "512x254x60.33"  10.522800  512 528 576 632  254 259 262 276  -HSync -VSync

        # 544x480x60.00 @ 16.650kHz
        Modeline "544x255x60.11"  11.188800  544 560 608 672  255 260 263 277  -HSync -VSync

        # 384x256x55.00 @ 15.625kHz
        Modeline "392x262x55.02"  7.500000  392 400 432 480  262 266 269 284  -HSync -VSync

        # 292x240x60.10 @ 15.625kHz
        Modeline "296x240x60.10"  5.750001  296 304 328 368  240 244 247 260  -HSync -VSync

        # 671x216x60.00 @ 15.625kHz
        Modeline "744x240x60.10"  14.250000  744 760 824 912  240 244 247 260  -HSync -VSync

        # 240x240x60.00 @ 15.625kHz
        Modeline "240x240x60.10"  4.625000  240 248 272 296  240 244 247 260  -HSync -VSync

        # 512x256x57.00 @ 15.846kHz
        Modeline "512x256x57.00"  10.014672  512 528 576 632  256 261 264 278  -HSync -VSync

        # 488x384x58.00 @ 16.650kHz
        Modeline "488x264x58.01"  9.990000  488 504 552 600  264 269 272 287  -HSync -VSync

        # 294x238x60.10 @ 15.625kHz
        Modeline "296x239x60.33"  5.750000  296 304 328 368  239 243 246 259  -HSync -VSync

        # 288x224x59.19 @ 15.625kHz
        Modeline "312x243x59.19"  6.000000  312 320 352 384  243 248 251 264  -HSync -VSync

        # 224x280x60.00 @ 16.650kHz
        Modeline "376x255x60.11"  7.725600  376 384 416 464  255 260 263 277  -HSync -VSync

        # 288x240x60.00 @ 15.625kHz
        Modeline "288x240x60.10"  5.500000  288 296 320 352  240 244 247 260  -HSync -VSync

        # 256x256x57.00 @ 15.846kHz
        Modeline "344x256x57.00"  6.718704  344 352 384 424  256 261 264 278  -HSync -VSync

        # 256x256x76.29 @ 16.650kHz
        Modeline "344x236x65.04"  7.059600  344 352 384 424  236 240 243 256  -HSync -VSync

        # 480x512x30.00 @ 16.650kHz
        Modeline "688x236x65.04"  14.119200  688 712 776 848  236 240 243 256  -HSync -VSync

        # 384x224x59.19 @ 15.625kHz
        Modeline "416x243x59.19"  8.000000  416 432 472 512  243 248 251 264  -HSync -VSync

        # 236x272x60.00 @ 16.650kHz
        Modeline "368x255x60.11"  7.592400  368 384 416 456  255 260 263 277  -HSync -VSync

        # 240x344x60.00 @ 16.650kHz
        Modeline "464x255x60.11"  9.457200  464 472 512 568  255 260 263 277  -HSync -VSync

        # 256x256x56.31 @ 15.654kHz
        Modeline "344x256x56.31"  6.637191  344 352 384 424  256 261 264 278  -HSync -VSync

        # 240x320x57.55 @ 16.650kHz
        Modeline "432x266x57.61"  8.791200  432 440 480 528  266 271 274 289  -HSync -VSync

        # 400x280x50.00 @ 15.625kHz
        Modeline "416x288x50.08"  8.000000  416 432 472 512  288 293 296 312  -HSync -VSync

        # 288x224x59.70 @ 15.625kHz
        Modeline "312x241x59.87"  6.000000  312 320 352 384  241 245 248 261  -HSync -VSync

        # 432x224x59.00 @ 15.625kHz
        Modeline "472x243x59.19"  9.125000  472 488 528 584  243 248 251 264  -HSync -VSync

        # 240x256x61.42 @ 16.650kHz
        Modeline "344x250x61.44"  7.059600  344 352 384 424  250 254 257 271  -HSync -VSync

        # 224x272x60.61 @ 16.650kHz
        Modeline "368x253x60.77"  7.592400  368 384 416 456  253 257 260 274  -HSync -VSync

        # 224x384x59.63 @ 16.650kHz
        Modeline "512x257x59.68"  10.522800  512 528 576 632  257 262 265 279  -HSync -VSync

        # 256x256x55.00 @ 15.625kHz
        Modeline "264x262x55.02"  5.125000  264 272 296 328  262 266 269 284  -HSync -VSync

        # 512x228x60.20 @ 15.625kHz
        Modeline "536x239x60.33"  10.250000  536 552 600 656  239 243 246 259  -HSync -VSync

        # 376x240x60.00 @ 15.625kHz
        Modeline "376x240x60.10"  7.250000  376 384 416 464  240 244 247 260  -HSync -VSync

        # 320x256x60.00 @ 16.650kHz
        Modeline "320x255x60.11"  6.526800  320 328 360 392  255 260 263 277  -HSync -VSync

        # 512x256x59.19 @ 16.454kHz
        Modeline "512x256x59.19"  10.398675  512 528 576 632  256 261 264 278  -HSync -VSync

        # 224x320x58.97 @ 16.650kHz
        Modeline "432x260x59.04"  8.791200  432 440 480 528  260 264 267 282  -HSync -VSync

        # 512x400x57.35 @ 16.650kHz
        Modeline "512x267x57.41"  10.522800  512 528 576 632  267 272 275 290  -HSync -VSync

        # 400x256x60.00 @ 16.650kHz
        Modeline "400x255x60.11"  8.258400  400 416 456 496  255 260 263 277  -HSync -VSync

        # 224x400x60.00 @ 16.650kHz
        Modeline "536x255x60.11"  10.922400  536 552 600 656  255 260 263 277  -HSync -VSync

        # 240x256x58.00 @ 16.124kHz
        Modeline "344x256x58.00"  6.836576  344 352 384 424  256 261 264 278  -HSync -VSync

        # 224x320x59.30 @ 16.650kHz
        Modeline "432x258x59.46"  8.791200  432 440 480 528  258 263 266 280  -HSync -VSync

        # 256x240x61.42 @ 15.969kHz
        Modeline "256x240x61.42"  4.982312  256 264 288 312  240 244 247 260  -HSync -VSync

        # 672x240x59.92 @ 15.625kHz
        Modeline "672x240x60.10"  12.875000  672 688 752 824  240 244 247 260  -HSync -VSync

        # 319x255x61.04 @ 16.650kHz
        Modeline "320x251x61.21"  6.526800  320 328 360 392  251 255 258 272  -HSync -VSync

Are you getting the same or am I missing something?

Try it with these args...


lrmc mame.xml -d9800 -n -i -d -sl -v

Those should make the resolutions much closer to the ones asked for, if not exact in most cases.  Defaults of lrmc aren't really great, at least if you've got an arcade monitor :).

Also these could be of some interest too...

Code: [Select]
 
  -win, --windows        If your using Windows modelines/ini files
  -ff, --fixfrogger      If you have the frogger/galaxian patch from CabMAME
  -ini                   When using mame.xml create .ini files in ./ini/
  -rm, --roundmodes      When using mame.xml round hxw and refresh rate

-rm probably is best in Windows, unless there's a way to override the mame integer thing with refresh rate.
-win makes the .ini files windows compliant, HxW@R instead of HxWxD@R like sdlmame reads. (unless your using SDL mame in Windows).
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: bitbytebit on October 25, 2010, 08:24:59 am
I've got a Radeon X850 http://en.wikipedia.org/wiki/File:PowerColor_Radeon_X850XT_PE.jpg (http://en.wikipedia.org/wiki/File:PowerColor_Radeon_X850XT_PE.jpg) that I found on ebay cheap coming to test, because that is the last version of GPU's Linux DRI /opengl/mesa support interrupts on.  So I'll see if it can use the waitforvsync option and have throttle off, and find out if it really works for tearing and refresh rate exactness as good as triple buffer does in Windows.  I've got my Windows XP install and have experienced it there now with Soft15Khz and triplebuffer.  Definitely interesting, and I'm using a Radeon HD 4350 I got a few days ago right now which is quite a nice card in both Linux and Windows compared to the ArcadeVGA3000.  I see it's the rv700 GPU and in Linux of course still doesn't do the interrupts for vsync but does seem to work a lot smoother in mode switching and general supported well in both Windows and Linux (ArcadeVGA card acted kind of funny for me in Windows, was surprised about that, just had a hard time dealing with it but this 4350 seemed nicer and of course worked better with Soft15khz opposed to my ArcadeVGA with bios flashed to be a normal Radeon HD 2600 card).

So basically I'm hoping this Radeon X850 can do the vsync stuff because it could be the best card in Linux if you want it all (and of course not wanting a super fast modern card, but want all the classic arcade and/or MAME/MESS to run in original resolutions without tearing).  They are on ebay for under 50 US dollars, so seem like a good choice for an arcade cabinet right now using Linux, at least while waiting for page flip support on the r600+ ATI GPU's.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: Calamity on October 25, 2010, 09:41:57 am
Definitely interesting, and I'm using a Radeon HD 4350 I got a few days ago right now which is quite a nice card in both Linux and Windows compared to the ArcadeVGA3000.

Great! The Radeon HD 4350 is the exact card I just wanted to focus development on. Though I haven't tested it yet, from Soft-15KHz thread it seems it's fully compatible with low resolutions (low dotclocks). I believe anything used there should also work for the more powerful 4650/4670, but 4350's price makes it a popular card, similar to the venerable 9250. Sailorsat says has that starting from 5000 series, Ati has discontinued all the good lowres capabilities, they may need a dongle as newer nVidia cards do. As VGA analog cards may disappear in the near future I believe the best approach is to focus on the last decent pci card suitable for lowres and lead people interested in serious emulation to get that card, instead of the somehow frustrating task of making a general tool for all cards.

It's also good news that X850 is supported by my hacked drivers, so we have the right tool to achive dynamic modelines for that card in Windows, however I havent tested that card for low dotclocks.

Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: Gray_Area on October 25, 2010, 02:58:52 pm
The X800 series is accessible via Soft15khz.

What rationale is there, or are the companies having, in locking out lowres capacity?
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: bitbytebit on October 25, 2010, 03:04:55 pm
The X800 series is accessible via Soft15khz.

What rationale is there, or are the companies having, in locking out lowres capacity?

I'm wondering if it's only a driver lockout and more of a miss sight on their part.  In Linux the Xorg developers have done the same thing in most of the drivers from just a lack of awareness of Arcade monitors and not sure of which chips can really do lower dotclocks.  I'd be interested in trying one of these new ATI things in Linux, they are getting the evergreen driver moving along in Linux because it's being pushed and developed by ATI people themselves, so ATI is behind it in Linux 100% now.  So since it's all open in Linux, we'd be able to fully see if it really can't do the lower dotclocks, or if they are just being like the Xorg developers and thinking of only flat panel HD TV output type stuff.  Seems the philosophy now is to avoid having the user be able to choose what kind of modelines to output to a monitor, and just have the monitor tell the user what it'll allow.  If the monitor doesn't say anything back, like an arcade monitor, then they default to basic VESA calculations and treat it like a normal computer monitor.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: bitbytebit on October 25, 2010, 08:39:42 pm
Version 0.14 - Working nicely in Windows with Soft15Khz or ArcadeVGA cards :)
* Now have a new arg called -resfile <file> which can be specified multiple times and takes either Soft15Khz files or the default ArcadeVGA.txt file (both included in ./extras/ now).  It will use the resolutions in the files to limit it's calculations to.  This basically is doing the same thing as those .ini files generators but it's dynamic and at runtime so you no longer have to maintain all the .ini files or worry about updating mame and redoing them.  This works well with Soft15Khz, using switchres.pl as a wrapper to mame and setting up a config file in C:\\etc\switchres.conf works pretty nicely now.
* Lots of little fixes with how switchres runs, and cleanup of how it calculates modelines with lrmc since the -resfile option required this.
* Tested on MameWah in Windows and it works well, avoids issues with games resolutions and mames decisions on picking them, it fixes that just like the .ini file fixes do (make sure you remove all your .ini files because they will override switchres.pl).  It's a pain to setup Mamewah, because you have to specify the Perl binary before the switchres.pl script (took me awhile to figure this out) but it does work once setup right.
* There were bugs with the -lrmc and -emulator args for passing commands to them separately, now those options should work correctly.
* Am noticing how it definitely is not great to have the refresh rate wrong with how Windows works, pacman sounds wrong, so you might want to add resolutions for those extra games in your Soft15Khz and this should be able to dynamically generate the right modelines quick.  Each run of switchres.pl will output the best modeline for your monitor, then the one it found in the current ones (resfile you gave it), unfortunately with an arcadeVGA card you can't do much about adding new ones.  If you have a monitor that can do 15-31.5 or more KHz like a d9800 then you really want to do this, else your missing a lot of better running games, I've gotten this working pretty nice in Linux and in Windows it just requires adding the modelines manually to your Soft15Khz usermodes file.
* Have emailed the guy at ATI that does the Linux driver development asking him about why the drivers don't support Arcade monitors in general and are lacking without hacking things in both Linux and Windows.  Also asked if the hardware is the limitation on the newer ATI cards or the driver has it limited, and if Linux drivers for it would be able to be hacked to overcome it (or if he would think of arcade monitors somewhat while developing those new evergreen Radeon 5XXX drivers).  Maybe he'll respond, here's a bunch of information on the code to run the newer ATI Radeons which gives  some insight on why they might have broken things, but possibly just short sightedness and not physical card/chip limitations: http://www.botchco.com/agd5f/ (http://www.botchco.com/agd5f/)
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: elvis on October 26, 2010, 06:26:34 am
After all this time I still haven't been able to get my Nvidia TNT2 card working with the Nouveau drivers.  I'm running Ubuntu 10.10 Maverick at the moment, and have tried nouveau drivers and drm/dri code from GIT in both a custom kernel and xorg drivers, and I still get the "Operation Not Permitted" error when trying to switch modelines via xrandr.

I thought maybe it was the low pclocks, but even trying to set standard VGA (640x480x32@60 with 12MHz pclock) it still throws the error.

I've switched over to an ATI Radeon 7000VE, and it works flawlessly.  I'm using xrandr from git with the patches in the GenRes zip, and I get the right modelines without a hitch.  I still need to use "opengl" with "waitvsync" to get it perfect with no-tearing, but that's fine by me.

So for now I'm going to stick with ATI hardware.  I'll keep this Nvidia TNT2 card around and continue testing every now and then.  I'm really not sure what is causing the error.  But for now an easily working ATI card trumps another weekend of me compiling nouveau drivers. :)
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on October 26, 2010, 07:03:19 am
After all this time I still haven't been able to get my Nvidia TNT2 card working with the Nouveau drivers.  I'm running Ubuntu 10.10 Maverick at the moment, and have tried nouveau drivers and drm/dri code from GIT in both a custom kernel and xorg drivers, and I still get the "Operation Not Permitted" error when trying to switch modelines via xrandr.

I thought maybe it was the low pclocks, but even trying to set standard VGA (640x480x32@60 with 12MHz pclock) it still throws the error.

I've switched over to an ATI Radeon 7000VE, and it works flawlessly.  I'm using xrandr from git with the patches in the GenRes zip, and I get the right modelines without a hitch.  I still need to use "opengl" with "waitvsync" to get it perfect with no-tearing, but that's fine by me.

So for now I'm going to stick with ATI hardware.  I'll keep this Nvidia TNT2 card around and continue testing every now and then.  I'm really not sure what is causing the error.  But for now an easily working ATI card trumps another weekend of me compiling nouveau drivers. :)

Sounds like we'll have to wait for the Nouveau drivers to settle down and become more stable till Nvidia cards can work with xrandr and vsync, I must have just gotten the right combination of code bases for it to work or it's my card version and somehow different supported in the driver (was an ancient QuadroFX 1400 or something).  I had got the current working snapshot and patched my kernel drm modules, which was a day old or something from the current working kernel tree they use and have linux 2.6.36.  Also got the xf86 driver for it from the git too, not sure if any of that makes a difference, but at least there's hope since it did work decently but I also had to go through all that though and do some odd tweaks here and  there too I think.  Oddly the vsync stuff didn't work though, might have been my card though because it's ancient and openGL stuff ran barely at all on it anyways.  I have this QuadroFX 3400 card in my workstation which might be slightly a few years more modern so maybe sooner or later I'll look into the Nvidia issues again.



Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: Calamity on October 26, 2010, 08:40:21 am
Version 0.14 - Working nicely in Windows with Soft15Khz or ArcadeVGA cards :)
* Now have a new arg called -resfile <file> which can be specified multiple times and takes either Soft15Khz files or the default ArcadeVGA.txt file (both included in ./extras/ now).  It will use the resolutions in the files to limit it's calculations to.  This basically is doing the same thing as those .ini files generators but it's dynamic and at runtime so you no longer have to maintain all the .ini files or worry about updating mame and redoing them.  This works well with Soft15Khz, using switchres.pl as a wrapper to mame and setting up a config file in C:\\etc\switchres.conf works pretty nicely now.

This may sound like silly question, forgive me... but how are you running your scripts in Windows? I tried with activeperl as you proposed but it complained about semicolons and other stuff, probably my fault, so I gave up.

If I understood properly, you're not doing dynamic modelines in Windows, but choosing from available modes to get rid of inis, isn't it?
[Edit] I've read your doc, it's answered there!
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: bitbytebit on October 26, 2010, 08:47:00 am
Version 0.14 - Working nicely in Windows with Soft15Khz or ArcadeVGA cards :)
* Now have a new arg called -resfile <file> which can be specified multiple times and takes either Soft15Khz files or the default ArcadeVGA.txt file (both included in ./extras/ now).  It will use the resolutions in the files to limit it's calculations to.  This basically is doing the same thing as those .ini files generators but it's dynamic and at runtime so you no longer have to maintain all the .ini files or worry about updating mame and redoing them.  This works well with Soft15Khz, using switchres.pl as a wrapper to mame and setting up a config file in C:\\etc\switchres.conf works pretty nicely now.

This may sound like silly question, forgive me... but how are you running your scripts in Windows? I tried with activeperl as you proposed but it complained about semicolons and other stuff, probably my fault, so I gave up.

If I understood properly, you're not doing dynamic modelines in Windows, but choosing from available modes to get rid of inis, isn't it?

Ah, you have to rename it to switchres.pl, most likely the case I'm suspecting.  Active perl wont see it otherwise, unless when you installed it you didn't allow it to add the path and extension stuff.

Yeah, basically it does the exact same thing now as the .ini generators do in Windows except it's dynamic.  I just added support to have it write out and keep a modelines database file, just a file that should be able to have soft15Khz use as the usermodes file.  So you can run it for a while, then go back and add those modes, and then add that file into your set of predefined modelines.  Would somewhat work but of course I do see how in Windows everything is called 60Hz refresh and looks like it doesn't even know how to pick resolutions based on refresh rates in the direct3d/draw layers.  At least from what I can tell, that area is basically the part that is open to having the ability to utilize the modeline we are generating somehow dynamically, else it'll have to be statically added and then again I'm guessing it still has the original refresh rate ambiguity that we had in Linux without using xrandr.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: Calamity on October 26, 2010, 11:33:30 am
Quote
Yeah, basically it does the exact same thing now as the .ini generators do in Windows except it's dynamic.  I just added support to have it write out and keep a modelines database file, just a file that should be able to have soft15Khz use as the usermodes file.  So you can run it for a while, then go back and add those modes, and then add that file into your set of predefined modelines.  Would somewhat work but of course I do see how in Windows everything is called 60Hz refresh and looks like it doesn't even know how to pick resolutions based on refresh rates in the direct3d/draw layers.  At least from what I can tell, that area is basically the part that is open to having the ability to utilize the modeline we are generating somehow dynamically, else it'll have to be statically added and then again I'm guessing it still has the original refresh rate ambiguity that we had in Linux without using xrandr.

I'll give another try to Active perl, but I believe it was reading the files as it complained that the lines didn't end with semicolons.

For some reason, ArcadeVGA modelines are labeled as 60 Hz, which can be misleading, but that's not the rule. You can perfectly define a modeline labeled 320x224@57 and invoke it from Mame using those values, as long as you keep vfreq value as integer (that's what limits the precision for naming modes and leads us to xres incrementing tricks). You can have a second modeline labeled 320x224@58 and they won't get mixed up. The important thing here is that the driver cannot know the real refresh of the mode (it doesn't take the time to calculate it out of modeline data), but trusts on the label we assign to it, so when we request 320x224@57 it will check its table and return the correct modeline, even if the actual refresh defined by the modeline is 57.00, 57.55 or 120.00 Hz.

This is for a fixed modeline table. However, it's possible to achieve real dynamic modeline functionallity, at least with ATI cards supported by the discontinued Catalyst 6.11 (= Catalyst 6.5, the one I hacked for 200 modes), using the trick I mentioned some posts above. I wonder if it'll be possible to do a similar thing with current Catalyst, in order to extend this to newer ATI cards.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: bitbytebit on October 26, 2010, 11:46:32 am
Quote
Yeah, basically it does the exact same thing now as the .ini generators do in Windows except it's dynamic.  I just added support to have it write out and keep a modelines database file, just a file that should be able to have soft15Khz use as the usermodes file.  So you can run it for a while, then go back and add those modes, and then add that file into your set of predefined modelines.  Would somewhat work but of course I do see how in Windows everything is called 60Hz refresh and looks like it doesn't even know how to pick resolutions based on refresh rates in the direct3d/draw layers.  At least from what I can tell, that area is basically the part that is open to having the ability to utilize the modeline we are generating somehow dynamically, else it'll have to be statically added and then again I'm guessing it still has the original refresh rate ambiguity that we had in Linux without using xrandr.

I'll give another try to Active perl, but I believe it was reading the files as it complained that the lines didn't end with semicolons.

For some reason, ArcadeVGA modelines are labeled as 60 Hz, which can be misleading, but that's not the rule. You can perfectly define a modeline labeled 320x224@57 and invoke it from Mame using those values, as long as you keep vfreq value as integer (that's what limits the precision for naming modes and leads us to xres incrementing tricks). You can have a second modeline labeled 320x224@58 and they won't get mixed up. The important thing here is that the driver cannot know the real refresh of the mode (it doesn't take the time to calculate it out of modeline data), but trusts on the label we assign to it, so when we request 320x224@57 it will check its table and return the correct modeline, even if the actual refresh defined by the modeline is 57.00, 57.55 or 120.00 Hz.

This is for a fixed modeline table. However, it's possible to achieve real dynamic modeline functionallity, at least with ATI cards supported by the discontinued Catalyst 6.11 (= Catalyst 6.5, the one I hacked for 200 modes), using the trick I mentioned some posts above. I wonder if it'll be possible to do a similar thing with current Catalyst, in order to extend this to newer ATI cards.


Is it genres, that won't work cause it's a shell script, would make sense if it's giving the issue.  Only switchres will work in Windows, since genres really just wraps around lrmc giving it the ability to also create an xorg.conf file too.

Ah, interesting, I'll have to look at that closer, just running some games last night noticed that (although I know the modeline was running the in the right Vert Hz to the monitor from my monitor osd/display, can check them with that).  I was using Soft15Khz and just saw that when running mame in verbose mode it calls everything 60Hz it seems when checking the different resolutions and weighting them.  I was just surprised how much different pacman is at 50Hz compared to 60.61, and that seems to be what your forced at currently by an ArcadeVGA card if you want a 288 line height in Windows.

On a side note I tried out this Radeon HD 4870 I had laying around just now, since it's a large card and wanted to see for sure if the RV770 did low res and how it liked the N64 Emulator.  It does do low res, and definitely likes the N64 emulator too.  I'm guessing the big gigantic size of this 4870 compared to the 4350 really does nothing for MAME though, not sure if just general video display would be any better on it compared to the other radeon.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: Calamity on October 26, 2010, 12:48:33 pm
Is it genres, that won't work cause it's a shell script, would make sense if it's giving the issue.  Only switchres will work in Windows, since genres really just wraps around lrmc giving it the ability to also create an xorg.conf file too.

Ok, that was it, it'll try switchres either.

I was just surprised how much different pacman is at 50Hz compared to 60.61, and that seems to be what your forced at currently by an ArcadeVGA card if you want a 288 line height in Windows.

If I force my monitor (lowres) to 16,7 KHz (no problem) I can get 288 progresive lines at 54 Hz, still not 60, but closer. Here is were it is important to have that 'soundsync' option from CabMame, so you can reduce game speed adjusting sound at the same time, and still have a progressive full frame. If 'soundsync' is not an option, you need to get the real 60.61 Hz to keep sound synced, which can be achieved either by chopping the frame by some lines (I hate this solution) or by interlacing + stretching (my preferred) where you can produce any refresh needed. I like to optimize the later method by choosing the tallest possible interlaced resolution for the given vertical refresh, as it provides better quality with less flicker where it is possible.

On a side note I tried out this Radeon HD 4870 I had laying around just now, since it's a large card and wanted to see for sure if the RV770 did low res and how it liked the N64 Emulator.  It does do low res, and definitely likes the N64 emulator too.  I'm guessing the big gigantic size of this 4870 compared to the 4350 really does nothing for MAME though, not sure if just general video display would be any better on it compared to the other radeon.

Good to know. I'm now doubting among 4350 and 4650 as I've seen the last one at 35 €.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .13)
Post by: bitbytebit on October 26, 2010, 12:57:54 pm
Is it genres, that won't work cause it's a shell script, would make sense if it's giving the issue.  Only switchres will work in Windows, since genres really just wraps around lrmc giving it the ability to also create an xorg.conf file too.

Ok, that was it, it'll try switchres either.

I was just surprised how much different pacman is at 50Hz compared to 60.61, and that seems to be what your forced at currently by an ArcadeVGA card if you want a 288 line height in Windows.

If I force my monitor (lowres) to 16,7 KHz (no problem) I can get 288 progresive lines at 54 Hz, still not 60, but closer. Here is were it is important to have that 'soundsync' option from CabMame, so you can reduce game speed adjusting sound at the same time, and still have a progressive full frame. If 'soundsync' is not an option, you need to get the real 60.61 Hz to keep sound synced, which can be achieved either by chopping the frame by some lines (I hate this solution) or by interlacing + stretching (my preferred) where you can produce any refresh needed. I like to optimize the later method by choosing the tallest possible interlaced resolution for the given vertical refresh, as it provides better quality with less flicker where it is possible.

On a side note I tried out this Radeon HD 4870 I had laying around just now, since it's a large card and wanted to see for sure if the RV770 did low res and how it liked the N64 Emulator.  It does do low res, and definitely likes the N64 emulator too.  I'm guessing the big gigantic size of this 4870 compared to the 4350 really does nothing for MAME though, not sure if just general video display would be any better on it compared to the other radeon.

Good to know. I'm now doubting among 4350 and 4650 as I've seen the last one at 35 €.


Yeah I was using cabmame with the soundsync and all on, basically the defaults it does with those.  I mean it worked, but I could tell and especially now that I've been playing it at 60.61 in Linux it is very noticable when you jump back and forth. 

Also that 4870 seems to have killed my Windows install, now it gets the c:\\windows\system32\config\system file is missing message and unfortunately it's a dual boot through grub to Linux or Windows and I installed on another system with my systems install disks (which don't boot and repair, and even then I suspect it may break my grub install on the root partition).  So that's great, I may have to wiggle the disk out of there and do the repair or reinstall on another system, wow Windows is annoying :).  At least it did the job of getting switchres basically working there, but I did have mamewah setup pretty nice last night finally and all working great so it definitely sucks that somehow the 4870 blew up the install.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on October 26, 2010, 03:03:56 pm
Note about the xorg-server patch, this is definitely needed.  I just tried the xorg-server unpatched to check and see, those default modes (especially the 320x240 one) are evil and won't let you even create one with xrandr to try and override it with.  So looks like for now, the xorg server must be patched with the patch I have and recompiled/installed.  The issues with that are the fact that you must make sure it's the same version you have installed, you have to make sure to use the right configure args which are "./configure --prefix=/usr --enable-record --enable-multibuffer --sysconfdir=/etc --localstatedir=/var", and you need to chmod 711 /usr/bin/Xorg;chmod u+s /usr/bin/Xorg after install else it won't be setuid root and allow a user to use it.

Definitely not the best thing to have people doing, but for some reason the X server adds those modes without a way to blacklist or override them and it even ignores the specified vert/horz freq limits in adding them.  It's sad but possibly the best approach eventually would be to have a complete X windows build/system for people to install to run on arcade monitors.  At least they wouldn't have to find/patch/configure/compile/install all the components and just run a script building it all for them instead.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: Calamity on October 26, 2010, 04:40:32 pm
Definitely not the best thing to have people doing, but for some reason the X server adds those modes without a way to blacklist or override them and it even ignores the specified vert/horz freq limits in adding them.  It's sad but possibly the best approach eventually would be to have a complete X windows build/system for people to install to run on arcade monitors.  At least they wouldn't have to find/patch/configure/compile/install all the components and just run a script building it all for them instead.

With all available software blocking natural hardware features it's become a difficult task to do modelines for the masses, however all the work and discoveries in this post seem very promising. Perhaps it would be nice to have a distribution or even a live cd with all the patches and good stuff so people without Linux background like me could dare to use and test it. VeS, the folk who posted some pages before and who pointed me to this thread, was working on a live cd for arcade monitors in the Spanish forum, then we stumbled upon those problems without knowing what was going on, it's great you've clarified all this. It seems probable the vsync issue will be figured out and all this put together will make a perfect platform for emulation, as I'm convinced Linux should run smoother than Windows.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on October 26, 2010, 05:03:38 pm
Definitely not the best thing to have people doing, but for some reason the X server adds those modes without a way to blacklist or override them and it even ignores the specified vert/horz freq limits in adding them.  It's sad but possibly the best approach eventually would be to have a complete X windows build/system for people to install to run on arcade monitors.  At least they wouldn't have to find/patch/configure/compile/install all the components and just run a script building it all for them instead.

With all available software blocking natural hardware features it's become a difficult task to do modelines for the masses, however all the work and discoveries in this post seem very promising. Perhaps it would be nice to have a distribution or even a live cd with all the patches and good stuff so people without Linux background like me could dare to use and test it. VeS, the folk who posted some pages before and who pointed me to this thread, was working on a live cd for arcade monitors in the Spanish forum, then we stumbled upon those problems without knowing what was going on, it's great you've clarified all this. It seems probable the vsync issue will be figured out and all this put together will make a perfect platform for emulation, as I'm convinced Linux should run smoother than Windows.


I think the vsync stuff is right around the corner, have been watching these patches from the Alex Deucher guy and every day they are updated (he's employeed by ATI to develop the Linux open source drivers for the Linux drm part of the kernel and xf86-ati driver).  So looks hopeful, I'm guessing he's doing this for the next 2.6.37 version most likely, adding the page flipping interrupt vsync support to the kernels drm layer for kernel mode switching...

http://people.freedesktop.org/~agd5f/pflip/ (http://people.freedesktop.org/~agd5f/pflip/)

I've emailed him, he emailed back about how most likely it's the drivers for the newer ATI cards in Windows and could always try in Linux and confirm that.  May be awhile before I get one of those cards, no need and definitely not going to risk it to just see if it works.  So maybe someone out there eventually will try switchres on one and report back.  I emailed back about these limitations of modelines and default resolutions not being able to get blacklisted.  Also he said it'd be best to have a reserved set of pll settings for when a mode was given with lower dotclocks instead of just making the minimum lower like we currently do, that would be something he'd think of as the proper fix in the drivers.  Not sure if he's planning on doing something like that or will let me know generally what would be needed to do that, also interesting if there's better general tuning of other things for the pll settings to get the resolutions to work better for arcade monitors (since he seems to be saying they are tuned currently for high end monitors, and probably in the newest cards are so over tuned that now they totally broke low res monitors support).  Tuning them for low res monitors might just be an amazing thing instead of just hacking the dotclocks. 

Building a set of sources or a set of patches and scripts that download the current sources for X windows, drm, mesa sdl, mame and any other misc needed parts, patch them and install.  That would be interesting since it'd be light weight being just patches and a script to run and it'd fetch it all and patch/install it.  I might try to setup something like that to make it a quick process, and avoid having to deal with all the varieties of Linux systems and instead override the Windowing system by creating our own (and probably put it in a separate path so it doesn't harm the current system, but just an alternative one to run).
 
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on October 27, 2010, 03:00:26 pm
Some interesting updates, definitely getting interesting, I've been talking with the ATI Radeon driver guy for the Linux open source stuff. 

First I've figured out through his help that the xorg modeline stuff does work but you have to avoid using any Modes configuration in the Screen section of the config.  Those will write hardwired modes you will not be able to override with your custom modelines, and in fact work against you by making duplicate modes but with 60Hz refresh rates.  Basically the xserver does add our custom modes but when we add them in the screens section the driver takes those names and gets HxW and creates a CVT modeline using 60Hz. 

So you don't have to recompile the ATI driver, besides the lower dotclock limit of course to make it allow less than 12Mhz.  Yet the PLL clock setup of course involved in that is needing to be tuned for lower resolutions with arcade monitors, same in the DRM layer with Kernel Mode Switching in newer kernels/ATI drivers if enabled.  More on that in a bit.

Second the xserver may have a bug, where the default modes it creates, some of which don't conform to our Vert/Horz freq range values.  These can't be overridden by xrandr at the moment because they are unwritable, and it seems like a bug.  So that is the main reason the xserver needs my patch right now to remove the adding of those default modelines.

Third I'm working on a script that basically will get all the stuff needed to build an Xorg server/driver system with OpenGL and DRI/DRM all correctly setup and will patch the sources with changes we have to make for arcade monitors (at least until they are actually applied to the X stuff officially).  My goal is to try and get the actual Xorg/DRM/Linux kernel all adapted to arcade monitors so it works in all distributions by default. 

That is the interesting part, I installed the newest Ubuntu 10.10 to test since it uses all the newest Xorg and DRM stuff.  It actually seems to do the Vsync stuff correctly, which is a plus.  The minus is that it has issues with of course the PLL Clock values and some oddity with mame not being able to switch to the new modes (I can use xrandr to do it) and so it isn't centered.  That part is probably minor through configuration or maybe some patching to allow it to work right.  It was all unpatched just using the distribution packages, including the mame version, I'm going to try and make this custom build thing be able to work there and find out more that way so it would be easy to have others do to through the script (not have to distribute big distros since just a script and people run it to build the distro themselves, which really is just a separate tree for the Xorg stuff and anything else necessary).

So there's a flicker every so often of the monitor in Ubuntu even with a good arcade modeline that works fine in my normal Gentoo setup.  Ubuntu is using the KMS code in the Linux kernel instead of UMS, which I'm guessing is the difference.  Alex Deucher (Radeon driver guy) says that this very likely is the PLL clock dividers and to try the older ones, see if that fixes it.  So this brings back an interesting thing about how we've always hacked these drivers to use a lower min_clock value and that is all we have done.  We have never tuned the PLL clock dividers to actually be optimized for arcade monitors.  This sounds like something that could make Linux be the only way to actually output the best possible signal to arcade monitors and something we could never do under Windows (unless we hacked the driver/firmware bios I guess). 

Another interesting thing about Xorg setup, in your monitor section you really need to make the identifier the name of your card output, like DVI-0 or VGA-0 etc.  It doesn't know how to really link the monitor section to the card output very well, usually just picks the first one per monitor section as it reads them.  This may be another reason why modelines often don't apply properly, you have to setup the xorg.conf file just right for your monitor/card names and ordering.

Here's my xorg.conf which can load the custom modelines without my patches, and seems like the proper way to set it up...
Code: [Select]
Section "Monitor"
        Identifier   "DVI-0"
        VendorName   "Wells Gardner"
        ModelName    "D9800"

        Option "DPMS"           "false"

        Option "MinClock"       "1Mhz"
        Option "MaxClock"       "90Mhz"

        HorizSync    15.25-38.00
        VertRefresh  47.00-75.00

        Option         "Primary"    "True"

        Option      "PreferredMode" "640x480x60.10"
        UseModes "ArcadeModes"
EndSection

Section "Monitor"
        Identifier   "VGA-0"
        VendorName   "Lilo"
        ModelName    "Lilo"

        HorizSync    15.25-38.00
        VertRefresh  47.00-75.00

        Option       "RightOf" "DVI-0"
        Option       "Primary"    "False"

        Option      "PreferredMode" "640x480x60.10"
        UseModes     "ArcadeModes"
EndSection

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

        #Option      "ArcadeMonitor"  "d9800"
        Option      "EXAVSync"       "yes"
        Option      "EnablePageFlip" "on"

        Option      "ModeDebug"      "true"
        Option      "NoDDC"
        Option      "IgnoreEDID"     "on"

        Option      "ForceMinDotClock"    "3Mhz"

        #assigns the output DVI-I-0 to Monitor0
        Option      "monitor-DVI-0" "DVI-0"
        #assigns the output DVI-I-1 to Monitor1
        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
                Virtual 1280 480
        EndSubSection
EndSection

Section "Modes"
        Identifier "ArcadeModes"

        Modeline "640x480x60.10"  25.240385  640 656 752 800  480 490 494 525  -HSync -VSync
EndSection

 
Also I've gotten switchres to build the modelines file and will release a version with that capability so in Windows you can have it write out a Soft15Khz custom modelines file as you play games, and apply/reboot and you'll slowly build more modelines that match the games you want to be more exact (probably need to trim/edit of course if limited to certain numbers of modelines).

This X Windows build is looking interesting, I'm still getting the base Xorg and all friends with DRM/Mesa to compile then I'll look into possibly SDL/Mame and perhaps a Linux kernel. Maybe it'll just be a simple small distro that really is just the bare bones X server and stuff needed to run mame, dynamically downloaded patched and built.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on October 28, 2010, 12:49:29 am
I figured out how to get the vsync stuff working now, and can run without any tearing at the screen refresh rate.  I had to first off use an ubuntu 2.6.35 kernel that seems to have patches that fix KMS to allow the radeon to work.  I also had to change the radeon DRM code in it to do lower dotclocks and default to 640x480 instead of 1024x768, so the framebuffer actually works on the monitor.  You also have to have a special firmware file too that isn't in my Gentoo dist.  I got my download/patch/compile script working and can build a good working X windows system from GIT that has openGL/Mesa and is independent from the system so it runs in a separate directory from /usr/ by just adding the new bin location to your path.  X Windows has compile variables that allow it to do that and keep within a separate tree basically.  This all works really well, and there's only one issue or two.  First the DRM code constantly checks for EDID when it doesn't exist, and that causes the flicker I saw on the monitor at a regular interval.  I am figuring I just need to fix that but also have notified the Radeon driver guy about it and expect he'll realize the issue and fix in in the main DRM linux kernel tree.  Also of course we still have the xserver being forceful about default modes (mainly makes a 320x480 one we can't override), and hopefully he also helps me overcome that (or I'll figure out how to make it allow overwriting those default modes or just remove the adding of them again in my new build tree).

So that is something to look forward to, will hopefully in a few days have a bash script that you can run and it'll download/patch/install a whole working X windows and Linux kernel separate from the main system (will need to of course boot into the new kernel version), which work with Radeon cards with modesetting and vsync ability through openGL. 
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: elvis on October 28, 2010, 03:24:44 am
So that is something to look forward to, will hopefully in a few days have a bash script that you can run and it'll download/patch/install a whole working X windows and Linux kernel separate from the main system (will need to of course boot into the new kernel version), which work with Radeon cards with modesetting and vsync ability through openGL. 
That sounds great.  I'll definitely be giving that a go when it's done.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: Calamity on October 28, 2010, 04:46:32 am
I figured out how to get the vsync stuff working now, and can run without any tearing at the screen refresh rate.  I had to first off use an ubuntu 2.6.35 kernel that seems to have patches that fix KMS to allow the radeon to work.  I also had to change the radeon DRM code in it to do lower dotclocks and default to 640x480 instead of 1024x768, so the framebuffer actually works on the monitor.  You also have to have a special firmware file too that isn't in my Gentoo dist.  I got my download/patch/compile script working and can build a good working X windows system from GIT that has openGL/Mesa and is independent from the system so it runs in a separate directory from /usr/ by just adding the new bin location to your path.  X Windows has compile variables that allow it to do that and keep within a separate tree basically.  This all works really well, and there's only one issue or two.  First the DRM code constantly checks for EDID when it doesn't exist, and that causes the flicker I saw on the monitor at a regular interval.  I am figuring I just need to fix that but also have notified the Radeon driver guy about it and expect he'll realize the issue and fix in in the main DRM linux kernel tree.  Also of course we still have the xserver being forceful about default modes (mainly makes a 320x480 one we can't override), and hopefully he also helps me overcome that (or I'll figure out how to make it allow overwriting those default modes or just remove the adding of them again in my new build tree).

So that is something to look forward to, will hopefully in a few days have a bash script that you can run and it'll download/patch/install a whole working X windows and Linux kernel separate from the main system (will need to of course boot into the new kernel version), which work with Radeon cards with modesetting and vsync ability through openGL.  

That's fantastic!

I've been reading a bit about these PLL dividers. It would be great to have a look at the code that translates the dotclock parameter of the modeline into these dividers. This is hidden for me in Windows, where the dotclock param is also an integer measured in MHz, so there's a resulting granularity in the precision of real dotclocks you can obtain, that also applies to resulting vfreq. If you have a look at Powerstrip there's an option named "ultrafine granularity" that might be achieved by direct tuning of these dividers.

EDIT: This also makes me wonder if those cards that had problems supporting very low resolutions, via Soft-15Khz, etc., were really limited by its hardware or by drivers.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: Quinny on October 28, 2010, 09:45:00 am
So that is something to look forward to, will hopefully in a few days have a bash script that you can run and it'll download/patch/install a whole working X windows and Linux kernel separate from the main system (will need to of course boot into the new kernel version), which work with Radeon cards with modesetting and vsync ability through openGL. 

Does this include the ArcadeVGA cards?
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on October 28, 2010, 10:37:16 am
So that is something to look forward to, will hopefully in a few days have a bash script that you can run and it'll download/patch/install a whole working X windows and Linux kernel separate from the main system (will need to of course boot into the new kernel version), which work with Radeon cards with modesetting and vsync ability through openGL. 

Does this include the ArcadeVGA cards?


It should, there is one issue with the BIOS label on those cards that hopefully is fixed in the newer version of the kernel I'm using, because they don't have a recognized ATI signature.  It's something that in the kernel source is easy to comment out though and bypass the check, or for the brave backing up then flashing the BIOS with an HD 2600 cards also would make it a normal recognized ATI card in the kernel.  I'll have to play around with mine and see for sure after I get things stable. 

It's interesting, the newest Linux kernel straight from the Linus tree just had the fix for the flickering issue, because they were polling the card constantly and since no EDID it was irritating it and constantly doing an intrusive check.  So that was great they just figured that one out, and of course was the main issue I saw, also the crashes in KMS mode are fixed it seems that I had saw with anything earlier besides the Ubuntu kernel (which must have the patches that went into the newest Linus kernel tree since 2.6.36 was out).

So it's all on the edge it seems, they just now are getting these cards to work decent at all with real support for the vsync ability and modeswitching.  Hopefully the couple issues I'm seeing work out with my mame 140 compile directly linking into the separate tree with the alternate versions of everything.  I realized I most likely need mame to really link into the separate libraries or else seems the openGL stuff on a couple games won't display, oddly  the ones with the extra low resolutions.  It's quite an interesting thing to get everything separated out, basically DRM/OpenGL/X/SDL/Mame are all in a /GA/ root directory and just have to set my PATH environment to include that /GA/bin before any other paths.  Pretty much should avoid a persons distribution limitations, as long as  a modern/new version, should be able to pick the distro and run this script and wait for the big download/compile cycle and hopefully does all the patching automatically so they don't have to think about it. 


Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on October 28, 2010, 10:40:23 am
I figured out how to get the vsync stuff working now, and can run without any tearing at the screen refresh rate.  I had to first off use an ubuntu 2.6.35 kernel that seems to have patches that fix KMS to allow the radeon to work.  I also had to change the radeon DRM code in it to do lower dotclocks and default to 640x480 instead of 1024x768, so the framebuffer actually works on the monitor.  You also have to have a special firmware file too that isn't in my Gentoo dist.  I got my download/patch/compile script working and can build a good working X windows system from GIT that has openGL/Mesa and is independent from the system so it runs in a separate directory from /usr/ by just adding the new bin location to your path.  X Windows has compile variables that allow it to do that and keep within a separate tree basically.  This all works really well, and there's only one issue or two.  First the DRM code constantly checks for EDID when it doesn't exist, and that causes the flicker I saw on the monitor at a regular interval.  I am figuring I just need to fix that but also have notified the Radeon driver guy about it and expect he'll realize the issue and fix in in the main DRM linux kernel tree.  Also of course we still have the xserver being forceful about default modes (mainly makes a 320x480 one we can't override), and hopefully he also helps me overcome that (or I'll figure out how to make it allow overwriting those default modes or just remove the adding of them again in my new build tree).

So that is something to look forward to, will hopefully in a few days have a bash script that you can run and it'll download/patch/install a whole working X windows and Linux kernel separate from the main system (will need to of course boot into the new kernel version), which work with Radeon cards with modesetting and vsync ability through openGL.  

That's fantastic!

I've been reading a bit about these PLL dividers. It would be great to have a look at the code that translates the dotclock parameter of the modeline into these dividers. This is hidden for me in Windows, where the dotclock param is also an integer measured in MHz, so there's a resulting granularity in the precision of real dotclocks you can obtain, that also applies to resulting vfreq. If you have a look at Powerstrip there's an option named "ultrafine granularity" that might be achieved by direct tuning of these dividers.

EDIT: This also makes me wonder if those cards that had problems supporting very low resolutions, via Soft-15Khz, etc., were really limited by its hardware or by drivers.


Here's where they do that magic at...

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm/radeon;hb=c3cceeddf0b5f97b0d2352b98ef0f025e31a9ae3 (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm/radeon;hb=c3cceeddf0b5f97b0d2352b98ef0f025e31a9ae3)

I think this file may be the most important with the clock stuff :)
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/gpu/drm/radeon/radeon_clocks.c;h=5249af8931e60549e01362102f9c8ca941ba0d24;hb=c3cceeddf0b5f97b0d2352b98ef0f025e31a9ae3 (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/gpu/drm/radeon/radeon_clocks.c;h=5249af8931e60549e01362102f9c8ca941ba0d24;hb=c3cceeddf0b5f97b0d2352b98ef0f025e31a9ae3)
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: lodoss118 on October 28, 2010, 01:13:24 pm
Hi i have a geforce gtx 460 and was wondering if this would work on windows or do i have to use linux? I also have this monitor
http://www.giz10p.co.uk/index.php?_a=viewProd&productId=309 (http://www.giz10p.co.uk/index.php?_a=viewProd&productId=309) tri sync auto switching monitor.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on October 28, 2010, 01:19:08 pm
Hi i have a geforce gtx 460 and was wondering if this would work on windows or do i have to use linux? I also have this monitor
http://www.giz10p.co.uk/index.php?_a=viewProd&productId=309 (http://www.giz10p.co.uk/index.php?_a=viewProd&productId=309) tri sync auto switching monitor.

It depends if that card works with Soft15Khz

If you use Soft15Khz, have that setup, then you can use the switchres perl script to run the games and it can basically do the .ini stuff but using the command line instead.  Also it'll show the modelines using lrmc that would be more optimal for the game your loading with it.  Those can be then put back into Soft15Khz as usermodes and then it'll utilize those resolutions next time it runs the game after a reboot (needs a reboot to add new modelines in Windows). 

The next version will have switchres write out a file of the modelines it generates each time you run a game and that will make it easier to create the usermodes file for Soft15Khz.  I'm going to probably post it sometime today for those added features, the things I'm working on probably wont be ready in the next day or two so might as well post what I have so far. 
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on October 28, 2010, 01:49:37 pm
Version 0.15 -
*  Added ability to write out modelines used into a file called modes.txt by default, useful with Soft15Khz and creating a usermodes file
*  new single mame patch for mame 0140 which combines everything and the hiscore patch so you don't have to get that extra now
*  new xf86-ati driver patch which just changes the lowest dotclock value allowed (doesn't even matter if using KMS in the Linux kernel DRM stuff
*  new way of creating the xorg.conf file, new example too, which will allow modelines to work right in the driver, avoid using the Modes line in the Screen section at all cost!!!
*  Don't use the stuff in the GroovyArcade folder, that is the script which is still in development for downloading/building an entire X Windows plus mame system, that will no longer have the tearing issues and work best with switchres.  The patches though are interesting in that directory, but somewhat duplicates of the normal patches directory.
* various bug fixes in switchres.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on November 01, 2010, 05:31:40 pm
Version 0.16 is up now, see info on first post on changes. 

I have been working on building the kernel/X windows system in Linux to be able to get perfect vsync and resolutions with the newer KMS mode for Radeon cards.  This basically allows the kernel to fully control the Radeon through the Atom bios and we get proper vsync through that.  I have finally gotten a build of X Windows and Linux where I can both change resolutions with xrandr almost flawless to exact Vertical Refresh rates and have mame properly run with nothrottle driven by the refresh rate of the monitor.  This is a slightly complex process and has taken me a week of digging around compiling X/Linux and patching Linux plus the newest Linux kernel just got this working right with KMS too (straight from the Linus tree).  Fortunately there's a modular package you get with GIT and it does all the X Windows building work for us (you will need to patch xrandr only).  Then you can run my new GA.sh script with the right args to download and install SDL/DirectFB/Mame on top of the new X Windows/OpenGL system.  There's stuff I had to change in the Linux kernel to get it working nicer with arcade monitors, mainly the minimum dotclock.  Also there's now a real framebuffer for newer Radeon cards from all this, and you can kind of force it to be arcade monitor compliant (includes a radeon.conf file with the module options to try and do that, it might work and get a 640x480@60 interlaced picture on the console.

The main one issue, which seems to be a bug in the xserver, are those default modelines it will make.  Mainly the 320x240 one it does just spoils the fun when a game needs that mode, just like how in Windows that was/is an issue on certain cards.  It's a bug since it should allow us to overwrite that modeline, but it doesn't right now and so my X Server patch could be used for now until I find a way to fix that correctly in the X Server and hopefully get them to include that change. 

I can also confirm that the X850 Radeon cards, at least the crossfire ones, do not work well at all in Linux.  Barely works and can't get a console, only X Windows and then mame crashes for some odd reason with a segfault trying to use OpenGL on it.  Also the ArcadeVGA 3000 card when actually allowed to load the KMS stuff onto it, has terrible weird output and programming modes with KMS mode in Linux.  I think the BIOS changes are fully incompatible with normal Radeon ATI ATOM Bios setup, and so in Linux the normal Radeon driver when actually using the Atom bios just doesn't know how to setup the cards chips.  It seems to think both outputs are digital ones, and the first always has a weird output barely legible and then the digital one is way out of range of what it should be.  Basically it seems the cards being programmed totally wrong and the horizontal/vertical refresh values are not even close to what they should be for some reason. 

So if you have an ArcadeVGA it will not work in Linux when you want to go into the newest current stuff utilizing the Radeon bios and interrupts from the card, you will need to probably flash your bios and make it a normal ATI Radeon HD 2600 first.  This all works really well though on the HD 4870 card, which is what I am using, and any chipset most likely below that besides those odd X800 type cards I'm guessing. If someone had a newer radeon and tested this, it could confirm if those cards really can't do lower dotclocks or if it's just the Windows drivers blocking it. 
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: Calamity on November 02, 2010, 06:37:25 pm
Hi bitbytebit,

You've done a great achievement. I can get a slight idea of how difficult this must have been. I think it's going to be important in the next years (before vga says goodbye) to have a solid platform for emulation that supports arcade monitors, and benefit from the last cards capable of low resolutions (it seems it's all over since HD5000), and this Linux solution looks perfect for that. I'm eager to get my hands on it.

I wonder if it will work with older Radeon (before Atom bios), i.e. the popular Radeon 9250. On the default resolutions issue, are they actually produced by the xserver? In Windows, it's the driver the one that provides the system with all the modes, and the 320x240 issue really happens when a 320x or 400x resolution is invoked, because Catalyst driver is hardcoded to activate doublescan with those resolutions (it's not DirectX's fault as I read somewhere). I believe doublescan support through custom modes does not work properly with Catalyst, and it might be related with that. Anyway, Catalyst can be patched to avoid that behaviour, restoring the normal use of 320x and 400x modes without the 321 trick. Besides that, we also have the issue with default modes (31 KHz) added by the driver at a variety of resolutions, that need to be restricted.

Thanks for the good work, again!
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: lodoss118 on November 02, 2010, 07:16:51 pm
i have ati 4850 and was wondering what is the best linux flavour to use, something that loades fast and how easy is it to install thispackage i am not a linux user?
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on November 03, 2010, 11:46:17 am
Hi bitbytebit,

You've done a great achievement. I can get a slight idea of how difficult this must have been. I think it's going to be important in the next years (before vga says goodbye) to have a solid platform for emulation that supports arcade monitors, and benefit from the last cards capable of low resolutions (it seems it's all over since HD5000), and this Linux solution looks perfect for that. I'm eager to get my hands on it.

I wonder if it will work with older Radeon (before Atom bios), i.e. the popular Radeon 9250. On the default resolutions issue, are they actually produced by the xserver? In Windows, it's the driver the one that provides the system with all the modes, and the 320x240 issue really happens when a 320x or 400x resolution is invoked, because Catalyst driver is hardcoded to activate doublescan with those resolutions (it's not DirectX's fault as I read somewhere). I believe doublescan support through custom modes does not work properly with Catalyst, and it might be related with that. Anyway, Catalyst can be patched to avoid that behaviour, restoring the normal use of 320x and 400x modes without the 321 trick. Besides that, we also have the issue with default modes (31 KHz) added by the driver at a variety of resolutions, that need to be restricted.

Thanks for the good work, again!


It should, they at least are working on all the ATI cards and seems the ones with r600/700/800 gpu chips are getting the best attention, although the r200/300/400 ones should in theory work too.  I think my x850 card has some odd dual card ability which breaks it from doing lower resolutions well.

It's X windows that puts the default resolutions in and I have a simple patch that fixes it where if the EDID isn't there and the user has specified any modelines in xorg.conf then it'll skip adding those default resolutions:
Code: [Select]
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index b2daec7..ff5ca2c 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -1633,6 +1633,10 @@ xf86ProbeOutputModes (ScrnInfoPtr scrn, int maxX, int maxY)
            xf86ForEachDetailedBlock(edid_monitor,
                                     handle_detailed_monrec,
                                     &p);
+       } else {
+           xf86DrvMsg(scrn->scrnIndex, X_INFO,
+                  "No EDID on output %s\n", output->name);
+           add_default_modes = FALSE;
        }

        if (xf86GetOptValFreq (output->options, OPTION_MIN_CLOCK,

I'm now on the xorg-devel mailing list and submitted it to them, hopefully they care enough to pay attention and this makes it into the main xserver eventually.  For now it's a pretty easy thing to patch and with the discovery of the modular GIT download package they have it makes compiling the whole X Windows somewhat easy.  There are a few quirks to it still with the build.sh script and I hopefully can make those easier to avoid with possibly a script to run the necessary commands with build.sh and add in the extra setting of things like environment variables.


My arcade cabinet now is definitely working nice and you not only gain MAME running without tearing and proper refresh rates and true resolutions, this stuff is dang fast for the other stuff too requiring Mesa OpenGL and DRM in general.  Also the Radeon card modeswitching is much smoother and seems the atom bios and chip is just being run properly now, before I guess it was more of a hack from userspace or something with the normal ati x driver methods.  Plus now you get a framebuffer on the console again with the newer cards, I am not sure how nice the modelines they have setup in there are on a true fixed freq arcade monitor though.  It should be somewhat easy to add a few modelines into the kernel as arcade monitor ones but I also think that the cvt part of it (it uses cvt too if you ask for one it doesn't know) should work giving it video=640x480-32@31i  which results in basically a 15.6Khz interlaced display for the frame buffer.  It seems you have to do the refresh rate 31 to get 62Hz interlaced and it pushes the Hfreq from 15.0 to 15.6 by doing that.  It might be nice to try putting lrmc logic in there to choose instead of cvt and specify it with a switch at the end like how it takes the 'i' at the end (like 'A' or something).

So one thing I would like to do is work on setting up the ability to make the framebuffer truly arcade friendly, to allow directfb and console usage to work nicely since it is nice to avoid X for some things (if only there was a good frontend too, would be kind of nice to avoid X all together).  One issue though with the framebuffer stuff is that directfb just doesn't understand the refresh rates and pixelclock settings and does the things we originally were stuck with in xrandr and SDL 1.2 with all the modelines.  It seems to not take very precise Hz values with decimal places and so we'd have to setup some interesting way to write out the /etc/fb.modes file each game start to hold only the Mode we want (that's how the directfb stuff programs the framebuffer, or basically how the Linux framebuffer gets the modelines it uses).  I guess that starts getting more complicated the more I think about it, there's unfortunately a lot of preset expectations on the framebuffer layers to just be a vesa compliant one.

I do think the nouveau driver will eventually be a good thing with Nvidia cards most likely, it's just not ready in development or at least close but not exactly there yet.  For now these radeon 4350 cards do look like the best bet, just odd how this new KMS stuff totally breaks an ArcadeVGA 3000 card into some weird horrible output issues.  I think they would have to completely write stuff into the DRM layers to add the AVGA cards and may be hard since the bios is closed source to them.  Fortunately ATI has the employees working on the normal Radeon cards in Linux though and since they can fully see all the stuff most likely, we are getting a very nice Radeon driver in Linux it seems. 
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on November 03, 2010, 11:50:11 am
i have ati 4850 and was wondering what is the best linux flavour to use, something that loades fast and how easy is it to install thispackage i am not a linux user?
If you have an arcade monitor, then you'll want to possibly use Ubuntu but will have to install a newer patched xrandr/xserver plus the lrmc and switchres program.  Also will need to patch the Linux kernel, getting the newest one, and compile/install it.  Not a super easy task unfortunately for those not used to Linux, hopefully all the patches get into the mainline code eventually although it's hard to get the developers to listen about old CRT monitors.

If you don't have an arcade monitor, then just install the newest 10.10 Ubuntu and it has mame packages and everything you need, and should work great plus you really don't need my programs in that case since it mostly just makes arcade monitors and resolution switching work better.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: lodoss118 on November 03, 2010, 02:17:49 pm
i have a arcade monitor :( i am going to get a mini itx and put my ati 4850 in that not sure i can setup a linux mame with this package :(. Is it possible for someone uhmmmm
in here making a compiled version of linux with this package already setup :@
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on November 03, 2010, 02:48:56 pm
i have a arcade monitor :( i am going to get a mini itx and put my ati 4850 in that not sure i can setup a linux mame with this package :(. Is it possible for someone uhmmmm
in here making a compiled version of linux with this package already setup :@

Hopefully this can be used by those who want to create distributions, it is something that I've done before but it's hard to make a compile of every single persons setup with the kernel and hardware.  I hopefully can make a script to somewhat automate it but it'd probably be mostly like how Gentoo works which is by no means for the first time user. 

I'm researching how to either make this all work in the mainline linux stuff, get patches pushed into that, or make it easiest as it can be to setup.  It's all just now possible and very new code that they've been putting into the linux kernel as of the last month.  So I think we'll eventually see this all become easier, at least I hope, or someone will be able to distribute a setup disk with the proper binaries on it.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: Calamity on November 03, 2010, 06:30:12 pm
I've posted this on the Spanish forum, hopefully VeS can try this stuff with a distribution, if you think it's a good idea.

Modifying the frame buffer modes sounds interesting. It's unlikely that 640x480@31i mode will work with many fixed frequency arcade monitors, because vesa porchs and sync pulses are shorter, and probably the mode will be out of sync, however it's a matter of testing. This applies only to the console, doesn't it?



Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on November 03, 2010, 08:37:38 pm
I've posted this on the Spanish forum, hopefully VeS can try this stuff with a distribution, if you think it's a good idea.

Modifying the frame buffer modes sounds interesting. It's unlikely that 640x480@31i mode will work with many fixed frequency arcade monitors, because vesa porchs and sync pulses are shorter, and probably the mode will be out of sync, however it's a matter of testing. This applies only to the console, doesn't it?




Yeah it's just the console, I think it's not too hard to adapt to arcade monitor support by just putting in some default modelines that work well with arcade monitors and forcing them through a kernel command line option. 

Definitely would be good to base a distribution off the xserver patch that I posted, only avoiding the default modes when there's modelines defined, and the newest X  Windows build and Linux kernel with the drm patches I have (plus xrandr patch, although I'm trying to obsolete that, I think it may not be needed, testing that right now). 

I'll post an updated genres here in the next day or so that should hopefully remove the need for the xrandr patch, include the right xserver patch (simpler one), and linux kernel patch with possible fixed freq arcade monitor support.  For now he should become familiar with the newest Linux kernel, I think 2.6.37-rc1 is fine, and the method of using the modular build.sh script to download the newest X build.  I'd be curious about any feedback on using that script, and if any issues come up.  It seems pretty solid and they are actively working on it so it's pretty smooth working on downloading/compiling/installing everything.   I've found I have to set 'export USE_XCB=NO' because xcb won't build with the python version before 3.0 which then isn't stable and breaks other X packages.  That's the main caveat I've found with the build.sh script so far, otherwise it's nice and can combine it with the newest Linux kernel to get a pretty nice setup.  The module options are important, in the radeon.conf file, and must build with radeon drm with KMS built in for the Linux kernel to use the newer radeon kernel code.   

I think I can get most things worked out to be minimal in patching the xserver only, linux kernel drm stuff, hopefully including a console that is arcade monitor friendly.  Will see how that goes, not sure how much work the console framebuffer will be.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: bitbytebit on November 04, 2010, 05:54:22 pm
I've posted this on the Spanish forum, hopefully VeS can try this stuff with a distribution, if you think it's a good idea.

Modifying the frame buffer modes sounds interesting. It's unlikely that 640x480@31i mode will work with many fixed frequency arcade monitors, because vesa porchs and sync pulses are shorter, and probably the mode will be out of sync, however it's a matter of testing. This applies only to the console, doesn't it?





I have been able to add the arcade frame buffer support/modes to the Linux kernel, and at the same time can avoid needing to patch the X server or X programs at all.  You will need the newest versions of X Windows still of course, but may be able to use ones that are from code after this last May (when they added an option called "DefaultModes" to the Monitor sections).  With that option we can turn off the default modes, so makes my patch obsolete.  Now I basically can give the Linux kernel an option like "video=DVI-I-0:640x480c" which the 'c' at the end tells it to kick into CGA mode, I have a 640x240, 320x240, 384x288 in there that can also be chosen but still need to test those, the 640x480 is interlaced and generated with lrmc using the -cga command line.  It's only for the frame buffer, but it's important to do this because of how X Windows and the DRM stuff in the framebuffer code work together now to do mode switching.  There are more default modes that can be pushed into the X server from the kernel framebuffer now, but my patch will allow the CGA mode to avoid using those plus also optimize modeline setup for an arcade monitor.  It will avoid trying to get an EDID over and over from the arcade monitor, and from adding any extra modes besides the one you pick on the kernel command line.

So basically with this one patch to the kernel, using Linux 2.6.37-rc1, and a newer X Windows from GIT or any that support the DefaultModes option, you should be able to use the radeon cards and my switchres program utilizing xrandr and we can do everything we want to with an arcade monitor through Linux.  The xorg.conf config of course needs that DefaultModes options set to False and possibly a few other tweaks too, although that might be it actually.  The console framebuffer mode you choose, will also be your default X modeline that it starts up with if you don't add more modelines in the xorg.conf. 

It's looking pretty promising, I'm thinking of repackaging the whole GenRes zip file to just include what is necessary now that we no longer require much extra stuff.  Mainly just lrmc, switchres, linux patch, mame patch (optional), and general info on getting/patching the kernel and getting the X org modular package and running build.sh to download/compile/install a fresh version of X Windows.  This is so far also running really stable on my arcade cabinet, the radeon driver is good.  I can say though the nouveau driver is quite unstable, I'm running it on my workstation and can lockup randomly.  All this also kinda abstracts the need for only Radeon cards in the future.  The blocks to that are doing some more min-pixclock changing for the other drivers in the DRM part of the kernel, hoping the other DRM cards become fully xrandr compliant and support the vsync stuff from OpenGL correctly.  Most of the focus though is in the kernel now, so it's just a custom kernel that should be necessary to get things working for any card in the future.

Also if you have any good all-around default modelines I should use in the kernel for these modes chosen on the commandline, I'm using the lrmc ones and thinking about instead using the Soft15Khz ones possibly since I am guessing they are probably better.  I'm going to write a script to convert them quickly into the structure format in C used for storing them in the kernel code, so I can make most any arcade mode possible for the console.  This also should make a system easy to reboot into any frame buffer mode specific to a game and use DirectFB with mame and avoid the X Windows if one wanted a dedicated console for one resolution.  Dynamically changing it may be a pain for now, not fully sure. 

So I'll have a new GenRes with a linux kernel patch and a bit more organized up later tonight or sometime tomorrow.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .14)
Post by: elvis on November 07, 2010, 07:42:11 am
You will need the newest versions of X Windows still of course, but may be able to use ones that are from code after this last May (when they added an option called "DefaultModes" to the Monitor sections).
For anyone wondering, Ubuntu 10.10 "Maverick" supports "DefaultModes" with it's provided version of xorg-server.  I'll try to test with the latest version of switchres+kernel-patches next weekend.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: Calamity on November 07, 2010, 10:05:49 am
I am thinking of building all this stuff myself as I'm definitely getting interested in Linux and I want to test it directly. I've seen the readme is focused on Gentoo, is it a good way to start? Any advices on distributions or packages to start with?
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: bitbytebit on November 07, 2010, 12:49:26 pm
I am thinking of building all this stuff myself as I'm definitely getting interested in Linux and I want to test it directly. I've seen the readme is focused on Gentoo, is it a good way to start? Any advices on distributions or packages to start with?


Sounds like Ubuntu might just be  a good way to start, creating a dpkg of the ubuntu kernel with the patch applied already would make it a super simple way to do this since in Gentoo it's in a  sense like building your own Linux distribution but with everything ready to be put onto the partition. 

I'll look into building a patched ubuntu kernel package. 

Also I'm currently experimenting with a command line option I added to lrmc which directly feeds the variables it uses to calculate a display structure for the modeline generation.  It's giving me a quick way to fiddle around with the settings of active/total lines and front/back porch size etc.  At least on the d9800 I'm finding some logic to being able to customize these with some algorithm on each games HxW@R values  and getting some even more exact refresh rates and display sizes.  If anything it's helping me get closer to moving some of the logic of lrmc into the perl script and having control and understanding it.

Basically right now a command line like these w/modelines, some are somewhat shifted to the right slightly but defender most of these examples, just started but guessing you might get some insight into these values and modelines (basically input for the -custom command are for HFPORCH, HACTIVE, HSYNC, HTOTAL, VFPORCH, VACTIVE, VSYNC, VTOTAL)
Code: [Select]
# suprmrio  256x240x32@60.000000 - lrmc 256 240 60.000000  -v -n -custom 15250 40000 40 85 3000000 90000000 8 320 32 384 4 240 3 256 -sl -i
"256x240"  4.669440 256 264 288 304 240 244 247 256 -HSync -VSync
# mario  256x224x32@59.185606 - lrmc 256 224 59.185606  -v -n -custom 15250 40000 40 85 3000000 90000000 8 320 32 384 4 224 3 240 -sl -i
"280x240"  5.124000 280 288 320 336 240 244 247 257 -HSync -VSync
# puckman  384x288x32@60.606061 - lrmc 384 288 60.606061  -v -n -custom 15250 40000 40 85 3000000 90000000 8 384 32 512 4 288 3 312 -sl -i
"384x288"  9.681455 384 392 424 512 288 292 295 312 -HSync -VSync
# defender  296x240x32@60.096154 - lrmc 296 240 60.096154  -v -n -custom 15250 40000 40 85 3000000 90000000 8 296 32 384 4 240 3 256 -sl -i
"296x240"  5.907693 296 304 336 384 240 244 247 256 -HSync -VSync
# dkong  344x256x32@60.606061 - lrmc 344 256 60.606061  -v -n -custom 15250 40000 40 85 3000000 90000000 8 344 32 448 4 256 3 280 -sl -i
"344x256"  7.602425 344 352 384 448 256 260 263 280 -HSync -VSync
# dbz  384x256x32@55.000000 - lrmc 384 256 55.000000  -v -n -custom 15250 40000 40 85 3000000 90000000 8 384 32 512 4 256 3 288 -sl -i
"384x256"  8.110080 384 392 424 512 256 260 263 288 -HSync -VSync

I started doing this after trying as reference modelines in lrmc.conf the ones from Soft15Khz, which I admit when using those I got better values for the blanking stuff and only issue was that on some modelines the screen has side boarders and not filling it fully horizontally.  So from there , since it's sort of the opposite of what lrmc does with the d9800 values it uses by default, figured this could hopefully help find the logic in between the two.  So far at least I've been able to work all vertical values logically and seem good, the horizontal is slowly getting to work correctly on more and more modelines horzontal resolution sizes.  Seems those are more up in the air which on the vertical side I just had a somewhat simple way of calculating and there's a lot more varying horizontal sizes to adjust for.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: bitbytebit on November 07, 2010, 12:52:22 pm
I am thinking of building all this stuff myself as I'm definitely getting interested in Linux and I want to test it directly. I've seen the readme is focused on Gentoo, is it a good way to start? Any advices on distributions or packages to start with?


Sounds great, If you know about building ubuntu packages would be interesting to get a kernel build package with the patch.  I'll look into this, I'm using the newest Ubuntu now on my desktop system as of the last few days and should help me be able to do things like that too.  I'm guessing it'll be a good combination using the newest Ubuntu and some modified packages to support arcade monitors, which is quite exciting since it sounds like a lot easier than my previous thoughts on how to make this work for people with the least amount of knowing details of compiling things and rebuilding parts of the system.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: Calamity on November 07, 2010, 05:33:00 pm
Sounds like Ubuntu might just be  a good way to start, creating a dpkg of the ubuntu kernel with the patch applied already would make it a super simple way to do this since in Gentoo it's in a  sense like building your own Linux distribution but with everything ready to be put onto the partition.  

I'll look into building a patched ubuntu kernel package.

I'll have a look at Ubuntu, I've been tempted to try it before and now I have a good reason.

Also I'm currently experimenting with a command line option I added to lrmc which directly feeds the variables it uses to calculate a display structure for the modeline generation.  It's giving me a quick way to fiddle around with the settings of active/total lines and front/back porch size etc.  At least on the d9800 I'm finding some logic to being able to customize these with some algorithm on each games HxW@R values  and getting some even more exact refresh rates and display sizes.  If anything it's helping me get closer to moving some of the logic of lrmc into the perl script and having control and understanding it.

Basically right now a command line like these w/modelines, some are somewhat shifted to the right slightly but defender most of these examples, just started but guessing you might get some insight into these values and modelines (basically input for the -custom command are for HFPORCH, HACTIVE, HSYNC, HTOTAL, VFPORCH, VACTIVE, VSYNC, VTOTAL)

I started doing this after trying as reference modelines in lrmc.conf the ones from Soft15Khz, which I admit when using those I got better values for the blanking stuff and only issue was that on some modelines the screen has side boarders and not filling it fully horizontally.  So from there , since it's sort of the opposite of what lrmc does with the d9800 values it uses by default, figured this could hopefully help find the logic in between the two.  So far at least I've been able to work all vertical values logically and seem good, the horizontal is slowly getting to work correctly on more and more modelines horzontal resolution sizes.  Seems those are more up in the air which on the vertical side I just had a somewhat simple way of calculating and there's a lot more varying horizontal sizes to adjust for.

As you have seen vertical and horizontal values can be worked out separately and be tied up later by the dotclock value. Horizontal values are a bit more tricky to calculate than vertical ones. All approaches I've seen (included AdvanceMame and lrmc I believe) use reference modelines or simply proportions among hactive/htotal/porches. This is a botch, that can work more ore less ok in many situations, but you don't have full control of the results and sometimes it may fail to produce a good modeline. Using that method, you need ad hoc reference modelines for each hfreq, which is not good at all.

In order to get rid of reference modelines, we need to know the right values of our monitor's front and back porches and sync pulse. These values are given in µs. If we are able to get modelines that produce these values, then we'll solve all our horizontal sizing and centering for any resolution. These are the ones I use with my monitor (Hantarex 9110) that could be good for any lowres monitor or TV:

   FrontPorch = 2.0
   SyncPulse = 4.7
   BackPorch = 8.0

These values are very similar to the ones used with standard NTSC/PAL signals, except for the porches that are a little bit bigger. The reason is that TVs were designed to work with a significant overscan, and if we used the same values we would have a chopped picture on the sides.

Second, we must know that horizontal timings are programmed using 'characters', not pixels. Characters are a group of 8 horizontal pixels. That's why all horizontal values must use 8-multiples. But this introduces a serious limitation in precision for horizontal calculations, as the picture can only be shifted right or left by 8 pixel jumps. So with really low resolutions, it may be difficult to center the picture properly, as normally it may be either too shifted to the right or to the left. The only way to solve this is to increase horizontal total and recenter the picture with bigger margins. Another issue with this is that if calculations are considered 'continuous', then when translating them to these 'discrete' character elements, the rounding to 8 can produce porch values that are too low, or even worse, sync pulses that are too short. So we need to check the output values against some minimums in order to accept them, mine are:

   FrontPorchMin = 1.8
   SyncPulseMin = 4.5
   BackPorchMin = 7.8

Let's have a look at one of your modelines and calculate the values directly:

"384x256"  8.110080 384 392 424 512 256 260 263 288 -HSync -VSync

hs = ( 392 - 384 ) / 8 = 1 (front porch in chars)
he = ( 424 - 392 ) / 8 = 4 (sync pulse in chars)
ht = ( 512 - 424 ) / 8 = 11 (back porch in chars)

LineTime = 1 / ( 8110080 / 512 ) * 1000000 = 63.1313 µs (this is the length of a single line)
CharTime = 63.1313 / ( 512 / 8 ) = 0.9864 µs (this is the length of a single character)

FrontPorch = hs * 0.9864 = 0.9864 ( < FrontPorchMin !)
SyncPulse = he * 0.9864 = 3.9457 ( < SyncPulseMin ! )
BackPorch = ht * 0.9864 = 10.8507 ( way bigger than needed BackPorch ! )

I haven't tested this modeline, but it's clear it would be shifted to the right on my monitor. Sync pulse is short, and though my monitor would synchronize with no problem, it's likely some monitors would not, as it's below the standard. We should change the horizontal values like this:

"384x256"  8.110080 384 400 440 512 256 260 263 288 -HSync -VSync

... to get 1.97, 4.93, 8.88 respectively.

We tend to use modelines with bigger back porches as its closer to NTSC/PAL standards, however arcade monitors are very flexible. All we need is to keep our values as constant as possible from one modeline to another, and they will all be centered. This method allows as to shift all resolutions to the right/left at the same time by re-calculating them using new porches.

This is the easy part. Now we need the opposite: to get the modeline values from the porch/sync ones. These calculations need to be iterated as CharTime changes each time we change HTotal. I'll show the algorithm I use. This is used once you have calculated the vertical part and know your Hfreq (note that only input values required are Hfreq and xres, the rest are output values):

Code: [Select]
SUB ModelineGetLineParams ( hfreq AS SINGLE, xres AS LONG, hhh AS LONG, hhi AS LONG, hhf AS LONG, hht AS LONG )

  LOCAL hh, hs, he, ht AS LONG
  LOCAL LineTime, CharTime, NewCharTime AS SINGLE

  LineTime = 1 / hfreq * 1000000

  hh = ROUND ( xres / 8, 0 )
  hs = 1
  he = 1
  ht = 1

  DO
    CharTime = LineTime / ( hh + hs + he + ht )
    IF hs * CharTime < FrontPorchMin OR ABS ( ( hs + 1 ) * CharTime - FrontPorch ) < ABS ( hs * CharTime - FrontPorch ) THEN INCR hs
    IF he * CharTime < SyncPulseMin OR ABS ( ( he + 1 ) * CharTime - SyncPulse ) < ABS ( he * CharTime - SyncPulse ) THEN INCR he
    IF ht * CharTime < BackPorchMin OR ABS ( ( ht + 1 ) * CharTime - BackPorch ) < ABS ( ht * CharTime - BackPorch ) THEN INCR ht
    NewCharTime = LineTime / ( hh + hs + he + ht )
  LOOP UNTIL NewCharTime = CharTime

  hhh = hh * 8
  hhi = ( hh + hs ) * 8
  hhf = ( hh + hs + he ) * 8
  hht = ( hh + hs + he + ht ) * 8

END SUB

What you need to know is if your monitor is either truly continuous in the whole hfreq range (then you shoud find out the right porches for the highest and the lowest frequency and then interpolate) or it works by intervals where fixed porches and pulses need to be used. Mine uses fixed values in the whole range (15.625-16.700) so I predefine FrontPorch/SyncPulse/BackPorch as globals right from a ini file, but you may need to calculate them depending of mode's hfreq or have a table (similar of what you've been doing with those intervals). I hope this can be of help.

Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: bitbytebit on November 07, 2010, 08:44:57 pm
Sounds like Ubuntu might just be  a good way to start, creating a dpkg of the ubuntu kernel with the patch applied already would make it a super simple way to do this since in Gentoo it's in a  sense like building your own Linux distribution but with everything ready to be put onto the partition.  

I'll look into building a patched ubuntu kernel package.

I'll have a look at Ubuntu, I've been tempted to try it before and now I have a good reason.

Also I'm currently experimenting with a command line option I added to lrmc which directly feeds the variables it uses to calculate a display structure for the modeline generation.  It's giving me a quick way to fiddle around with the settings of active/total lines and front/back porch size etc.  At least on the d9800 I'm finding some logic to being able to customize these with some algorithm on each games HxW@R values  and getting some even more exact refresh rates and display sizes.  If anything it's helping me get closer to moving some of the logic of lrmc into the perl script and having control and understanding it.

Basically right now a command line like these w/modelines, some are somewhat shifted to the right slightly but defender most of these examples, just started but guessing you might get some insight into these values and modelines (basically input for the -custom command are for HFPORCH, HACTIVE, HSYNC, HTOTAL, VFPORCH, VACTIVE, VSYNC, VTOTAL)

I started doing this after trying as reference modelines in lrmc.conf the ones from Soft15Khz, which I admit when using those I got better values for the blanking stuff and only issue was that on some modelines the screen has side boarders and not filling it fully horizontally.  So from there , since it's sort of the opposite of what lrmc does with the d9800 values it uses by default, figured this could hopefully help find the logic in between the two.  So far at least I've been able to work all vertical values logically and seem good, the horizontal is slowly getting to work correctly on more and more modelines horzontal resolution sizes.  Seems those are more up in the air which on the vertical side I just had a somewhat simple way of calculating and there's a lot more varying horizontal sizes to adjust for.

As you have seen vertical and horizontal values can be worked out separately and be tied up later by the dotclock value. Horizontal values are a bit more tricky to calculate than vertical ones. All approaches I've seen (included AdvanceMame and lrmc I believe) use reference modelines or simply proportions among hactive/htotal/porches. This is a botch, that can work more ore less ok in many situations, but you don't have full control of the results and sometimes it may fail to produce a good modeline. Using that method, you need ad hoc reference modelines for each hfreq, which is not good at all.

In order to get rid of reference modelines, we need to know the right values of our monitor's front and back porches and sync pulse. These values are given in µs. If we are able to get modelines that produce these values, then we'll solve all our horizontal sizing and centering for any resolution. These are the ones I use with my monitor (Hantarex 9110) that could be good for any lowres monitor or TV:

   FrontPorch = 2.0
   SyncPulse = 4.7
   BackPorch = 8.0

These values are very similar to the ones used with standard NTSC/PAL signals, except for the porches that are a little bit bigger. The reason is that TVs were designed to work with a significant overscan, and if we used the same values we would have a chopped picture on the sides.

Second, we must know that horizontal timings are programmed using 'characters', not pixels. Characters are a group of 8 horizontal pixels. That's why all horizontal values must use 8-multiples. But this introduces a serious limitation in precision for horizontal calculations, as the picture can only be shifted right or left by 8 pixel jumps. So with really low resolutions, it may be difficult to center the picture properly, as normally it may be either too shifted to the right or to the left. The only way to solve this is to increase horizontal total and recenter the picture with bigger margins. Another issue with this is that if calculations are considered 'continuous', then when translating them to these 'discrete' character elements, the rounding to 8 can produce porch values that are too low, or even worse, sync pulses that are too short. So we need to check the output values against some minimums in order to accept them, mine are:

   FrontPorchMin = 1.8
   SyncPulseMin = 4.5
   BackPorchMin = 7.8

Let's have a look at one of your modelines and calculate the values directly:

"384x256"  8.110080 384 392 424 512 256 260 263 288 -HSync -VSync

hs = ( 392 - 384 ) / 8 = 1 (front porch in chars)
he = ( 424 - 392 ) / 8 = 4 (sync pulse in chars)
ht = ( 512 - 424 ) / 8 = 11 (back porch in chars)

LineTime = 1 / ( 8110080 / 512 ) * 1000000 = 63.1313 µs (this is the length of a single line)
CharTime = 63.1313 / ( 512 / 8 ) = 0.9864 µs (this is the length of a single character)

FrontPorch = hs * 0.9864 = 0.9864 ( < FrontPorchMin !)
SyncPulse = he * 0.9864 = 3.9457 ( < SyncPulseMin ! )
BackPorch = ht * 0.9864 = 10.8507 ( way bigger than needed BackPorch ! )

I haven't tested this modeline, but it's clear it would be shifted to the right on my monitor. Sync pulse is short, and though my monitor would synchronize with no problem, it's likely some monitors would not, as it's below the standard. We should change the horizontal values like this:

"384x256"  8.110080 384 400 440 512 256 260 263 288 -HSync -VSync

... to get 1.97, 4.93, 8.88 respectively.

We tend to use modelines with bigger back porches as its closer to NTSC/PAL standards, however arcade monitors are very flexible. All we need is to keep our values as constant as possible from one modeline to another, and they will all be centered. This method allows as to shift all resolutions to the right/left at the same time by re-calculating them using new porches.

This is the easy part. Now we need the opposite: to get the modeline values from the porch/sync ones. These calculations need to be iterated as CharTime changes each time we change HTotal. I'll show the algorithm I use. This is used once you have calculated the vertical part and know your Hfreq (note that only input values required are Hfreq and xres, the rest are output values):

Code: [Select]
SUB ModelineGetLineParams ( hfreq AS SINGLE, xres AS LONG, hhh AS LONG, hhi AS LONG, hhf AS LONG, hht AS LONG )

  LOCAL hh, hs, he, ht AS LONG
  LOCAL LineTime, CharTime, NewCharTime AS SINGLE

  LineTime = 1 / hfreq * 1000000

  hh = ROUND ( xres / 8, 0 )
  hs = 1
  he = 1
  ht = 1

  DO
    CharTime = LineTime / ( hh + hs + he + ht )
    IF hs * CharTime < FrontPorchMin OR ABS ( ( hs + 1 ) * CharTime - FrontPorch ) < ABS ( hs * CharTime - FrontPorch ) THEN INCR hs
    IF he * CharTime < SyncPulseMin OR ABS ( ( he + 1 ) * CharTime - SyncPulse ) < ABS ( he * CharTime - SyncPulse ) THEN INCR he
    IF ht * CharTime < BackPorchMin OR ABS ( ( ht + 1 ) * CharTime - BackPorch ) < ABS ( ht * CharTime - BackPorch ) THEN INCR ht
    NewCharTime = LineTime / ( hh + hs + he + ht )
  LOOP UNTIL NewCharTime = CharTime

  hhh = hh * 8
  hhi = ( hh + hs ) * 8
  hhf = ( hh + hs + he ) * 8
  hht = ( hh + hs + he + ht ) * 8

END SUB

What you need to know is if your monitor is either truly continuous in the whole hfreq range (then you shoud find out the right porches for the highest and the lowest frequency and then interpolate) or it works by intervals where fixed porches and pulses need to be used. Mine uses fixed values in the whole range (15.625-16.700) so I predefine FrontPorch/SyncPulse/BackPorch as globals right from a ini file, but you may need to calculate them depending of mode's hfreq or have a table (similar of what you've been doing with those intervals). I hope this can be of help.



Cool, this is great, I can see what your saying about the horizontal issue and makes total sense from what I am having to deal with.  I do have the timing values of the WG D9800/D9400 Monitors, they have 5 standard factory pre-set timing modes.  They can be set to any values between 15.75-40Khz hor and 40-100Hz ver, at the factory they have the 15.725, 24.395, 31.469 another 31.469 and a 37.879 modes.  From what the engineer said, any values for H/V freq can be used in those bigger ranges, but I'm guessing the values you mention are the key in using within each range.  The CGA mode ranges are close to yours somewhat, 2.187, 4.688, 6.719, EGA mode ranges are 2.910, 3.000, 4.440, VGA .636, 3.813, 1.906, second VGA mode the same which I guess it's extended and a 720x400 size for it compared to 640x480 on the first VGA mode, and SVGA 1.000, 3.200, 2.200.   So I'm not totally sure how to choose which values besides just the closest Hfreq to one of the preset modes, like when in the 17-19Khz Horz range for the 288 line pacman resolution at 60.61Hz.  That one looks good already though, so seem to be doing mostly right with what I've done but then it's mostly a few vertical games and a fewer odd ones like the one you pointed out (dbz) that it's shifted to one side or the other of the screen (although compared to what I was doing it's much better than before).  I'm just surprised with the one single display setting line I input now, I can mostly get games all looking decent, compared to the way lrmc usually works with the d9200 and d9800 having multiple display settings, since I guess I'm calculating the display setting more dynamically and vertical looks good on all games so it's now just the horizontal.

I converted your code/function for the horizontal calculation into perl, made a little program I ran and tested values with and looks good.  I was thinking about running things through lrmc twice, once I got the the basic resolution, but this makes more sense and probably what I was thinking would have never worked right.  I am guessing that after running through lrmc to calculate the basic resolution, this would be used to fixup the horizontal settings. 

The only thing odd is my perl script gives the last value as 504 instead of 512 for the total, basically  "384 400 440 504" for horizontal, maybe a rounding issue in perl?  Here's the perl program created from your function:
Code: [Select]
#!/usr/bin/perl
#
#
use POSIX;
use Getopt::Long;

my $FrontPorch = 2.187;
my $SyncPulse  = 4.688;
my $BackPorch  = 6.719;

my $HFreq = "15840";
my $HRes  = "384";

my $help    = 0;
my $debug   = 0;

my $result = GetOptions (
                "help|h" => \$help,
                "debug|d" => \$debug,
                "hfreq|hf=s" => \$HFreq,
                "hres|hr=s" => \$HRes,
                "fp=s" => \$FrontPorch,
                "sp=s" => \$SyncPulse,
                "bp=s" => \$BackPorch,
);

if ($help) {
        print "Usage:\n";
        print "  -hf    Horizontal Frequency\n";
        print "  -hr    Horizontal Resolution\n";
        print "  -fp    FrontPorch\n";
        print "  -sp    SyncPulse\n";
        print "  -bp    BackPorch\n";
        exit 0;
}

my $FrontPorchMin = sprintf("%.2f", ($FrontPorch - .20));
my $SyncPulseMin  = sprintf("%.2f", ($SyncPulse - .20));
my $BackPorchMin  = sprintf("%.2f", ($BackPorch - .20));

my $output = ModelineGetLineParams($HFreq, $HRes);

print "$output\n";

exit 0;


sub ModelineGetLineParams() {
  my $hfreq = shift(@_); # SINGLE
  my $xres  = shift(@_); #LONG 
  my $hhh = 0; # LONG
  my $hhi = 0;
  my $hhf = 0;
  my $hht = 0;

  my $hh, $hs, $he, $ht; # LONG
  my $LineTime, $CharTime, $NewCharTime; #  SINGLE

  $LineTime = 1 / $hfreq * 1000000;
  $LineTime = sprintf("%.4f", $LineTime);

  $hh = ceil( ($xres / 8) );
  $hs = 1;
  $he = 1;
  $ht = 1;

  if ($debug) {
        print "Input hfreq: $hfreq xres: $xres LineTime: $LineTime hh: $hh\n";
  }

  do {
    $CharTime = $LineTime / ( $hh + $hs + $he + $ht );
    if ((($hs * $CharTime) < $FrontPorchMin) ||
        (abs(( $hs + 1 ) * $CharTime - $FrontPorch ) < abs( $hs * $CharTime - $FrontPorch ))) {
                $hs++;
    }
    if ((($he * $CharTime) < $SyncPulseMin) ||
        (abs(( $he + 1 ) * $CharTime - $SyncPulse ) < abs( $he * $CharTime - $SyncPulse ))) {
                $he++;
    }
    if ((($ht * $CharTime) < $BackPorchMin) ||
        (abs(( $ht + 1 ) * $CharTime - $BackPorch ) < abs( $ht * $CharTime - $BackPorch ))) {
                $ht++;
    }
    $NewCharTime = $LineTime / ( $hh + $hs + $he + $ht );
    if ($debug) {
      print "CharTime: $CharTime NewCharTime: $NewCharTime LineTime: $LineTime hh: $hh hs: $hs he: $he ht: $ht\n";
    }
  } while ($NewCharTime != $CharTime);
  # LOOP UNTIL NewCharTime = CharTime

  $hhh = $hh * 8;
  $hhi = ( $hh + $hs ) * 8;
  $hhf = ( $hh + $hs + $he ) * 8;
  $hht = ( $hh + $hs + $he + $ht ) * 8;

  return "$hhh $hhi $hhf $hht";
}

It's great though to now have an entry point into your code from this, and start figuring out how to make the same calculations your talking about instead of trusting lrmc which definitely sounds like it causes they issues your talking about and I'm seeing because of use of reference modelines. 

I've attached the full set of specs for the D9400/9800 monitors, for the first time I see how the values are directly able to calculate the modlines, thanks for tying this together into that.  I've been wanting to be able to use those values somehow and didn't realize how they translated to the actual ones but now see that the character conversion makes them make sense.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: elvis on November 08, 2010, 07:12:17 am
I'll look into building a patched ubuntu kernel package.  
Install a package called "kernel-package" and then read the man file on "kpkg".  It makes building custom kernel packages a piece of cake.

I'm sure there's an equivalent in RPM-based distros, but kpkg is the way to go in Debian, Ubuntu and the various derivatives.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: Calamity on November 08, 2010, 07:46:30 am
The only thing odd is my perl script gives the last value as 504 instead of 512 for the total, basically  "384 400 440 504" for horizontal, maybe a rounding issue in perl?  Here's the perl program created from your function:

Your script is working fine. It gives 504 instead of 512 because your entering 6.719 for the back porch, smaller than 8.88 of the modeline we used as sample and I modified by hand. I'm happy you could translate it into perl!

I've attached the full set of specs for the D9400/9800 monitors, for the first time I see how the values are directly able to calculate the modlines, thanks for tying this together into that.  I've been wanting to be able to use those values somehow and didn't realize how they translated to the actual ones but now see that the character conversion makes them make sense.

Precious information. If you look at VGA_m3 and VGA_m2 they are much the same, horizontal values are equal so you may use just one interval for both modes. Only difference is vertical porches. I'm gessing your monitor has a sort of auto-adjust mechanism, and it's separating 400 and 480 vertical resolutions to properly adjust vertical amplitude, so both of them fill the screen.

Appart from that, your decision of which interval to use should be hfreq-driven, the closest to the reference one for the interval may be a good first approach, but there must be a jump somewhere in between 15.725 and 24.394, (etc.) where the respective values of each interval should apply (unless they are continuous and interpolated that would be very strange). Without more info, the only way to establish that point is by experimenting.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: Calamity on November 08, 2010, 07:47:33 am
I'll look into building a patched ubuntu kernel package.  
Install a package called "kernel-package" and then read the man file on "kpkg".  It makes building custom kernel packages a piece of cake.

I'm sure there's an equivalent in RPM-based distros, but kpkg is the way to go in Debian, Ubuntu and the various derivatives.

Thanks! I'll have a look at this!
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: bitbytebit on November 08, 2010, 09:36:30 am
I'll look into building a patched ubuntu kernel package.  
Install a package called "kernel-package" and then read the man file on "kpkg".  It makes building custom kernel packages a piece of cake.

I'm sure there's an equivalent in RPM-based distros, but kpkg is the way to go in Debian, Ubuntu and the various derivatives.

Thanks! I'll have a look at this!


I've actually just built a ubuntu kernel package last night, it's for amd64 though and I'm now trying to figure out how to cross compile one for 32 bit processors.  I haven't given it a test though, guessing it should work but of course will need to add the video=640x480c option into grub.cfg manually (not sure yet how to build that into the install, seems they are vague about that part).  I'm looking at testing it, and cleaning up the build of it and uploading it my sourceforge page.  So looks like this should make it pretty easy on ubuntu to get things working on an arcade monitor, hopefully the X Windows version and the 2.6.37-rc1 play together well.

I sort of plugged in that function to replace the horizontal values in the modeline after the vertical ones are created with lrmc.  It does align things back up horizontally but I now see that partly the original modeline values for the custom one I'm doing have the too small across the screen issue.  I will look more at your code and try to get the vertical calculation stuff figured out to go along with it, so possibly can fully escape the need for lrmc.  I'm right now just dividing up the range of horizontal freq seeing that there's about 8 between like 15 - 23 and between 23 - 31 and 31 - 37, roughly at least, and so having a 8 Khz range centered on each of those 15-19,20-27,28-35,36-40 values for now seems to work from what I can tell.

Also when I calculate, it gives a new total horizontal lines, and I'm finding that if I recalculate the dotclock and use that it still matches the vertical refresh I was aiming at.  Is that normal, and expected, or will it probably only match correctly if I start doing the vertical calculations with the horizontal ones (or is that another part of your code, shifting around the dotclock to adjust that vertical refresh rate).  Looks exciting though, glad to start seeing some of the calculating able to happen outside lrmc, even though lrmc is doing pretty good this has much more potential actually using the monitors values and building a database of different monitor values would be interesting.     
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: Calamity on November 08, 2010, 10:39:17 am
Also when I calculate, it gives a new total horizontal lines, and I'm finding that if I recalculate the dotclock and use that it still matches the vertical refresh I was aiming at.  Is that normal, and expected, or will it probably only match correctly if I start doing the vertical calculations with the horizontal ones (or is that another part of your code, shifting around the dotclock to adjust that vertical refresh rate).  Looks exciting though, glad to start seeing some of the calculating able to happen outside lrmc, even though lrmc is doing pretty good this has much more potential actually using the monitors values and building a database of different monitor values would be interesting.     

It's a must to recalculate the dotclock to match the vfreq you was aiming at the beginning, otherwise the hfreq premise used by the above function wouldn't be right (as vfreq and hfreq are related). Vertical porches and pulses are not affected by this.

The logic I use is this:

Calculate vertical values from required Vfreq -> total number of lines (Hfreq) -> horizontal values (Htotal) -> dotclock

Actual calculations for the whole modeline are more straight-forward than the ones I do in my modeline function, that is a bit twisted to account for an issue with actual dotclocks that cannot adopt any value we imagine, but only some discrete ones, that I keep in a table, however you may ignore this by now and build the modeline function without that, as it is only there to improve accuracy. Later today I'll paste the function with some comments to explain it.

Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: Calamity on November 08, 2010, 05:17:14 pm
This is the function I use, I've added some comments:

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, interlace, margen, DotClockIdx AS LONG
  LOCAL hhh, hhi, hhf, hht, newHhh, newHhi, newHhf, newHht, vvv, vvi, vvf, vvt, vIncr, vfreqLabel AS LONG
  LOCAL hfreq, Dotclock, DotclockReq, vvtIni, VBlankLines, diff, newDiff, newVfreq, hfreqReal, vfreqReal AS SINGLE

' We set default 'interlace' to 1 (no interlace). When set to 2 it means interlace is on. I use these values as they are
' useful for calculations, instead of 0, 1.

  INCR interlace

' This part is just to filter max and min resolutions, hfreq and vfreq values to keep them inside our monitor limits.
' It also handles vertical games (rotated resolutions). But its focused on lowres monitors with some hardcoded conditionals,
' so you may want to modify things to adapt it to multifrequency monitors. However, this should better be kept outside
' this function.

  IF xres < XresMin THEN xres = XresMin : result = result OR %SimilarRes
  IF yres < YresMin THEN yres = YResMin : result = result OR %SimilarRes

  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

' here we start calculating an estimation of hfreq required for the mode, and check if it exceeds our monitor's limits.

  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

' Now, we need to know the minimum integer number of total lines needed to produce a mode that matches vfreq within
' our hfreq limits (vvtIni)

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

' Next block is used to get horizontal values and dotclock. This version uses an iterated loop and a dotclock table for
' accuracy, but it's not necessary and can be simplified like this (not tested):
'
'   hfreq = vfreq * vvtIni
'   ModelineGetLineParams ( hfreq, xres, Hhh, Hhi, Hhf, Hht )
'   DotClockReq = hfreq * Hht
'
' (notice hfreq is recalculated here from our integer vvtIni)

  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

' Now we calculate the number of lines needed for vertical blanking. VerticalBlank is the time in µs our monitor needs
' to complete it's vertical retrace (front and back porches + sync pulses). I use 1280 µs for TVs and lowres monitors.
' Notice the 0.5 increment in case of interlace: this is used to make sure that vvt will be an uneven value if the mode
' is interlaced, otherwise our timings would be wrong as all interlaced modes have an uneven number of lines despite
' we set vvt as an even number.

  VBlankLines = INT ( hfreq * VerticalBlank ) + IIF ( interlace = 2, 0.5, 0 )

' Now we work out the vertical part of the modeline (forget about vIncr). We start with vvt and substract vvv and Vblanklines
' The rest is considered as fill in margins needed to achive the required vfreq, and we divide then by 2 (up and down margins
' are equal.
' For the sync pulse, 3 and 5 lines long pulses are hardcoded (progressive or interlaced) according to PAL standard, however
' this should be checked for higher frequencies
' Notice all calculations have beed done as 'progressive', and here we use the 'interlace' multiplier to get the right
' values in case of interlace

  vvv = yres
  vvt = ( vvtIni + vIncr ) * interlace
  margen = vvt - vvv - VBlankLines * interlace
  vvi = vvv + ROUND ( margen / 2, 0 ) + 1 * interlace
  vvf = vvi + IIF ( interlace = 2, 5, 3 )

' That's all, the rest is for storing values, etc.

  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
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: bitbytebit on November 08, 2010, 05:43:25 pm
This is the function I use, I've added some comments:

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, interlace, margen, DotClockIdx AS LONG
  LOCAL hhh, hhi, hhf, hht, newHhh, newHhi, newHhf, newHht, vvv, vvi, vvf, vvt, vIncr, vfreqLabel AS LONG
  LOCAL hfreq, Dotclock, DotclockReq, vvtIni, VBlankLines, diff, newDiff, newVfreq, hfreqReal, vfreqReal AS SINGLE

' We set default 'interlace' to 1 (no interlace). When set to 2 it means interlace is on. I use these values as they are
' useful for calculations, instead of 0, 1.

  INCR interlace

' This part is just to filter max and min resolutions, hfreq and vfreq values to keep them inside our monitor limits.
' It also handles vertical games (rotated resolutions). But its focused on lowres monitors with some hardcoded conditionals,
' so you may want to modify things to adapt it to multifrequency monitors. However, this should better be kept outside
' this function.

  IF xres < XresMin THEN xres = XresMin : result = result OR %SimilarRes
  IF yres < YresMin THEN yres = YResMin : result = result OR %SimilarRes

  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

' here we start calculating an estimation of hfreq required for the mode, and check if it exceeds our monitor's limits.

  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

' Now, we need to know the minimum integer number of total lines needed to produce a mode that matches vfreq within
' our hfreq limits (vvtIni)

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

' Next block is used to get horizontal values and dotclock. This version uses an iterated loop and a dotclock table for
' accuracy, but it's not necessary and can be simplified like this (not tested):
'
'   hfreq = vfreq * vvtIni
'   ModelineGetLineParams ( hfreq, xres, Hhh, Hhi, Hhf, Hht )
'   DotClockReq = hfreq * Hht
'
' (notice hfreq is recalculated here from our integer vvtIni)

  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

' Now we calculate the number of lines needed for vertical blanking. VerticalBlank is the time in µs our monitor needs
' to complete it's vertical retrace (front and back porches + sync pulses). I use 1280 µs for TVs and lowres monitors.
' Notice the 0.5 increment in case of interlace: this is used to make sure that vvt will be an uneven value if the mode
' is interlaced, otherwise our timings would be wrong as all interlaced modes have an uneven number of lines despite
' we set vvt as an even number.

  VBlankLines = INT ( hfreq * VerticalBlank ) + IIF ( interlace = 2, 0.5, 0 )

' Now we work out the vertical part of the modeline (forget about vIncr). We start with vvt and substract vvv and Vblanklines
' The rest is considered as fill in margins needed to achive the required vfreq, and we divide then by 2 (up and down margins
' are equal.
' For the sync pulse, 3 and 5 lines long pulses are hardcoded (progressive or interlaced) according to PAL standard, however
' this should be checked for higher frequencies
' Notice all calculations have beed done as 'progressive', and here we use the 'interlace' multiplier to get the right
' values in case of interlace

  vvv = yres
  vvt = ( vvtIni + vIncr ) * interlace
  margen = vvt - vvv - VBlankLines * interlace
  vvi = vvv + ROUND ( margen / 2, 0 ) + 1 * interlace
  vvf = vvi + IIF ( interlace = 2, 5, 3 )

' That's all, the rest is for storing values, etc.

  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

This is great, I've been actually digging through that code today and so this is perfect and on time to help me figure out the deeper details of the interlacing and limits issues when out of bounds.  I've gotten the basic calculating working when the v/h freq's are in range and interlacing isn't required, screen sizes are in range, and it definitely is really looking amazing compared with lrmc.  I can actually calculate the resolution for mario brothers to exact original everything and it fills the screen and is perfect, never could do that with lrmc.

One question I have, have you any ideas how to also put in doublescan support, I can figure things out probably from looking at lrmc and seeing the difference between it and interlace.  From what I can tell you haven't got doublescan support in there, so I may try to add it for the games with 192 vertical resolutions.  Also I am figuring when things go into VGA/SVGA areas then there may be some issues there, but I am guessing the -Vsync and -Hsync are changed to be positive possibly when encountering a certain threshhold.

I so far have a pretty good perl hash and config format it reads to have one or more lines of the monitor parameters, ranges so with the d9800 I can have 4 ranges and have a basic way of going through and figuring out which range to use and starting to tie that into your checks to adapt to a d9800 monitor or other multi range ones.  I take it that the vertical front porch/sync/back porch values are really not necessary, so can throw those out or is there some use for them down the road to be extra accurate?  Sounds like your defaults then would work for most arcade monitors and then for ones with special needs or the d9800 that's where these config lines added with multiple ranges can be used.

Thanks again for all this information, hopefully have something in a few days at most, also hopefully have these ubuntu kernel packages built in a day or so.  They take forever to build, lots of modules.  I think I got it so it'll default to arcade mode when a monitor has no EDID so should make it easier to install and the grub.cfg editing for the video=640x480c line won't hopefully be as important or possibly not needed.  There will be a necessary module options config file though to turn off polling of the monitor, since that just makes the system slow from the arcade monitor lacking an EDID and it constantly harrassing it for one.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: bitbytebit on November 09, 2010, 02:03:44 am
I have ubuntu kernel builds for 64 bit and 32 bit on the sourceforge project site now.  These are needing testing, I'm not sure how well they'll work but you'll definitely need to use the radeon.conf modprobe settings in the switchres.zip archive.  That file needs to be put into /etc/modprobe.d/, to stop polling.  Then I think by default it'll use 640x480 interlaced in arcade monitor compatible resolution, but if not it needs the /boot/grub/grub.cfg file to use the "video=640x480c" arg on the command line for the kernel.  When installing these, they will make themselves the default choice in the grub boot menu, but can choose the old kernel and uninstall them if they don't work.  Let me know how they work, hopefully they work right for the 32bit one and there's no other necessary config options that ubuntu uses (used the default config so would guess it's the same as their kernel, but sometimes distros get sort of customized builds unfortunately).

I have just about gotten the basic modeline generation being done in perl too, Thanks to Calamity for giving me the information/code for that to be possible.  It's definitely looking amazing, compared to what lrmc was doing, seems to be generating almost perfect modelines.  I've got it able to take the monitor parameters in the switchres.conf config but defaults to basic arcade monitor settings.  Would only need to set those I think if you have a d9800 or something, which I've got a default switchres.conf example file showing what is necessary.

So next release of switchres will definitely be a bit 'beta' testing, can still use lrmc with a command line option, but by default it now uses it's own perl logic to do the modeline stuff and will no longer need to worry about lrmc at all.  Hopefully I get that up here in a bit, I think it's ready but need to edit the readme files a little probably.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .18)
Post by: bitbytebit on November 09, 2010, 02:34:23 am
Version 0.18 - Dropped need for lrmc and Ubuntu kernel packages available
* Thanks to Calamity switchres no longer needs lrmc and generates modelines itself, which are way better than lrmc ever did.
* Now can output modelines just with switchres on the command line, like "switchres -calc 320 240 60.00" or for a specific game in mame "switchres -calcgame galaga".
* With new modeline creation, if you have anything more than an ordinary arcade monitor you'll need to put the specific parameters into the ~/switchres.conf file.  There's an example file included in the extras directory.
* Generally seems to produce a lot better results than before, can get exact resolutions now instead of rather odd ones that lrmc would produce.  With a d9800 monitor I can almost perfectly get every games resolution and refresh rate to exact specs.  I never could do that with lrmc.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: elvis on November 09, 2010, 04:50:41 am
I'll look into building a patched ubuntu kernel package.  
Install a package called "kernel-package" and then read the man file on "kpkg".  It makes building custom kernel packages a piece of cake.

I'm sure there's an equivalent in RPM-based distros, but kpkg is the way to go in Debian, Ubuntu and the various derivatives.

Thanks! I'll have a look at this!


I've actually just built a ubuntu kernel package last night, it's for amd64 though and I'm now trying to figure out how to cross compile one for 32 bit processors. 

I made a mistake above.  You want to run "man make-kpkg".

In there you'll find a flag called "--cross-compile" which will do exactly what you want.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: Calamity on November 09, 2010, 06:22:42 am
It's great you managed to get this working on a multrifrequency monitor! It's such a nice feeling when you know you're directly driving the electron beam ;)

I take it that the vertical front porch/sync/back porch values are really not necessary, so can throw those out or is there some use for them down the road to be extra accurate?  Sounds like your defaults then would work for most arcade monitors and then for ones with special needs or the d9800 that's where these config lines added with multiple ranges can be used.

Vertical porch/sync values you have are good to avoid hardcoding that 1280 µs value I use, which I took from this book (highly recommended):

http://books.google.es/books?id=u-3oFBzrQ0sC&pg=PA49&lpg=PA49&dq=fly-back+time+ms++tv+sync&source=bl&ots=PKl_u_8HKn&sig=l7S_AYEtoenKFEU0TnUzlNNOvhg&hl=es&ei=pd9lSsvyOYeenQOe9rXaDQ&sa=X&oi=book_result&ct=result&resnum=1#v=onepage&q&f=false (http://books.google.es/books?id=u-3oFBzrQ0sC&pg=PA49&lpg=PA49&dq=fly-back+time+ms++tv+sync&source=bl&ots=PKl_u_8HKn&sig=l7S_AYEtoenKFEU0TnUzlNNOvhg&hl=es&ei=pd9lSsvyOYeenQOe9rXaDQ&sa=X&oi=book_result&ct=result&resnum=1#v=onepage&q&f=false)

For instance, let us work out the values for your monitor's Mode 1. The ones we're interested in are B (sync pulse), C (back porch) and E (front porch). We'll convert the timings into lines:

B = 191 µs = 3 * 63.594 (length of a line) -> 3 lines
C = 190 µs = 3 * 63.594 (length of a line) -> 3 lines
E = 1018 µs = 16 * 63.594 (length of a line) -> 16 lines

VerticalBlank = 191 + 190 + 1018 = 1399 µs -> 22 lines

The same can be done for the rest of modes.
(it seems to me C and E values are swaped in that table but it does not matter now)*

In many modes, you may want to add extra lines to delay the video and get a lower vertical refresh that matches the one you want, those extra lines are the one I add like margins to C and E.

You may have notice that this is an ideal case, and as we move from that reference mode the length of the lines (in time) will vary slightly. As we can only use integers for the number of lines, we must check that the above values are respected, to do things right. However, I used hardcoded number of lines for vertical sync pulses as they are constant in the practical situations I've been working with, but in order to make this extensive for more monitors this should be done properly.

I unfortunately dropped doublescan support in my code because I never got it working with Catalyst drivers. However, I believe the only thing that needs to be done is to double the required dotclock for a single scan mode, and do all calculations as progressive (the modeline will be the same as if it was single scan, we just need to do DotClock * 2, and bear this in mind when we compute Vfreq, otherwise we would get Vfreq * 2 too).

By the way, did you check if those positive polarities in some modes are really needed or just recommended?

* Normally, vertical front porch, the one before sync pulse and right after visible video, is as short as one line, as we just need a small delay before we send the sync pulse to make the beam return to the top of the screen. On the other hand, back porch needs to be longer, because once the beam reaches the top it needs some time to stabilize itself before we can start drawing again.
Title: Re: Genres modeline generator and switchres dynamic modeline switcher (ver .17)
Post by: bitbytebit on November 10, 2010, 12:38:39 pm
It's great you managed to get this working on a multrifrequency monitor! It's such a nice feeling when you know you're directly driving the electron beam ;)

I take it that the vertical front porch/sync/back porch values are really not necessary, so can throw those out or is there some use for them down the road to be extra accurate?  Sounds like your defaults then would work for most arcade monitors and then for ones with special needs or the d9800 that's where these config lines added with multiple ranges can be used.

Vertical porch/sync values you have are good to avoid hardcoding that 1280 µs value I use, which I took from this book (highly recommended):

http://books.google.es/books?id=u-3oFBzrQ0sC&pg=PA49&lpg=PA49&dq=fly-back+time+ms++tv+sync&source=bl&ots=PKl_u_8HKn&sig=l7S_AYEtoenKFEU0TnUzlNNOvhg&hl=es&ei=pd9lSsvyOYeenQOe9rXaDQ&sa=X&oi=book_result&ct=result&resnum=1#v=onepage&q&f=false (http://books.google.es/books?id=u-3oFBzrQ0sC&pg=PA49&lpg=PA49&dq=fly-back+time+ms++tv+sync&source=bl&ots=PKl_u_8HKn&sig=l7S_AYEtoenKFEU0TnUzlNNOvhg&hl=es&ei=pd9lSsvyOYeenQOe9rXaDQ&sa=X&oi=book_result&ct=result&resnum=1#v=onepage&q&f=false)

For instance, let us work out the values for your monitor's Mode 1. The ones we're interested in are B (sync pulse), C (back porch) and E (front porch). We'll convert the timings into lines:

B = 191 µs = 3 * 63.594 (length of a line) -> 3 lines
C = 190 µs = 3 * 63.594 (length of a line) -> 3 lines
E = 1018 µs = 16 * 63.594 (length of a line) -> 16 lines

VerticalBlank = 191 + 190 + 1018 = 1399 µs -> 22 lines

The same can be done for the rest of modes.
(it seems to me C and E values are swaped in that table but it does not matter now)*

In many modes, you may want to add extra lines to delay the video and get a lower vertical refresh that matches the one you want, those extra lines are the one I add like margins to C and E.

You may have notice that this is an ideal case, and as we move from that reference mode the length of the lines (in time) will vary slightly. As we can only use integers for the number of lines, we must check that the above values are respected, to do things right. However, I used hardcoded number of lines for vertical sync pulses as they are constant in the practical situations I've been working with, but in order to make this extensive for more monitors this should be done properly.

I unfortunately dropped doublescan support in my code because I never got it working with Catalyst drivers. However, I believe the only thing that needs to be done is to double the required dotclock for a single scan mode, and do all calculations as progressive (the modeline will be the same as if it was single scan, we just need to do DotClock * 2, and bear this in mind when we compute Vfreq, otherwise we would get Vfreq * 2 too).

By the way, did you check if those positive polarities in some modes are really needed or just recommended?

* Normally, vertical front porch, the one before sync pulse and right after visible video, is as short as one line, as we just need a small delay before we send the sync pulse to make the beam return to the top of the screen. On the other hand, back porch needs to be longer, because once the beam reaches the top it needs some time to stabilize itself before we can start drawing again.


I don't think the polarity values matter, at least up through VGA modes, in SVGA mode I think they might not matter but it might be a slightly better display with them positive.

I am trying to plug in those vertical values and it's odd, because basically when I use those I get the margen value less than 0, like -2 or more and it causes the whole calculation to get off and output is wider than it should be.  It's odd because it's a difference of .00128 vs .001399 or something and that seems to totally throw it off.  I'm still checking that, seeing why it's happening and if I'm missing something.  Also it's kind of tricky in the multi frequency case to use those, because the first calculation doesn't know which range it'll use, although in the cases I'm testing it's always the first CGA range anyways.  You values seem to be pretty much perfect that you used/hardcoded, always work great besides possibly a few lines too low in the 288 line high pacman case although all other games are perfect.

I'm wondering if there's  a bit more I'm missing needed to calculate the vertical values, than just changing that main verticalblank value.

Also doublescan support doesn't seem as important as I had thought, although still interested in it.  I now can get the native 192 high line resolutions which before lrmc wouldn't even do without using doublescan.  Although I think in other monitor types and possibly to get things a bit better in a few resolutions doublescan support would be good.  I'm still wanting to look into that, did a little, will have to start doing some tests and see if I can find how to put it into the logic of the calculations.

I'm making it so the -mon argument works again and can avoid having to put monitor details into the config unless it's not known already by the program, so will be more user friendly at least if it's a known monitor type.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .18)
Post by: bitbytebit on November 10, 2010, 04:38:19 pm
I think I somewhat figured out how to use the vertical timing values, required a bit more work but now actually improved the way things are calculated when having multiple ranges to check against.  I had to do some tricky moving of the checking of stuff, so that those values can be used to jumpstart the first calculations and think I figured out how to use them to calculate out the rest of the vertical modeline values.  It seems to be working, and centering the vertical picture now as well as it is centering the horizontal.  Do you know the timings of the vertical for other arcade monitors I could plug in and test with, I'm going to look around for some other values to see what they do to the modeline.  Part of the issue I think I had was, besides having to calculate the total lines with those values and starting hfreq value, was not running each of those line number values through int() so they were adding up too large of total lines.  From what I could tell I had 2 lines too much and that seemed to fix it when I ran each of the 3 values for the vertical lines through the int() function.

This is definitely interesting since by doing this I'm having to go through the entire logic of that and fully/somewhat understand it, quite interesting stuff.  I'm pretty amazed at your virtualize function just seeing what it can do when I limit calculations to CGA specs and use it on my monitor, haven't looked at it too deeply but seems to do the job really well at getting the best resolution to expand/shrink the game into.  Much nicer than what I did originally at just trying 640x480 or some other things I tried similar but never got these kind of results.  I also am amazed at how complicated lrmc makes this stuff and how actually way off it is to the desired target compared to your methods.


Also I just did a test, and the positive polarity values for vsync/hsync do matter actually in higher resolutions like 800x600 on the d9800. Without those the picture gets a bit wavy on the edge.  Also the monitor really doesn't like anything above 38Khz horizontal, else it's curved in like an hourglass on one side.  Basically following the specs they used for 800x600 on the data sheet, it is nice at 60Hz vertical and 37.8Khz horizontal, also the calculations are very nice for SVGA so your stuff does work for this.  When I use the specs for vertical from the sheet it uses the 37Khz horizontal and looks square, when I don't and use the generic verticalblank it goes up to 39Khz and starts getting the curve inward.  So I'm suspecting that means I'm somewhat using these vertical timings right, at least seems to make it act right for SVGA mode.


Just to double check, here's the code where I'm setting up the vertical values, I'm not sure the interlaced case works exactly the same for the second vertical value on the modeline.  Your using 5 when interlaced and 3 when not, what should I do and am I doing the other numbers right (seems to center it vertically, guessing it's correct from that)...
Code: [Select]
       
        if ($HaveVerTiming) {
                $LineTime = 1.0 / ( $newDC / $newHt ) * 1000000;
                $B = int(($VFP*1000)/$LineTime);
                $C = int(($VSP*1000)/$LineTime);
                $E = int(($VBP*1000)/$LineTime);
                if ($VERBOSE > 1) {
                        print "Linetime=$LineTime B=$B C=$C E=$E Lines=" . int(($B + $C + $E)+0.5) . "\n";
                }

                $VBlankLines = int($HFreq * $VerticalBlank);
                if ($interlace == 2) {
                        $VBlankLines += 0.5;
                }
                my $margen = $vtotal - $va - $VBlankLines * $interlace;
                if ($VERBOSE > 1) {
                        print "Using VBlankLines: $VBlankLines with Margen: $margen ($vtotal - $va - $VBlankLines * $interlace) to calculate Vblanking\n";
                }

                $vb = $va + $B + (int(($margen / 2)+0.5) + 1 * $interlace);
                $vc = int($vb+$C);
        } else {
                $VBlankLines = int($HFreq * $VerticalBlank);
                if ($interlace == 2) {
                        $VBlankLines += 0.5;
                }
                my $margen = $vtotal - $va - $VBlankLines * $interlace;
                if ($VERBOSE > 1) {
                        print "Using VBlankLines: $VBlankLines with Margen: $margen ($vtotal - $va - $VBlankLines * $interlace) to calculate Vblanking\n";
                }

                $vb = $va + int(($margen / 2)+0.5) + 1 * $interlace;
                $vc = $vb;
                if ($interlace == 2) {
                        $vc += 5;
                } else {
                        $vc += 3;
                }
        }

Also here's the whole function now, with the logic changed...
Code: [Select]
sub get_modeline() {
        my $OriginalWidth = shift(@_);
        my $OriginalHeight = shift(@_);
        my $OriginalRefresh = shift(@_);
        my @flags = ();
        my $PHSYNC = 0;
        my $PVSYNC = 0;
        my $ha = 0;
        my $hb = 0;
        my $hc = 0;
        my $htotal = 0;
        my $va = 0;
        my $vb = 0;
        my $vc = 0;
        my $vtotal = 0;
        my $ModeName = "";
        my $DotClock = 0;
        my $ModeNum = -1;
        my $ModeBase = 0;
        my $interlace = 1;
        my $doublescan = 1;
        my $VBlankLines = 0;
        my $HfreqTolerance = 0.010 * 1000;
        my $HFreq = 0;
        my $LineTime = 0;
        my ($B, $C, $E);
        my $HaveVerTiming = 0;
        my $output = "";
        my ($newDC, $newHh, $newHi, $newHf, $newHt);
        my $VT = 0;

        # Check width/height restrictions
        if ($OriginalWidth < $XresMin) {
                $OriginalWidth = $XresMin;
        }
        if ($OriginalHeight < $YresMin) {
                $OriginalHeight = $YresMin;
        }

        # Check vertical refresh limits
        if ($OriginalRefresh < $MonitorModes[$ModeBase]{'VfreqMin'}) {
                if ((2 * $OriginalRefresh) <= $MonitorModes[$ModeBase]{'VfreqMax'}) {
                        $OriginalRefresh *= 2;
                } else {
                        $OriginalRefresh = $MonitorModes[$ModeBase]{'VfreqMin'};
                }
        } elsif ($OriginalRefresh > $MonitorModes[$ModeBase]{'VfreqMax'}) {
                $OriginalRefresh = $MonitorModes[$ModeBase]{'VfreqMax'};
        }

        if ($OriginalHeight > $ActiveLinesLimit) {
                $interlace = 2;
                if ($OriginalHeight < $VirtualLinesLimit) {
                        my $line = ResVirtualize($OriginalWidth, $OriginalHeight, $OriginalRefresh, $HFreq);
                        ($OriginalWidth, $OriginalHeight, $OriginalRefresh, $HFreq) = split(/\s/, $line);
                        if ($VERBOSE > 0) {
                                print "Height more than active lines limit!!!\n";
                        }
                }
        }

        # Find most fitting mode to begin with
        for (my $i = $ModeBase; $i < scalar(@MonitorModes); $i++) {
                if ($USE_VTIME && $MonitorModes[$ModeBase]{'VFrontPorch'} && $MonitorModes[$ModeBase]{'VSyncPulse'} && $MonitorModes[$ModeBase]{'VBackPorch'}) {
                        $HaveVerTiming = 1;
                        $FP = $MonitorModes[$ModeBase]{'HFrontPorch'};
                        $SP = $MonitorModes[$ModeBase]{'HSyncPulse'};
                        $BP = $MonitorModes[$ModeBase]{'HBackPorch'};
                        $VFP = $MonitorModes[$ModeBase]{'VFrontPorch'};
                        $VSP = $MonitorModes[$ModeBase]{'VSyncPulse'};
                        $VBP = $MonitorModes[$ModeBase]{'VBackPorch'};
                        $VerticalBlank = int((($VFP * 1000) + ($VSP * 1000) + ($VBP * 1000))+0.5) / 1000000;
                }

                $HFreq = int($OriginalRefresh * $OriginalHeight / ($interlace * (1.0 - $OriginalRefresh * $VerticalBlank )));

                # Check minimum horizontal frequency
                if($HFreq < $MonitorModes[$ModeBase]{'HfreqMin'}) {
                        my $old_HFreq = $HFreq;
                        $HFreq = $MonitorModes[$ModeBase]{'HfreqMin'};
                        if ($VERBOSE > 0) {
                                print "Warning: Raised horizontal frequency from " .
                                        sprintf("%.3f", ($old_HFreq/1000)) . "Khz to " . sprintf("%.3f", ($HFreq/1000)) . "Khz\n";
                        }
                }

                if (($HFreq >= $MonitorModes[$i]{'HfreqMin'}) &&
                     ($HFreq <= $MonitorModes[$i]{'HfreqMax'}) &&
                      ($OriginalRefresh >= $MonitorModes[$i]{'VfreqMin'}) &&
                       ($OriginalRefresh <= $MonitorModes[$i]{'VfreqMax'})) {
                                if ($VERBOSE > 0) {
                                        print "horizontal frequency " . sprintf("%.3f", ($HFreq/1000)) .
                                                "Khz matches monitor mode number $i: " .
                                                sprintf("%.3f", ($MonitorModes[$i]{'HfreqMin'}/1000)) . "Khz - " .
                                                sprintf("%.3f", ($MonitorModes[$i]{'HfreqMax'}/1000)) . "Khz\n";
                                }
                                $HfreqMin = $MonitorModes[$i]{'HfreqMin'};
                                $HfreqMax = $MonitorModes[$i]{'HfreqMax'};
                                $VfreqMin = $MonitorModes[$i]{'VfreqMin'};
                                $VfreqMax = $MonitorModes[$i]{'VfreqMax'};
                                $DotClockMin = $MonitorModes[$i]{'DotClockMin'};
                                $DotClockMax = $MonitorModes[$i]{'DotClockMax'};
                                $FP = $MonitorModes[$i]{'HFrontPorch'};
                                $SP = $MonitorModes[$i]{'HSyncPulse'};
                                $BP = $MonitorModes[$i]{'HBackPorch'};
                                $VFP = $MonitorModes[$i]{'VFrontPorch'};
                                $VSP = $MonitorModes[$i]{'VSyncPulse'};
                                $VBP = $MonitorModes[$i]{'VBackPorch'};
                                $PHSYNC = $MonitorModes[$i]{'HsyncPolarity'};
                                $PVSYNC = $MonitorModes[$i]{'VsyncPolarity'};
                                if ($USE_VTIME && $VFP && $VSP && $VBP) {
                                        $HaveVerTiming = 1;
                                        $VerticalBlank = int((($VFP * 1000) + ($VSP * 1000) + ($VBP * 1000))+0.5) / 1000000;
                                } else {
                                        $HaveVerTiming = 0;
                                }
                                $ModeNum = $i;
                                goto GOOD_MODE;
                }

                if ($ModeBase < (scalar(@MonitorModes)-1)) {
                        $ModeBase++;
                }
        }
        GOOD_MODE:
        if ($VERBOSE > 1) {
                print "Calculated vertical blanking to be $VerticalBlank using mode $ModeBase\n";
        }

        # Check if horizontal frequency is above maximum allowed
        if($HFreq > $MonitorModes[$ModeBase]{'HfreqMax'}) {
                if ($OriginalHeight > $ActiveLinesLimit) {
                        my $line = ResVirtualize($OriginalWidth, $OriginalHeight, $OriginalRefresh, $HFreq);
                        ($OriginalWidth, $OriginalHeight, $OriginalRefresh, $HFreq) = split(/\s/, $line);
                        $interlace = 2;
                        if ($VERBOSE > 0) {
                                print "HFreq greater than monitor allows!!!\n";
                        }
                } else {
                        my $oldhf = $HFreq;
                        my $oldvr = $OriginalRefresh;
                        $HFreq = $MonitorModes[$ModeBase]{'HfreqMax'};
                        $VBlankLines = int(($HFreq * $VerticalBlank)+0.5);
                        $OriginalRefresh = $HFreq / ( $OriginalHeight / $interlace + $VBlankLines );
                        if ($VERBOSE > 0) {
                                print "Lowered Hfreq from $oldhf to $HFreq and VRefresh from $oldvr to $OriginalRefresh\n";
                        }
                }
        }

        # Calculate total vertical lines
        if ($HaveVerTiming) {
                # Find horizontal modeline values
                $output = ModelineGetLineParams($HFreq, $OriginalWidth, $FP, $SP, $BP);
                ($newDC, $newHh, $newHi, $newHf, $newHt) = split(/\s/, $output);
                $LineTime = 1.0 / ( $newDC / $newHt ) * 1000000;
                $B = int(($VFP*1000)/$LineTime);
                $C = int(($VSP*1000)/$LineTime);
                $E = int(($VBP*1000)/$LineTime);
                $VT = int(($OriginalHeight+$B+$C+$E)+0.5);
                if ($VERBOSE > 1) {
                        print "Linetime=$LineTime B=$B C=$C E=$E Lines=" . int(($B + $C + $E)+0.5) . "\n";
                }
        } else {
                # Total vertical lines
                $VT = int(($HFreq / $OriginalRefresh)+0.5);
        }
        if ($interlace == 2) {
                $VT += 0.5;
        }
        # If below minimum horizontal refresh increment vertical lines till it isn't
        while (($OriginalRefresh * $VT) < ($MonitorModes[$ModeBase]{'HfreqMin'})) {
                $VT++
        }
        # Horizontal frequency recalculation
        $HFreq = int(($OriginalRefresh * $VT)+0.5);
        if ($VERBOSE > 0) {
                print "Using $VT vertical lines with " . sprintf("%.3f", ($HFreq/1000)) . "Khz horizontal frequency.\n";
        }
        if ($ModeNum < 0) {
                print "ERROR: ($ModeNum) No mode setting in config matches required monitor hfreq $HFreq and vfreq $OriginalRefresh!!!\n";
                exit 1;
        }

        # Find horizontal modeline values
        $output = ModelineGetLineParams($HFreq, $OriginalWidth, $FP, $SP, $BP);
        ($newDC, $newHh, $newHi, $newHf, $newHt) = split(/\s/, $output);

        # Calculate modeline values
        $DotClock = sprintf("%.6f", $newDC / 1000000);
        $ha = $OriginalWidth;
        $hb = $newHi;
        $hc = $newHf;
        $htotal = $newHt;
        $va = $OriginalHeight;
        $vtotal = $VT * $interlace;
        $ModeName = "\"${ha}x${va}\"";

        if ($HaveVerTiming) {
                $LineTime = 1.0 / ( $newDC / $newHt ) * 1000000;
                $B = int(($VFP*1000)/$LineTime);
                $C = int(($VSP*1000)/$LineTime);
                $E = int(($VBP*1000)/$LineTime);
                if ($VERBOSE > 1) {
                        print "Linetime=$LineTime B=$B C=$C E=$E Lines=" . int(($B + $C + $E)+0.5) . "\n";
                }

                $VBlankLines = int($HFreq * $VerticalBlank);
                if ($interlace == 2) {
                        $VBlankLines += 0.5;
                }
                my $margen = $vtotal - $va - $VBlankLines * $interlace;
                if ($VERBOSE > 1) {
                        print "Using VBlankLines: $VBlankLines with Margen: $margen ($vtotal - $va - $VBlankLines * $interlace) to calculate Vblanking\n";
                }

                $vb = $va + $B + (int(($margen / 2)+0.5) + 1 * $interlace);
                $vc = int($vb+$C);
        } else {
                $VBlankLines = int($HFreq * $VerticalBlank);
                if ($interlace == 2) {
                        $VBlankLines += 0.5;
                }
                my $margen = $vtotal - $va - $VBlankLines * $interlace;
                if ($VERBOSE > 1) {
                        print "Using VBlankLines: $VBlankLines with Margen: $margen ($vtotal - $va - $VBlankLines * $interlace) to calculate Vblanking\n";
                }

                $vb = $va + int(($margen / 2)+0.5) + 1 * $interlace;
                $vc = $vb;
                if ($interlace == 2) {
                        $vc += 5;
                } else {
                        $vc += 3;
                }
        }

        # flags
        if ($PHSYNC) {
                push @flags, "+HSync";
        } else {
                push @flags, "-HSync";
        }

        if ($PVSYNC) {
                push @flags, "+VSync";
        } else {
                push @flags, "-VSync";
        }

        # Check for interlace
        if ($interlace == 2) {
                push @flags, "interlace";
        } elsif ($doublescan == 2) {
                push @flags, "doublescan";
        }

        $MODELINE = "$ModeName $DotClock $ha $hb $hc $htotal $va $vb $vc $vtotal @flags";

        if ($VERBOSE > 1) {
                print "New modeline with hfreq: $HFreq refresh: " . (($DotClock*1000000) / ($htotal * $vtotal)) . "\n $MODELINE\n";
        }
        return $MODELINE;
}



Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .18)
Post by: Calamity on November 10, 2010, 07:26:11 pm
These vertical elements can't be very accurate because of the integer issue (you've seen how the key to properly calculate things is always manage integer elements). What's important is the total sum of front/back porches + sync. I've checked my code and the vertical part is really hardcoded for low resolutions I'm afraid. It's assuming front porch is always one line and sync pulses 3/5, leaving the rest for back porch. This actually means:

*progressive:

front porch : 1.5 lines -> rounded to 1 line -> 64 µs
sync pulse: 2.5 lines -> rounded to 3 lines -> 192 µs
back porch: 16 lines -> 16 lines -> 1024 µs
VerticalBlank: 20 lines -> 1280 µs

*interlaced:

front porch : 3(/2) lines -> 96 µs
sync pulse: 5(/2) lines  -> 160 µs
back porch: 33(/2) lines -> 1088 µs
VerticalBlank: 41(/2) lines -> 1344 µs

(this values can be used to support Hantarex MTC 9110 as they should produce the same modelines I am doing. Interlaced values are not the actual used right now but they should be. I'll have a look at this)

So that 3/5 are because TV standars consider sync pulse as 2.5 lines long, so 3 is for the rounding, and 5 because by do multiply by 2 when we interlace. So, the code can be made more generic by calculating these from the above values in µs, for any monitor type. Bear in mind that as we move from the reference mode line lenths change so to do things perfect this must be considered and that's why it's not really correct to precalculate a fixed table with line numbers for vertical porchs/sync or hardcode the values as I was doing.

I've seen your code and the logic looks good. I had imagined another way to deal with multisync monitors as I explained some posts above, by considering each interval/mode as a separate virtual monitor and produce as many versions of each modeline as virtual monitors, and have a system to rate them to choose the best one. For instance, if you ask for 640x480 and use the CGA mode, it will produce an interlaced res (bad rate), after that you use VGA mode and the modeline will be progressive, with a better rate obtained so we select the second. That is all that 'result' stuff about. This was intended for dealing with monitors that have separate hfreq intervals with gaps in the middle, which seems it's not the case with d9800. However, your method seems just as good.

I have to go now, hopefully tomorrow I have some time to look at this and comment. I'm really happy you managed to get this stuff working. I've devoted a lot of hours to think how these calculations should be done, it's incredible how quickly you've figured all of it.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .18)
Post by: bitbytebit on November 10, 2010, 11:04:35 pm
These vertical elements can't be very accurate because of the integer issue (you've seen how the key to properly calculate things is always manage integer elements). What's important is the total sum of front/back porches + sync. I've checked my code and the vertical part is really hardcoded for low resolutions I'm afraid. It's assuming front porch is always one line and sync pulses 3/5, leaving the rest for back porch. This actually means:

*progressive:

front porch : 1.5 lines -> rounded to 1 line -> 64 µs
sync pulse: 2.5 lines -> rounded to 3 lines -> 192 µs
back porch: 16 lines -> 16 lines -> 1024 µs
VerticalBlank: 20 lines -> 1280 µs

*interlaced:

front porch : 3(/2) lines -> 96 µs
sync pulse: 5(/2) lines  -> 160 µs
back porch: 33(/2) lines -> 1088 µs
VerticalBlank: 41(/2) lines -> 1344 µs

(this values can be used to support Hantarex MTC 9110 as they should produce the same modelines I am doing. Interlaced values are not the actual used right now but they should be. I'll have a look at this)

So that 3/5 are because TV standars consider sync pulse as 2.5 lines long, so 3 is for the rounding, and 5 because by do multiply by 2 when we interlace. So, the code can be made more generic by calculating these from the above values in µs, for any monitor type. Bear in mind that as we move from the reference mode line lenths change so to do things perfect this must be considered and that's why it's not really correct to precalculate a fixed table with line numbers for vertical porchs/sync or hardcode the values as I was doing.

I've seen your code and the logic looks good. I had imagined another way to deal with multisync monitors as I explained some posts above, by considering each interval/mode as a separate virtual monitor and produce as many versions of each modeline as virtual monitors, and have a system to rate them to choose the best one. For instance, if you ask for 640x480 and use the CGA mode, it will produce an interlaced res (bad rate), after that you use VGA mode and the modeline will be progressive, with a better rate obtained so we select the second. That is all that 'result' stuff about. This was intended for dealing with monitors that have separate hfreq intervals with gaps in the middle, which seems it's not the case with d9800. However, your method seems just as good.

I have to go now, hopefully tomorrow I have some time to look at this and comment. I'm really happy you managed to get this stuff working. I've devoted a lot of hours to think how these calculations should be done, it's incredible how quickly you've figured all of it.



I put up a new version, has quite  few changes past the code I posted, had a few bugs in interlacing when using the vertical values and also had broken CGA mode but figured out the way to do that right.  Also I discovered that the cutoff point on the d9800 for VGA -> SVGA mode is about 32Khz which makes sense and I didn't realize VGA mode was such a small span but the others seem to be able to blanket 8Khz or so each. 

Thanks, I'm hoping it's all going to work right, definitely some tricky stuff to be able to calculate things with the multiple ranges but the only one issue I can see (hopefully) is possibly being able to specify a preferred range or put the ranges in a preferred order.  RIght now I go from lowest to highest and it seems right, since we are trying to calculate the best arcade resolution which most are lower, yet for general resolution calculation it could be opposite of that (which is what lrmc does I think).  Hopefully now that I am starting to understand the interlace calculations a little bit more, from having to get them to work in the vert input mode and your explanation too, hopefully I can start to look at doublescan and figure out how that can be put in. 

Also there seems to be a bug in the Linux DRM stuff with modeswitching, at least seems like it's that.  Basically sometimes, you have to go into another resolution, and back out, then in again to have it display right.  Like it's not really changing all the values of the card output to the monitor.  From what I can tell the exact same modeline is generated and the kernel even prints out messages saying it got the exact same modeline too.  Somewhere in there it seems to not really get to the card itself and usually only games with the 288 vertical resolutions and they end up being wider  than they should (like galaga or pacman do this sometimes, but not often from what I can tell).  It's always done this, did it actually more often with lrmc so it may also have to do with timing calculations and possibly the dotclock value having some leeway. So that's one oddity I want to look into eventually, and doublescan, plus I've now got templates for most of the monitor types that lrmc supported and not sure if they are going to work 100% (especially pal/ntsc ones).

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .19)
Post by: Calamity on November 11, 2010, 04:21:09 am
I've seen your vertical calculations and they seem correct. Without running it I don't know if there will be any rounding issue but the logic is correct and anyway monitors are somewhat tolerant with this.

I'd highly appreciate you included the specs for Hantarex MTC 9110, as it's not a pure CGA monitor but has an extended hfreq range I'd like to be able to use:

Code: [Select]
} elsif ($MONITOR eq "h9110") {
# HANTAREX MTC 9110
fill_mode("15625-16670,49.5-65,3000000-40960000,2.000,4.700,8.000,0.064,0.192,1.024,0,0");
$ActiveLinesLimit  = 288;
$VirtualLinesLimit = 448;
$XresMin = 184;
$YresMin = 192;
}

I hope this weekend I have some time to implement the idea of 'virtual monitors', it's something I was planning to do some day but I didn't have the values for a real multisync monitor, I believe it could make things simplier (or not). Even if your monitor has a continuous hfreq range it can be modelled as having 4 adjacent ranges in where different parameters apply.

ActiveLinesLimit and VirtualLinesLimit are not monitor but user specifications. Indeed, a CGA monitor might do 292.5 progressive lines, but for normal arcade monitor operation it involves adjusting a lot our vertical amplitude potenciometer, so for convenience I set that limit that the user can move if desired. Between ActiveLinesLimit and VirtualLinesLimit we have an interval where we need to interlace but still with too few lines to get a decent shaped picture (too low vertical size), that's why I send those resolutions though the virtualize proc to get a 4:3 res where I can stretch. Again, nothing really stops as from attempting a resolution of 300 lines interlaced, it will just have huge vertical margins and will look 'panoramic', but for convenience we stablish that VirtualLinesLimit at a suitable point to avoid odd-looking resolutions. The resolutions above VirtualLinesLimit are interlaced without stretching.

Now, we could also have an user limitation for lower resolutions, opposite to ActiveLinesLimit, in order to activate doublescan in case it was needed. A good value could be ActiveLinesLimit / 2. But these limitations were intended to be applied to separate hfreq range intervals, so you would have ActiveLinesLimit pairs for each of those intervals, instead of a pair for the whole monitor range. For instance, if you try to do 320x240 inside the CGA interval, you'd get 320x240 progressive. Then if you try it inside the SVGA interval, where you have defined ActiveLinesLimit = 600, the lower limit will be 600/2 = 300, so 240 is below that and you will get 320x240 doublescan. Following my logic you don't need to do any range selection inside the modeline generator, but call the modeline generator for each of the 4 ranges you have (each with its proper porches and stuff), so you will get 4 viable modelines with a rate that accounts for their degree of degradation (doublescan is considered a degradation unless you really want it), and you would select the best one of them according to that rate.

Thinking further, monitor and video card capabilities could be separated. Dotclock allowance range is not monitor but videocard related. Doublescan and interlace capabilities are videocard related too (or buggy drivers limited if you prefer), and one might want to disable i.e. doublescan in case it can't be used.

Once you have a solid engine I'd like to comment the dotclock accuracy issues I found with Windows, to check if they are also there with Linux.

(I'm just commenting this stuff in case it can be useful, not trying to drive you to any design decision, as what's important is to get this running.)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .19)
Post by: bitbytebit on November 11, 2010, 10:39:53 am
I've seen your vertical calculations and they seem correct. Without running it I don't know if there will be any rounding issue but the logic is correct and anyway monitors are somewhat tolerant with this.

I'd highly appreciate you included the specs for Hantarex MTC 9110, as it's not a pure CGA monitor but has an extended hfreq range I'd like to be able to use:

Code: [Select]
} elsif ($MONITOR eq "h9110") {
# HANTAREX MTC 9110
fill_mode("15625-16670,49.5-65,3000000-40960000,2.000,4.700,8.000,0.064,0.192,1.024,0,0");
$ActiveLinesLimit  = 288;
$VirtualLinesLimit = 448;
$XresMin = 184;
$YresMin = 192;
}

I hope this weekend I have some time to implement the idea of 'virtual monitors', it's something I was planning to do some day but I didn't have the values for a real multisync monitor, I believe it could make things simplier (or not). Even if your monitor has a continuous hfreq range it can be modelled as having 4 adjacent ranges in where different parameters apply.

ActiveLinesLimit and VirtualLinesLimit are not monitor but user specifications. Indeed, a CGA monitor might do 292.5 progressive lines, but for normal arcade monitor operation it involves adjusting a lot our vertical amplitude potenciometer, so for convenience I set that limit that the user can move if desired. Between ActiveLinesLimit and VirtualLinesLimit we have an interval where we need to interlace but still with too few lines to get a decent shaped picture (too low vertical size), that's why I send those resolutions though the virtualize proc to get a 4:3 res where I can stretch. Again, nothing really stops as from attempting a resolution of 300 lines interlaced, it will just have huge vertical margins and will look 'panoramic', but for convenience we stablish that VirtualLinesLimit at a suitable point to avoid odd-looking resolutions. The resolutions above VirtualLinesLimit are interlaced without stretching.

Now, we could also have an user limitation for lower resolutions, opposite to ActiveLinesLimit, in order to activate doublescan in case it was needed. A good value could be ActiveLinesLimit / 2. But these limitations were intended to be applied to separate hfreq range intervals, so you would have ActiveLinesLimit pairs for each of those intervals, instead of a pair for the whole monitor range. For instance, if you try to do 320x240 inside the CGA interval, you'd get 320x240 progressive. Then if you try it inside the SVGA interval, where you have defined ActiveLinesLimit = 600, the lower limit will be 600/2 = 300, so 240 is below that and you will get 320x240 doublescan. Following my logic you don't need to do any range selection inside the modeline generator, but call the modeline generator for each of the 4 ranges you have (each with its proper porches and stuff), so you will get 4 viable modelines with a rate that accounts for their degree of degradation (doublescan is considered a degradation unless you really want it), and you would select the best one of them according to that rate.

Thinking further, monitor and video card capabilities could be separated. Dotclock allowance range is not monitor but videocard related. Doublescan and interlace capabilities are videocard related too (or buggy drivers limited if you prefer), and one might want to disable i.e. doublescan in case it can't be used.

Once you have a solid engine I'd like to comment the dotclock accuracy issues I found with Windows, to check if they are also there with Linux.

(I'm just commenting this stuff in case it can be useful, not trying to drive you to any design decision, as what's important is to get this running.)


I've added that monitor in, good to have another range in that extended range I had read about.  I'm going to make the get_mode function take the monitors array into it as a local array, that way we could call it many times with multiple monitor types instead of one single run with them all together.  That would allow it to be called multiple times for each monitor type and then have logic to pick the best one, if desired.  I think the logic I'm using for the choosing of the resolution from the preset file (like with Soft15Khz or AVGA) probably is close to doing the decision making, it at least is able to pick from those lists the best fitting resolution.  I need to see if I accounted for interlace and doublescan though,  I don't think I did but that would be pretty easy I think just making them less likable than an equal progressive. 

Interesting about the active lines limit, I was wondering that, makes sense it's the setting the monitor pots issue more than limitations.  I like the idea of having lower line limits till we do doublescan, which is basically what I was doing with lrmc and is interesting to do doublescan in the higher ranges possibly instead of lower ones since I'm guessing that could make it look somewhat better.  I do see how doublescan is really a last resort and quite bad looking if there's a possible alternative, now seeing the output for 192 high resolution games on my d9800 compared to the doublescan versions, I like them better like they are now.

All sounds really interesting, thanks for all the feedback and information, help and such.  Definitely helping me get this working much better than originally, I'm pretty happy with how well it's working and just a few issues with my monitor currently I see that are somewhat a real problem.  The major issue I see is that old one about certain games like dbz with most likely wrong resolutions in mame, which always seem to suspiciously show a 1.5 or greater resolution aspect ratio.  It always seems to be those games that stretch too wide and look to me like they have definitely gotten the screen size wrong for both width and height.  You can somewhat fiddle around and get a working size, but it's not always clearly only width or height I think.  Maybe they had a bigger blanking interval or something to push it in more?  The dbz case and mk case are both ones I know of at least.  I keep thinking maybe there's something in the calculations wrong but now seeing the same thing with your method instead of lrmc, although it is closer than lrmc could get and I think shows the problem only instead of lrmc problems combined.  So I think it's definitely the games resolutions themselves and might even be somewhat impossible to fix those without some virtualization or changing mame itself like is done with frogger/galaxian to get them to behave properly.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .19)
Post by: Calamity on November 11, 2010, 11:28:18 am
Maybe they had a bigger blanking interval or something to push it in more?

Yeah, could be. But as there are many games with the opposite problem (less xres than real) which is even worse, I believe it's just that the resolutions reported by Mame are wrong. Some games also change resolutions several times (see Cabmame option changeres), so another possibility is that the reported resolution is just one that is used at some point but not the main one. In order to find the cause it would be necessary to have a look at involved Mame system drivers... I think the easiest way to solve this by now is using a list of patches for these games/systems resolutions, so your frogger patch could be included there.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .19)
Post by: bitbytebit on November 11, 2010, 11:51:31 am
Maybe they had a bigger blanking interval or something to push it in more?

Yeah, could be. But as there are many games with the opposite problem (less xres than real) which is even worse, I believe it's just that the resolutions reported by Mame are wrong. Some games also change resolutions several times (see Cabmame option changeres), so another possibility is that the reported resolution is just one that is used at some point but not the main one. In order to find the cause it would be necessary to have a look at involved Mame system drivers... I think the easiest way to solve this by now is using a list of patches for these games/systems resolutions, so your frogger patch could be included there.


Yeah, well it's the frogger patch from Cabmame, not mine :) It gives an idea though of how to possibly solve the issues by defining a smaller area than the drivers visible area.  When it's a bigger area we want than the visible area that might be something different I'm guessing.  Seems in the galaxian/frogger issue they scaled the vertical resolution x 3 times to to get the stars to show properly, which added up to 768, and so we're limiting the resolution but the actual visible resolution is still the huge area and the OSD is that size still for the info menu (so it's useless almost to use the info menu).  Seems like there would be a way to get it all fully correct, but looking into it I couldn't see one that was not hacking the actual game driver and getting really complicated redoing the whole thing (like they did when they changed it in .125 and caused the issue of it being too tall). 

I have moved the dotclock stuff out of the monitor lines, make sense and nicer without that in them, also got a quick working ability to feed the modeline function with each line separately.  Just right now do that when asking to calculate a game resolution without loading it in mame, but it's nice to see each possible resolution now.  Here's the basic diff I've done so far, pretty simple change, but definitely brings some interesting possibilities and ways to test multiple monitor lines.

Code: [Select]
diff --git a/extra/switchres.conf b/extra/switchres.conf
index b15f45f..4f5406c 100644
--- a/extra/switchres.conf
+++ b/extra/switchres.conf
@@ -2,25 +2,33 @@
 #vsync=1
 ff=1
 mon=d9800
+#mon=cga
 modesfile=/home/arcade/modes.txt
 displayart=:0.1 /data/mrq
+#use_vtime=0

 #
 # Monitor Limits format:
-# HfreqMin-HfreqMax,VfreqMin-VfreqMax,DotclockMin-DotclockMax,HfrontPorch,HsyncPulse,HbackPorch,VfrontPorch,VsyncPulse,VbackPorch,HorPolarity,VerPolarity
+# HfreqMin-HfreqMax,VfreqMin-VfreqMax,HfrontPorch,HsyncPulse,HbackPorch,VfrontPorch,VsyncPulse,VbackPorch,HorPolarity,VerPolarity
 #
 # CGA Monitor
-#MonitorLimits=15250-15700,49.5-65,3000000-40960000,2.000,4.700,8.000,0.190,0.191,1.018,0,0
+#MonitorLimits=15250-15700,49.5-65,2.000,4.700,8.000,0.190,0.191,1.018,0,0
+#MonitorLimits=15250-15700,49.5-65,2.000,4.700,8.000,0.064,0.192,1.024,0,0
+#MonitorLines=288,448,184,192
 #
 # Wells Gardner D9800 monitor
 #
-#MonitorLimits=15250-20000,40-80,3000000-40960000,2.187,4.688,6.719,0.190,0.191,1.018,0,0
-#MonitorLimits=20001-30000,40-80,3000000-40960000,2.910,3.000,4.440,0.451,0.164,1.048,0,0
-#MonitorLimits=30001-32000,40-80,3000000-40960000,0.636,3.813,1.906,0.318,0.064,1.048,0,0
-#MonitorLimits=32001-38900,40-80,3000000-40960000,1.000,3.200,2.200,0.020,0.106,0.607,1,1
+#MonitorLimits=15250-20000,40-80,2.187,4.688,6.719,0.190,0.191,1.018,0,0
+#MonitorLimits=20001-30000,40-80,2.910,3.000,4.440,0.451,0.164,1.048,0,0
+#MonitorLimits=30001-32000,40-80,0.636,3.813,1.906,0.318,0.064,1.048,0,0
+#MonitorLimits=32001-38900,40-80,1.000,3.200,2.200,0.020,0.106,0.607,1,1
 #
 #
 # MinVertLine,MinVirtLine,MinWidth,MinHeight
 #
 #MonitorLines=600,600,184,192
+#
+# DotClock limits of video card
+DotClockMin=3000000
+DotClockMax=90000000

diff --git a/switchres b/switchres
index 7010970..29054e3 100755
--- a/switchres
+++ b/switchres
@@ -95,8 +95,6 @@ my $HfreqMin    = 0;
 my $HfreqMax    = 0;
 my $VfreqMin    = 0;
 my $VfreqMax    = 0;
-my $DotClockMin = 0;
-my $DotClockMax = 0;

 my $FP  = 0;
 my $SP  = 0;
@@ -116,6 +114,9 @@ my $VirtualLinesLimit = 448;
 my $XresMin = 184;
 my $YresMin = 192;

+my $DotClockMin = 3000000;
+my $DotClockMax = 40960000;
+
 my @cfgopts = read_config($CONFIG_FILE);
 foreach(@cfgopts) {
        my $line = $_;
@@ -126,6 +127,8 @@ foreach(@cfgopts) {
                fill_mode($value);
        } elsif ($key eq "MonitorLines") {
                ($ActiveLinesLimit, $VirtualLinesLimit, $XresMin, $YresMin) = split(/,/, $value);
+       } elsif ($key eq "DotClockRange") {
+               ($DotClockMin, $DotClockMax) = split(/-/, $value);
        } elsif ($key eq "resfile") {
                if (! -e $value) {
                        print "Error: resfile $value doesn't exist!!!\n";
@@ -422,58 +425,58 @@ if ($MONITOR || !scalar(@MonitorModes)) {
        @MonitorModes = ();
        if ($MONITOR eq "d9800" || $MONITOR eq "d9400") {
                # D9800/D9400
-               fill_mode("15250-20000,40-80,3000000-40960000,2.187,4.688,6.719,0.190,0.191,1.018,0,0");
-               fill_mode("20001-30000,40-80,3000000-40960000,2.910,3.000,4.440,0.451,0.164,1.048,0,0");
-               fill_mode("30001-32000,40-80,3000000-40960000,0.636,3.813,1.906,0.318,0.064,1.048,0,0");
-               fill_mode("32001-38900,40-80,3000000-40960000,1.000,3.200,2.200,0.020,0.106,0.607,1,1");
+               fill_mode("15250-20000,40-80,2.187,4.688,6.719,0.190,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");
                $ActiveLinesLimit  = 600;
                $VirtualLinesLimit = 600;
                $XresMin = 184;
                $YresMin = 192;
        } elsif ($MONITOR eq "d9200") {
                # D9200
-               fill_mode("15250-20000,40-100,3000000-40960000,2.187,4.688,6.719,0.190,0.191,1.018,0,0");
-               fill_mode("20001-30000,40-100,3000000-40960000,2.910,3.000,4.440,0.451,0.164,1.048,0,0");
-               fill_mode("30001-33000,40-100,3000000-40960000,0.636,3.813,1.906,0.318,0.064,1.048,0,0");
+               fill_mode("15250-20000,40-100,2.187,4.688,6.719,0.190,0.191,1.018,0,0");
+               fill_mode("20001-30000,40-100,2.910,3.000,4.440,0.451,0.164,1.048,0,0");
+               fill_mode("30001-33000,40-100,0.636,3.813,1.906,0.318,0.064,1.048,0,0");
                $ActiveLinesLimit  = 480;
                $VirtualLinesLimit = 600;
                $XresMin = 184;
                $YresMin = 192;
        } elsif ($MONITOR eq "ntsc") {
-               fill_mode("15734.26-15734.26,59.95-59.95,3000000-40960000,0.636,3.813,1.906,0,0,0,0,0");
+               fill_mode("15734.26-15734.26,59.95-59.95,0.636,3.813,1.906,0,0,0,0,0");
                $ActiveLinesLimit  = 240;
                $VirtualLinesLimit = 448;
                $XresMin = 184;
                $YresMin = 192;
        } elsif ($MONITOR eq "pal") {
-               fill_mode("15625-15625,50-50,3000000-40960000,0.636,3.813,1.906,0,0,0,0,0");
+               fill_mode("15625-15625,50-50,0.636,3.813,1.906,0,0,0,0,0");
                $ActiveLinesLimit  = 288;
                $VirtualLinesLimit = 448;
                $XresMin = 184;
                $YresMin = 192;
        } elsif ($MONITOR eq "vga") {
-               fill_mode("30001-32000,40-80,3000000-40960000,0.636,3.813,1.906,0.318,0.064,1.048,0,0");
+               fill_mode("30001-32000,40-80,0.636,3.813,1.906,0.318,0.064,1.048,0,0");
                $ActiveLinesLimit  = 480;
                $VirtualLinesLimit = 600;
                $XresMin = 184;
                $YresMin = 192;
        } elsif ($MONITOR eq "ega") {
                # EGA
-               fill_mode("24960-24960,50-60,3000000-40960000,2.910,3.000,4.440,0.451,0.164,1.048,0,0");
+               fill_mode("24960-24960,50-60,2.910,3.000,4.440,0.451,0.164,1.048,0,0");
                $ActiveLinesLimit  = 384;
                $VirtualLinesLimit = 480;
                $XresMin = 184;
                $YresMin = 192;
        } elsif ($MONITOR eq "h9110") {
                # Hantarex MTC 9110
-               fill_mode("15625-16670,49.5-65,3000000-40960000,2.000,4.700,8.000,0.064,0.192,1.024,0,0");
+               fill_mode("15625-16670,49.5-65,2.000,4.700,8.000,0.064,0.192,1.024,0,0");
                $ActiveLinesLimit  = 288;
                $VirtualLinesLimit = 448;
                $XresMin = 184;
                $YresMin = 192;
        } else {
                # CGA
-               fill_mode("15250-15700,49.5-65,3000000-40960000,2.000,4.700,8.000,0.064,0.192,1.024,0,0");
+               fill_mode("15250-15700,49.5-65,2.000,4.700,8.000,0.064,0.192,1.024,0,0");
                $ActiveLinesLimit  = 288;
                $VirtualLinesLimit = 448;
                $XresMin = 184;
@@ -852,6 +855,21 @@ if ($RESOLUTION) {
                exit 1;
        }

+       if ($VERBOSE > 1 || $CALCRES) {
+               foreach (@MonitorModes) {
+                       my @mmode;
+                       push @mmode, $_;
+                       my $mline = get_modeline($width, $height, $refresh, @mmode);
+                       my $resinfo = get_resinfo($mline);
+                       print "# $GAME $resinfo\n";
+                       print "     $mline\n";
+               }
+               if ($CALCRES) {
+                       print "\n";
+                       #exit 0;
+               }
+       }
+
        # Use LRMC to generate a custom modeline
        if ($GEN_MODELINES) {
                # Only use doublescan when it's a small vertical height
@@ -869,7 +887,7 @@ if ($RESOLUTION) {
                        }
                        $MODELINE = get_modeline_lrmc("$LRMC_CMD");
                } else {
-                       $MODELINE = get_modeline($width, $height, $refresh);
+                       $MODELINE = get_modeline($width, $height, $refresh, @MonitorModes);
                }
                $MODELINE =~ s/\s+/ /g;
                $MODELINE =~ s/^\s+//g;
@@ -953,7 +971,7 @@ if ($RESOLUTION) {
                                        my $LRMC_CMD = $LRMC_BIN . " " . $w . " " . $h . " " . $r . " " . $LRMC_ARGS;
                                        $MODELINE = get_modeline_lrmc("$LRMC_CMD");
                                } else {
-                                       $MODELINE = get_modeline($w, $h, $r);
+                                       $MODELINE = get_modeline($w, $h, $r, @MonitorModes);
                                }
                                $MODELINE =~ s/\s+/ /g;
                                $MODELINE =~ s/^\s+//g;
@@ -1253,6 +1271,7 @@ sub get_modeline() {
        my $OriginalWidth = shift(@_);
        my $OriginalHeight = shift(@_);
        my $OriginalRefresh = shift(@_);
+       my @MonitorModes = @_;
        my @flags = ();
        my $PHSYNC = 0;
        my $PVSYNC = 0;
@@ -1328,8 +1347,6 @@ sub get_modeline() {
                $HfreqMax    = $MonitorModes[$i]{'HfreqMax'};
                $VfreqMin    = $MonitorModes[$i]{'VfreqMin'};
                $VfreqMax    = $MonitorModes[$i]{'VfreqMax'};
-               $DotClockMin = $MonitorModes[$i]{'DotClockMin'};
-               $DotClockMax = $MonitorModes[$i]{'DotClockMax'};
                $PHSYNC      = $MonitorModes[$i]{'HsyncPolarity'};
                $PVSYNC      = $MonitorModes[$i]{'VsyncPolarity'};
                $FP  = $MonitorModes[$i]{'HFrontPorch'};
@@ -1600,18 +1617,15 @@ sub ResVirtualize () {

 sub fill_mode() {
        my $value = shift(@_);
-       my ($hf, $vf, $dc, $hfp, $hsp, $hbp, $vfp, $vsp, $vbp, $hp, $vp) = split(/,/, $value);
+       my ($hf, $vf, $hfp, $hsp, $hbp, $vfp, $vsp, $vbp, $hp, $vp) = split(/,/, $value);
        my ($hfmin, $hfmax) = split(/-/, $hf);
        my ($vfmin, $vfmax) = split(/-/, $vf);
-       my ($dcmin, $dcmax) = split(/-/, $dc);
        my $mode_num = scalar(@MonitorModes);

        $MonitorModes[$mode_num]{'HfreqMin'} = $hfmin;
        $MonitorModes[$mode_num]{'HfreqMax'} = $hfmax;
        $MonitorModes[$mode_num]{'VfreqMin'} = $vfmin;
        $MonitorModes[$mode_num]{'VfreqMax'} = $vfmax;
-       $MonitorModes[$mode_num]{'DotClockMin'} = $dcmin;
-       $MonitorModes[$mode_num]{'DotClockMax'} = $dcmax;
        $MonitorModes[$mode_num]{'HFrontPorch'} = $hfp;
        $MonitorModes[$mode_num]{'HSyncPulse'} = $hsp;



 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .19)
Post by: Calamity on November 11, 2010, 11:54:12 am
I've added that monitor in, good to have another range in that extended range I had read about.  I'm going to make the get_mode function take the monitors array into it as a local array, that way we could call it many times with multiple monitor types instead of one single run with them all together.  That would allow it to be called multiple times for each monitor type and then have logic to pick the best one, if desired.  I think the logic I'm using for the choosing of the resolution from the preset file (like with Soft15Khz or AVGA) probably is close to doing the decision making, it at least is able to pick from those lists the best fitting resolution.  I need to see if I accounted for interlace and doublescan though,  I don't think I did but that would be pretty easy I think just making them less likable than an equal progressive.

That's great, I think it will make the process more general, however I haven't tested that.

Interesting about the active lines limit, I was wondering that, makes sense it's the setting the monitor pots issue more than limitations.  I like the idea of having lower line limits till we do doublescan, which is basically what I was doing with lrmc and is interesting to do doublescan in the higher ranges possibly instead of lower ones since I'm guessing that could make it look somewhat better.  I do see how doublescan is really a last resort and quite bad looking if there's a possible alternative, now seeing the output for 192 high resolution games on my d9800 compared to the doublescan versions, I like them better like they are now.

What we'll have to work out are the most suitable active line limits for your monitor modes, as I guess they will have to be carefully selected to have the best results. BTW I wonder if I could still buy one of those D9800 here in Europe.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .19)
Post by: Calamity on November 11, 2010, 12:13:47 pm
Yeah, well it's the frogger patch from Cabmame, not mine :) It gives an idea though of how to possibly solve the issues by defining a smaller area than the drivers visible area.  When it's a bigger area we want than the visible area that might be something different I'm guessing.  Seems in the galaxian/frogger issue they scaled the vertical resolution x 3 times to to get the stars to show properly, which added up to 768, and so we're limiting the resolution but the actual visible resolution is still the huge area and the OSD is that size still for the info menu (so it's useless almost to use the info menu).  Seems like there would be a way to get it all fully correct, but looking into it I couldn't see one that was not hacking the actual game driver and getting really complicated redoing the whole thing (like they did when they changed it in .125 and caused the issue of it being too tall). 

I see, it's a different thing this frogger issue, to be honest I haven't tested this game with newer Mame versions, I'll have a look tonight.

I have moved the dotclock stuff out of the monitor lines, make sense and nicer without that in them, also got a quick working ability to feed the modeline function with each line separately.  Just right now do that when asking to calculate a game resolution without loading it in mame, but it's nice to see each possible resolution now.  Here's the basic diff I've done so far, pretty simple change, but definitely brings some interesting possibilities and ways to test multiple monitor lines.

Yes that's it! The way I thought for rating resolutions was based on setting bits on the result of the function, so each bit means a kind of degradation, which allows to account for several 'defects' at the same time, for instance a resolution can be interlaced and have bad refresh at the same time. Depending on the weight (position) we decide which defects are worse that others, and they can be added up, so evaluating the output modelines can be a matter of just choosing the one with the lower result value.



Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .19)
Post by: bitbytebit on November 11, 2010, 02:35:27 pm
Yeah, well it's the frogger patch from Cabmame, not mine :) It gives an idea though of how to possibly solve the issues by defining a smaller area than the drivers visible area.  When it's a bigger area we want than the visible area that might be something different I'm guessing.  Seems in the galaxian/frogger issue they scaled the vertical resolution x 3 times to to get the stars to show properly, which added up to 768, and so we're limiting the resolution but the actual visible resolution is still the huge area and the OSD is that size still for the info menu (so it's useless almost to use the info menu).  Seems like there would be a way to get it all fully correct, but looking into it I couldn't see one that was not hacking the actual game driver and getting really complicated redoing the whole thing (like they did when they changed it in .125 and caused the issue of it being too tall). 

I see, it's a different thing this frogger issue, to be honest I haven't tested this game with newer Mame versions, I'll have a look tonight.

I have moved the dotclock stuff out of the monitor lines, make sense and nicer without that in them, also got a quick working ability to feed the modeline function with each line separately.  Just right now do that when asking to calculate a game resolution without loading it in mame, but it's nice to see each possible resolution now.  Here's the basic diff I've done so far, pretty simple change, but definitely brings some interesting possibilities and ways to test multiple monitor lines.

Yes that's it! The way I thought for rating resolutions was based on setting bits on the result of the function, so each bit means a kind of degradation, which allows to account for several 'defects' at the same time, for instance a resolution can be interlaced and have bad refresh at the same time. Depending on the weight (position) we decide which defects are worse that others, and they can be added up, so evaluating the output modelines can be a matter of just choosing the one with the lower result value.





I had seen the result output you were doing and that sounds really good, I just did a similar thing but the weight of each type of alteration my not be in proper order or weight yet.  Right now I've got it so you can see exactly what changes were made in each mode, but it does tend to choose the lowest value of the ranges.  Definitely nice to have this now, helping me see what happens exactly per range and also now with a -v for verbose added (more added the more verbose it gets)  the -calcgame xxx -v will give a nice informative output of what is going on per range.

I just updated to version .20 that has this and the other changes in it, with the new monitor type too...

Version 0.20 - Multiple ranges resolutions can be compared
* When printing out a resolution, you can now see all the possible ones if
  monitor has multiple ranges
* Added new  Hantarex MTC 9110 Arcade Monitor support
* Print out information on exactly what was changed to create a modeline,
  in future could be used to weight multiple monitor ranges
* Moved dotclock range to separate config from monitor ranges, not used anyways
  and specific to video cards more than anything.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .20)
Post by: Calamity on November 11, 2010, 06:42:10 pm
I've attached an Excel table with some calculations based on D9800 values, to try to help figuring out where the transitions between modes could be done. The interesting part is the active lines area. I'll think about this.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .20)
Post by: bitbytebit on November 11, 2010, 11:59:03 pm
I've attached an Excel table with some calculations based on D9800 values, to try to help figuring out where the transitions between modes could be done. The interesting part is the active lines area. I'll think about this.


Interesting, so those are the calculated out active line and blanking limits for those values. What's strange is how in the documentation they claim 40-100Hz vertical but from what I can tell it's impractical with the 15.250 (they claim 15.725 lower limit but it seems to push down to this just fine) to 38.9 (again they claim 40 here but it seems to get odd anywhere above this) Horizontal Khz limits.  Also on the front page of the manual they claim 15.75-50Khz scanning and 40-100Hz vertical, so of course there they ad another 10Khz to horizontal which I do not see as even possible from what I've seen it do above 40 let alone 38.9.  I think the vertical can go up to 100Hz technically, but I don't see how that could actually happen and at most have seen around mid 70Hz vertical I think max actually get used.  Maybe there's lower resolutions, I don't know tons about the possibilities since I am just learning about this.  Also those ranges I choose for horizontal freq are part speculation and seem to be confirmed from not running into issues yet with them.  Really only issue was the VGA->SVGA point which otherwise my guesses were maybe correct (although I guess the month or two I've been through fiddling with things my guesses are from that experience and some intuition about it from what I've experienced).  What's odd is that this d9800 monitor seems to not be very well documented as so capable, maybe from the bad experiences with the 9200 and people think the 9200 is the same but it's completely limited compared to the 9400/9800 models.  The 9200 seems to be truly fixed around 1Khz at three points and also can sort of go up to SVGA but I guess it's not meant to do it.  I guess the 9200 dies to easily though for them to be of much importance, at least from what I can tell, they are a big hassle to keep alive into older age.  So these line limits, are we basically following them most likely already in the code, jumping from one set to the other as they calculate out too much Horzontal Khz or too little?  I'm pretty amazed at looking at the amount of lines added vertically when too small and other adjustments, where in lrmc I could see nothing and it was a black box it seemed of what had happened.  Also I like how your calculations make it so the actual active lines are the real resolution size we wanted no matter what even if there are margins.  In lrmc it was being 'honest' about this and calling active lines the whole screen visible which of course isn't really what we need because we are trying to create a resolution mame/SDL will actually choose by active lines matching.  I always suspected there was a lot more flexibility in these modelines from studying the ones SailorSat came up with and seeing how they were way better than lrmc but didn't obey the same rules lrmc enforced.  Now I'm seeing how partly that's possible, and neat to have the actual code doing it somewhat understandable to me (last reworking of it moving things around completely really helped me see all the different tests and changes to make things work). 

I'm guessing now that doublescan would essentially be going to everyplace interlace is done/calculated and doing it when smaller instead of bigger than our vertical limits and then dividing by 2 instead of multiplying by 2 in the places where the interlace variable is put into the equation.  Also from what I can tell, though I'm pretty sure, basically every time the virtualization happens interlacing is done? 

Also do you think the dotclock increments you saw are the hardware, just that one chip for that radeon version, or constant on all radeon/ati or other chips, or possibly just the Windows driver?  It's interesting with that because sometimes I suspect from looking at the d9800 OSD with it telling me the values that it'll be off by .10 of what the modeline should be (although also it only is one decimal place out, so pacman is 60.5 sometimes).  I'm not sure if it's the card, linux video drm layer, or monitor or monitor miscalculation that makes it fluxuate like that  (or be different than what it calculates out to).  Just another thing I've been thinking about, and I read before about how I guess the increments of dotclocks are in 250 or something, that modern video cards have some limit to how precise they can be.

Does seem like the modeline output so far has been quite nice though for ranges from 15-40Khz so it does seem like, as long as the monitor specs are in there and maybe the d9800 are good generic ones somewhat, this is the most useful modeline generator I've actually been able to use.  All others are always very specific to a either normal modern monitors or there's lrmc and a few others for arcade monitors, but not anything that really can bridge all them together like I'm seeing.  That's my goal, is to try and make this able to really do all modelines, because that's what I've been hunting for since I got this d9800 and I seriously don't see how anyone else has ever gotten full use of the d9800 monitor because I didn't see it out there in Windows or Linux, something that could go through the whole range and adjust to any resolution and vertical refresh rate.  I think the only vertical refresh rates I can't create and have to throttle on are ones like Tron and Journey that have that odd 512 high vertical lines at 30Hz (which is odd, was there interlacing involved or something?) .  I can even run Starwars at 40Hz with nothrottle, it's a bit odd at first but you realize that's how it looked in the arcade, was the low Vertical refresh that gave it that characteristic it had.

Also that brings up another question about vector games, right now I just go to 480 lines high and width depending on if they are vertical or not (actually 488 because of both 640x480 and 800x600 are either taken up by the X Windows desktop resolution and also there's an odd issue with a phantom 800x600 resolution xrandr seems to not allow, but will allow 801x600, even when I can't see any 800x600 resolution in existence).  Is this something that could be done better, should we just go for max lines and I should try 600 vertical on those since the d9800 can do it at that just fine?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .20)
Post by: SailorSat on November 12, 2010, 01:55:43 am
Wow, completely missed this thread.
I haven't read through your scripts yet, but certainly will take a look soon :).

The "biggest" problem I've encountered with generating modelines "on the fly" would be that most games use their own timing rules.

As an example there are those 60Hz 256line game.
Basic math says 15,720kHz / 60Hz leaves 262 lines in total.
262 lines total - 256 lines active = 6! lines for the porches and the sync

So these games most likely silently increased their horizontal frequency up to 16,000kHz, as most monitors out there should work fine when adjusted.
Now if you apply some basic formula like "okay, 10% of active lines for to the sync" you'll end up way higher on those games.

I've tried both calculations based on
- lines formula (V_Total = Height / pVActive {pVActive = 0.912})
- timing based calculations (V_Total = Frequency / Refresh)

Problem with the first is simple... you'll end up with to many lines and combined with the vertical refresh, to high vertical refresh.
The second one on the hand most likely will produce to small vertical sync as the reference Frequency is too low.

Best would be to do BOTH calculations and then use the golden middle of both results.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .20)
Post by: Calamity on November 12, 2010, 08:04:28 am
Wow, completely missed this thread.
I haven't read through your scripts yet, but certainly will take a look soon :).

The "biggest" problem I've encountered with generating modelines "on the fly" would be that most games use their own timing rules.

As an example there are those 60Hz 256line game.
Basic math says 15,720kHz / 60Hz leaves 262 lines in total.
262 lines total - 256 lines active = 6! lines for the porches and the sync

So these games most likely silently increased their horizontal frequency up to 16,000kHz, as most monitors out there should work fine when adjusted.
Now if you apply some basic formula like "okay, 10% of active lines for to the sync" you'll end up way higher on those games.

I've tried both calculations based on
- lines formula (V_Total = Height / pVActive {pVActive = 0.912})
- timing based calculations (V_Total = Frequency / Refresh)

Problem with the first is simple... you'll end up with to many lines and combined with the vertical refresh, to high vertical refresh.
The second one on the hand most likely will produce to small vertical sync as the reference Frequency is too low.

Best would be to do BOTH calculations and then use the golden middle of both results.

Hi SailorSat,

The basic idea is to have your vertical blank in µs instead of percentages. For my Hantarex 9110, I work with a vertical blank of 1280 µs. So for the particular case you're proposing it would be done like this:

hfreq = vfreq * yres / ( interlace * ( 1 - vfreq * VerticalBlank ) ) = 60 * 256 / ( 1 * ( 1 - 60 * 0.00128 ) ) = 16637.78 Hz
vvt = hfreq / vfreq = 16637,78 / 60 = 277.29 -> 277 lines

So you need to go up to 16.64 KHz to achieve 256 active lines at 60Hz, which can be out of the limits of some monitors, but mine does accept. So this is useful to have 1942 and such games running at real 60 Hz when rotated in a horizontal monitor (that's why I started with all this stuff by the way http://www.marcianitos.in/foro/thread/33/35/13335_1.html (http://www.marcianitos.in/foro/thread/33/35/13335_1.html)).

Nice thing about these algorithms is that they work to get the best (or less bad) solution for any particular monitor. So if your monitor can't deal with 16.64 KHz but only with, say 16.20 KHz, you won't be able to get 256 lines@60Hz but you'll get as close as you can: 256 lines@58,48Hz.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .20)
Post by: Calamity on November 12, 2010, 01:02:31 pm
Interesting, so those are the calculated out active line and blanking limits for those values. What's strange is how in the documentation they claim 40-100Hz vertical but from what I can tell it's impractical with the 15.250 (they claim 15.725 lower limit but it seems to push down to this just fine) to 38.9 (again they claim 40 here but it seems to get odd anywhere above this) Horizontal Khz limits.  Also on the front page of the manual they claim 15.75-50Khz scanning and 40-100Hz vertical, so of course there they ad another 10Khz to horizontal which I do not see as even possible from what I've seen it do above 40 let alone 38.9.  I think the vertical can go up to 100Hz technically, but I don't see how that could actually happen and at most have seen around mid 70Hz vertical I think max actually get used.  Maybe there's lower resolutions, I don't know tons about the possibilities since I am just learning about this.  Also those ranges I choose for horizontal freq are part speculation and seem to be confirmed from not running into issues yet with them.  Really only issue was the VGA->SVGA point which otherwise my guesses were maybe correct (although I guess the month or two I've been through fiddling with things my guesses are from that experience and some intuition about it from what I've experienced).  What's odd is that this d9800 monitor seems to not be very well documented as so capable, maybe from the bad experiences with the 9200 and people think the 9200 is the same but it's completely limited compared to the 9400/9800 models.  The 9200 seems to be truly fixed around 1Khz at three points and also can sort of go up to SVGA but I guess it's not meant to do it.  I guess the 9200 dies to easily though for them to be of much importance, at least from what I can tell, they are a big hassle to keep alive into older age.  So these line limits, are we basically following them most likely already in the code, jumping from one set to the other as they calculate out too much Horzontal Khz or too little?  I'm pretty amazed at looking at the amount of lines added vertically when too small and other adjustments, where in lrmc I could see nothing and it was a black box it seemed of what had happened.  Also I like how your calculations make it so the actual active lines are the real resolution size we wanted no matter what even if there are margins.  In lrmc it was being 'honest' about this and calling active lines the whole screen visible which of course isn't really what we need because we are trying to create a resolution mame/SDL will actually choose by active lines matching.  I always suspected there was a lot more flexibility in these modelines from studying the ones SailorSat came up with and seeing how they were way better than lrmc but didn't obey the same rules lrmc enforced.  Now I'm seeing how partly that's possible, and neat to have the actual code doing it somewhat understandable to me (last reworking of it moving things around completely really helped me see all the different tests and changes to make things work).

I have no experience with digital chassis and I'm really interested in the results you get out of this, in order to make a general method for all monitors. Mine is an analog monitor, and Hfreq range is about 1 KHz wide, but you can use a potenciometer to shift that 1 KHz window up or down. Modern monitors as yours should have all of its adjusting functionality done through it's OSD, however, it makes me wonder if that documented 15.725-40.000 window might be shifted down a bit. As you say, without documentation we can just speculate and test. It's the same with these ranges, I believe there must be a cutoff point where the monitor goes for a mode or the other, but if it has some autoadjusting mechanism maybe it can make this transparent for us. I made that Excel table to try to figure out how to solve the overlapping between ranges, as I'm guessing there will be some frontier modes that could be calculated within both adjacent ranges, so we might end up with two modelines with the same rate/score to choose from (maybe, after all, this rating system was too simple to work). I have the feeling (not confirmed) that the monitor will be more 'confortable' when showing that resolution on the lower part of each single range than on the upper part. So, a way to force it to do so can be to actually define one of these ActiveLinesLimit for each or our intervals, based on that values on the table, so that when we reach the area were both ranges overlap, the resulting mode from the lower range will be virtualized, so our method will choose the upper one without doubts. I'm guessing that the optimal value for this ActiveLinesLimit should be between the values named as Max (VfreqMin) and Max (Vfreq 60Hz), that's why I chose 288 for my monitor. However, I still have to think about this.

I'm guessing now that doublescan would essentially be going to everyplace interlace is done/calculated and doing it when smaller instead of bigger than our vertical limits and then dividing by 2 instead of multiplying by 2 in the places where the interlace variable is put into the equation.  Also from what I can tell, though I'm pretty sure, basically every time the virtualization happens interlacing is done?

Yes, in a way doublescan can be considered opposite to interlace but it's not so simple, I think it should divide dotclocks not lines.

Also do you think the dotclock increments you saw are the hardware, just that one chip for that radeon version, or constant on all radeon/ati or other chips, or possibly just the Windows driver?  It's interesting with that because sometimes I suspect from looking at the d9800 OSD with it telling me the values that it'll be off by .10 of what the modeline should be (although also it only is one decimal place out, so pacman is 60.5 sometimes).  I'm not sure if it's the card, linux video drm layer, or monitor or monitor miscalculation that makes it fluxuate like that  (or be different than what it calculates out to).  Just another thing I've been thinking about, and I read before about how I guess the increments of dotclocks are in 250 or something, that modern video cards have some limit to how precise they can be.

Well, this is a highly interesting stuff I'd like to test when possible. First, at least in Windows we have a limitation on the precision of the dotclock value, as it is stored using integers were each unit stands for 0.01 MHz, so 375 -> 3.75 MHz, 376 -> 3.76 MHz and so on. I don't know if this is a hardware limitation or not. But these values have to be converted to the dividers we talked about somewhere in the driver, and that's were we could see if it's possible to be more precise or not (not a trivial task for what I saw). Second, when you program a Radeon 9250 card for 3.75 MHz, you really get 3.749904, 376 gives 3.764327, etc.... but I haven't been able to find the logic and it seemed a little bit random, as the increments are not constant. It is almost sure it has to do with the dividers stuff. So I ended up making a table that stores all input dotclocks with their corresponding actual tested dotclock. That way I can predict the resulting Vfreq for my modelines with 0.002 Hz accuracy. It doesn't mean I can go so close for any input Vfreq, but at least I know what the result will be and how close to the requested Vfreq I'll get. You may wonder how I got those values. The only possible way (without an oscilloscope I believe) is by making a program that switches to your just created video mode and does vsync, then you measure resulting Vfreq as accurate as possible, and finally use that value to find the real dotclock by doing the calculations backwards. So you need to create a test modeline for any single input dotclock value... the test took hours to end. I have confirmed the same values for two different Radeon 9250, and also they seem to be correct with a Radeon X300, however, I don't know if they can be used with other Radeon.

Does seem like the modeline output so far has been quite nice though for ranges from 15-40Khz so it does seem like, as long as the monitor specs are in there and maybe the d9800 are good generic ones somewhat, this is the most useful modeline generator I've actually been able to use.  All others are always very specific to a either normal modern monitors or there's lrmc and a few others for arcade monitors, but not anything that really can bridge all them together like I'm seeing.  That's my goal, is to try and make this able to really do all modelines, because that's what I've been hunting for since I got this d9800 and I seriously don't see how anyone else has ever gotten full use of the d9800 monitor because I didn't see it out there in Windows or Linux, something that could go through the whole range and adjust to any resolution and vertical refresh rate.  I think the only vertical refresh rates I can't create and have to throttle on are ones like Tron and Journey that have that odd 512 high vertical lines at 30Hz (which is odd, was there interlacing involved or something?) .  I can even run Starwars at 40Hz with nothrottle, it's a bit odd at first but you realize that's how it looked in the arcade, was the low Vertical refresh that gave it that characteristic it had.

I really went through several different methods until I definitely got to that one working, starting from an Excel table, and understood that any algorithm that really intended to be as good as oneself doing the stuff by hand should somehow operate in the same manner as a person would do, adding line by line and checking results, so it needed to be iterated. What I hardly imagined is that it could be adapted so quickly to support multisync monitors. So definitely we should try to extend it to do all modelines, as this combined with the Linux modeline support you've achieved can be nearly perfect.

I've also wondered about those 30Hz modes, maybe they were interlaced. However, you can double Vfreq and use CabMame Redraw patch.

Also that brings up another question about vector games, right now I just go to 480 lines high and width depending on if they are vertical or not (actually 488 because of both 640x480 and 800x600 are either taken up by the X Windows desktop resolution and also there's an odd issue with a phantom 800x600 resolution xrandr seems to not allow, but will allow 801x600, even when I can't see any 800x600 resolution in existence).  Is this something that could be done better, should we just go for max lines and I should try 600 vertical on those since the d9800 can do it at that just fine?

Well, vector games are going to be stretched anyway, so I think the best approach is to virtualize their resolution. I think you asked before if virtualization involves interlacing. It does now, as it was designed for lowres monitors, however, we can make a progressive version of that algorithm, to be used within your upper ranges. The idea behind virtualization is to produce the biggest possible resolution with a given Vfreq. It came because at the beginning I also used a fixed resolution when stretching, say 640x480@60, but I found that if the game's original Vfreq was lower, say 57Hz, I had more lines to play with so could use a 512 lines or more resolution, producing a better and more defined picture. So the lower the Vfreq, the higher your vertical resolution can be, and the better the result of stretching will be. I used this specially for vertical games that were above 288 lines, however the same idea can be applied to vector games.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .20)
Post by: bitbytebit on November 12, 2010, 02:21:06 pm
Wow, completely missed this thread.
I haven't read through your scripts yet, but certainly will take a look soon :).

The "biggest" problem I've encountered with generating modelines "on the fly" would be that most games use their own timing rules.

As an example there are those 60Hz 256line game.
Basic math says 15,720kHz / 60Hz leaves 262 lines in total.
262 lines total - 256 lines active = 6! lines for the porches and the sync

So these games most likely silently increased their horizontal frequency up to 16,000kHz, as most monitors out there should work fine when adjusted.
Now if you apply some basic formula like "okay, 10% of active lines for to the sync" you'll end up way higher on those games.

I've tried both calculations based on
- lines formula (V_Total = Height / pVActive {pVActive = 0.912})
- timing based calculations (V_Total = Frequency / Refresh)

Problem with the first is simple... you'll end up with to many lines and combined with the vertical refresh, to high vertical refresh.
The second one on the hand most likely will produce to small vertical sync as the reference Frequency is too low.

Best would be to do BOTH calculations and then use the golden middle of both results.

Glad to have your interest in this, have read through the whole Soft15Khz thread (took a few days) and it helped me get a lot  of the basic ideas on what needed to be done in  Linux and about modeline generation in general.  Actually the pacman modeline you generated at around 18Khz on a horizontal monitor setup for someone that got the correct 60.61Hz refresh rate originally inspired me/proved to me that my d9800 could actually do better than I had been doing and needed to get modelines that were better than the generic lrmc was doing (or any other modeline generators).  Fortunately Calamity has educated me with his code on the ways to get that kind of precision to both meet normal arcade monitors requirements and also fully use a d9800 type monitor to it's maximum potential.  I actually used switchres, have it working (think it still should work) in Windows with Soft15Khz, basically able to generate new modelines and eliminate the whole .ini file need which is just a simple matching the mame xml output res to what the Soft15Khz mode files contain/best match.  Definitely interested in what you think of the code and any knowledge you have to help improve the modelines generated by it, or if it can help Soft15Khz in any way.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .20)
Post by: bitbytebit on November 12, 2010, 02:43:36 pm
Interesting, so those are the calculated out active line and blanking limits for those values. What's strange is how in the documentation they claim 40-100Hz vertical but from what I can tell it's impractical with the 15.250 (they claim 15.725 lower limit but it seems to push down to this just fine) to 38.9 (again they claim 40 here but it seems to get odd anywhere above this) Horizontal Khz limits.  Also on the front page of the manual they claim 15.75-50Khz scanning and 40-100Hz vertical, so of course there they ad another 10Khz to horizontal which I do not see as even possible from what I've seen it do above 40 let alone 38.9.  I think the vertical can go up to 100Hz technically, but I don't see how that could actually happen and at most have seen around mid 70Hz vertical I think max actually get used.  Maybe there's lower resolutions, I don't know tons about the possibilities since I am just learning about this.  Also those ranges I choose for horizontal freq are part speculation and seem to be confirmed from not running into issues yet with them.  Really only issue was the VGA->SVGA point which otherwise my guesses were maybe correct (although I guess the month or two I've been through fiddling with things my guesses are from that experience and some intuition about it from what I've experienced).  What's odd is that this d9800 monitor seems to not be very well documented as so capable, maybe from the bad experiences with the 9200 and people think the 9200 is the same but it's completely limited compared to the 9400/9800 models.  The 9200 seems to be truly fixed around 1Khz at three points and also can sort of go up to SVGA but I guess it's not meant to do it.  I guess the 9200 dies to easily though for them to be of much importance, at least from what I can tell, they are a big hassle to keep alive into older age.  So these line limits, are we basically following them most likely already in the code, jumping from one set to the other as they calculate out too much Horzontal Khz or too little?  I'm pretty amazed at looking at the amount of lines added vertically when too small and other adjustments, where in lrmc I could see nothing and it was a black box it seemed of what had happened.  Also I like how your calculations make it so the actual active lines are the real resolution size we wanted no matter what even if there are margins.  In lrmc it was being 'honest' about this and calling active lines the whole screen visible which of course isn't really what we need because we are trying to create a resolution mame/SDL will actually choose by active lines matching.  I always suspected there was a lot more flexibility in these modelines from studying the ones SailorSat came up with and seeing how they were way better than lrmc but didn't obey the same rules lrmc enforced.  Now I'm seeing how partly that's possible, and neat to have the actual code doing it somewhat understandable to me (last reworking of it moving things around completely really helped me see all the different tests and changes to make things work).

I have no experience with digital chassis and I'm really interested in the results you get out of this, in order to make a general method for all monitors. Mine is an analog monitor, and Hfreq range is about 1 KHz wide, but you can use a potenciometer to shift that 1 KHz window up or down. Modern monitors as yours should have all of its adjusting functionality done through it's OSD, however, it makes me wonder if that documented 15.725-40.000 window might be shifted down a bit. As you say, without documentation we can just speculate and test. It's the same with these ranges, I believe there must be a cutoff point where the monitor goes for a mode or the other, but if it has some autoadjusting mechanism maybe it can make this transparent for us. I made that Excel table to try to figure out how to solve the overlapping between ranges, as I'm guessing there will be some frontier modes that could be calculated within both adjacent ranges, so we might end up with two modelines with the same rate/score to choose from (maybe, after all, this rating system was too simple to work). I have the feeling (not confirmed) that the monitor will be more 'confortable' when showing that resolution on the lower part of each single range than on the upper part. So, a way to force it to do so can be to actually define one of these ActiveLinesLimit for each or our intervals, based on that values on the table, so that when we reach the area were both ranges overlap, the resulting mode from the lower range will be virtualized, so our method will choose the upper one without doubts. I'm guessing that the optimal value for this ActiveLinesLimit should be between the values named as Max (VfreqMin) and Max (Vfreq 60Hz), that's why I chose 288 for my monitor. However, I still have to think about this.

I'm guessing now that doublescan would essentially be going to everyplace interlace is done/calculated and doing it when smaller instead of bigger than our vertical limits and then dividing by 2 instead of multiplying by 2 in the places where the interlace variable is put into the equation.  Also from what I can tell, though I'm pretty sure, basically every time the virtualization happens interlacing is done?

Yes, in a way doublescan can be considered opposite to interlace but it's not so simple, I think it should divide dotclocks not lines.

Also do you think the dotclock increments you saw are the hardware, just that one chip for that radeon version, or constant on all radeon/ati or other chips, or possibly just the Windows driver?  It's interesting with that because sometimes I suspect from looking at the d9800 OSD with it telling me the values that it'll be off by .10 of what the modeline should be (although also it only is one decimal place out, so pacman is 60.5 sometimes).  I'm not sure if it's the card, linux video drm layer, or monitor or monitor miscalculation that makes it fluxuate like that  (or be different than what it calculates out to).  Just another thing I've been thinking about, and I read before about how I guess the increments of dotclocks are in 250 or something, that modern video cards have some limit to how precise they can be.

Well, this is a highly interesting stuff I'd like to test when possible. First, at least in Windows we have a limitation on the precision of the dotclock value, as it is stored using integers were each unit stands for 0.01 MHz, so 375 -> 3.75 MHz, 376 -> 3.76 MHz and so on. I don't know if this is a hardware limitation or not. But these values have to be converted to the dividers we talked about somewhere in the driver, and that's were we could see if it's possible to be more precise or not (not a trivial task for what I saw). Second, when you program a Radeon 9250 card for 3.75 MHz, you really get 3.749904, 376 gives 3.764327, etc.... but I haven't been able to find the logic and it seemed a little bit random, as the increments are not constant. It is almost sure it has to do with the dividers stuff. So I ended up making a table that stores all input dotclocks with their corresponding actual tested dotclock. That way I can predict the resulting Vfreq for my modelines with 0.002 Hz accuracy. It doesn't mean I can go so close for any input Vfreq, but at least I know what the result will be and how close to the requested Vfreq I'll get. You may wonder how I got those values. The only possible way (without an oscilloscope I believe) is by making a program that switches to your just created video mode and does vsync, then you measure resulting Vfreq as accurate as possible, and finally use that value to find the real dotclock by doing the calculations backwards. So you need to create a test modeline for any single input dotclock value... the test took hours to end. I have confirmed the same values for two different Radeon 9250, and also they seem to be correct with a Radeon X300, however, I don't know if they can be used with other Radeon.

Does seem like the modeline output so far has been quite nice though for ranges from 15-40Khz so it does seem like, as long as the monitor specs are in there and maybe the d9800 are good generic ones somewhat, this is the most useful modeline generator I've actually been able to use.  All others are always very specific to a either normal modern monitors or there's lrmc and a few others for arcade monitors, but not anything that really can bridge all them together like I'm seeing.  That's my goal, is to try and make this able to really do all modelines, because that's what I've been hunting for since I got this d9800 and I seriously don't see how anyone else has ever gotten full use of the d9800 monitor because I didn't see it out there in Windows or Linux, something that could go through the whole range and adjust to any resolution and vertical refresh rate.  I think the only vertical refresh rates I can't create and have to throttle on are ones like Tron and Journey that have that odd 512 high vertical lines at 30Hz (which is odd, was there interlacing involved or something?) .  I can even run Starwars at 40Hz with nothrottle, it's a bit odd at first but you realize that's how it looked in the arcade, was the low Vertical refresh that gave it that characteristic it had.

I really went through several different methods until I definitely got to that one working, starting from an Excel table, and understood that any algorithm that really intended to be as good as oneself doing the stuff by hand should somehow operate in the same manner as a person would do, adding line by line and checking results, so it needed to be iterated. What I hardly imagined is that it could be adapted so quickly to support multisync monitors. So definitely we should try to extend it to do all modelines, as this combined with the Linux modeline support you've achieved can be nearly perfect.

I've also wondered about those 30Hz modes, maybe they were interlaced. However, you can double Vfreq and use CabMame Redraw patch.

Also that brings up another question about vector games, right now I just go to 480 lines high and width depending on if they are vertical or not (actually 488 because of both 640x480 and 800x600 are either taken up by the X Windows desktop resolution and also there's an odd issue with a phantom 800x600 resolution xrandr seems to not allow, but will allow 801x600, even when I can't see any 800x600 resolution in existence).  Is this something that could be done better, should we just go for max lines and I should try 600 vertical on those since the d9800 can do it at that just fine?

Well, vector games are going to be stretched anyway, so I think the best approach is to virtualize their resolution. I think you asked before if virtualization involves interlacing. It does now, as it was designed for lowres monitors, however, we can make a progressive version of that algorithm, to be used within your upper ranges. The idea behind virtualization is to produce the biggest possible resolution with a given Vfreq. It came because at the beginning I also used a fixed resolution when stretching, say 640x480@60, but I found that if the game's original Vfreq was lower, say 57Hz, I had more lines to play with so could use a 512 lines or more resolution, producing a better and more defined picture. So the lower the Vfreq, the higher your vertical resolution can be, and the better the result of stretching will be. I used this specially for vertical games that were above 288 lines, however the same idea can be applied to vector games.


Thanks, I know I asked a lot of questions so will take me awhile to digest this and hopefully push some of it into the code, basically that was most of my current issues/questions I had.  I did just figure out how to do the rating/weighting of resolutions to where it should give the lowest score to the best, I had to push all those values for the codes to above 2048 and then use the bottom 2047 for storing the number of vertical lines padded with (and should have room for more) also the weights are actually not those values but I calculate them according to what values are stored in that result and then use the vertical padding to increase the weight more per 8 lines high.  That way a really padded resolution will not be as good as a lighter padded one yet they both have the same atributes.  Also weighted any vertical refresh rate more than most else, and not really weight a horizontal refresh rate change anything since as long as it's in range it shouldn't matter I'm guessing (maybe side padding though, I haven't looked at accounting for that yet I guess). 

I made the d9200 monitor config sections more exact to what it should be capable of, where each range is about 1Khz wide so it basically is a good test case.  From what I can tell it works pretty nice calculating for that and weighting it, so is good still even when it's more fixed freq than a d9800 is. 

Good to know about doublescan, I figured it wasn't that easy, looking at lrmc and doublescan and interlace stuff in there, it's quite a tangled mess and takes up most of the code actually adjusting for each of them.  Your way of doing interlaced is much simpler/cleaner and produces better results, I'm hoping to make doublescan the same way too since the main thing in lrmc that makes the code hard to read is the doublescan/interlace support.

Those 30Hz modes are really the only games I have to use throttle on now from what I can tell, since it's impossible to do otherwise, but will take a look at those cabmame patches again and see if that one works already in Linux or is one I can possibly port into the linux mame patch too. 

I'll try to get a virtualization function that is just for vector games, sounds interesting and will help me understand that virtualization function more.  I wondered why it always interlaced and that now makes sense, so sounds like the vector game one could be a function that either tries the maximum resolution progressive or closest vertical resolution to the game progressive.  When that is possible, otherwise do the interlaced version.

Also I tested my ubuntu kernel packages, and well they boot but they didn't have all the ubuntu patches that allow the best smoothest working with the system.  I just figured out how to get the newest patches for ubuntu kernels, actually they have a directory of them for the mainline Linux kernels so I was able to grab a clean applying 2.6.37-rc1 patch and it looks like I'll hopefully have real genuine working correctly Ubuntu 10.10 kernel packages with the arcade resolution patches applied.  I still think in Ubuntu 10.10 there's a bit of hacking at the xorg.conf to turn off the default modelines and possibly the grub.cfg cmd line to the kernel to enable the 640x480 interlaced arcade resolution framebuffer for the console (although if my fix works, it'll autodetect that for us).  It's easy stuff for anyone half familiar with Linux, but sadly a bit technical for anyone just using Linux since messing up your grub.cfg file or xorg.conf can be a painful thing to fix (at least grub.cfg, actually ubuntu doesn't use an xorg.conf file by default because Xorg mostly autodetects stuff.  That actually somewhat makes it a pain because then people need to create an xorg.conf first although Xorg -configure should output one that works and the default modeline thing can be added).  So when I get these newer ubuntu packages uploaded tonight or tomorrow, they take a few hours each to build, I hopefully will have something workable for people wanting to just install Ubuntu 10.10 and avoid building a new X Windows and patching/compiling the latest Linux kernel.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .20)
Post by: bitbytebit on November 12, 2010, 10:13:06 pm
Here's something interesting where I am guessing the mame info is way off on the vertical refresh rate. Saw zookeeper mentioned in another thread and I tried calculating and playing it, found a real odd one that must be masked by most setups with predefined modelines and/or using throttle.  Also this shows my weighting system when fed with the d9200 monitor stats, Basically mame reports a crazy refresh rate of 76.2 which makes it touch the sides of the screen at 256x256 and look ok, but it runs at 125% speed on nothrottle, so of course when I hardcode it with an .ini file to 60Hz it runs 100% perfect and some side borders but looks just as good.  So I don't see how in this case we could really ever know it was wrong, unless you push f11 or hear the audio and see it's running about 25% too fast at the reported mame stats (which also make no sense, they have 256 put into every field like it had no vertical or horizontal more than the active ones, just all is really odd or someone just rushed through shoving in values which are wrong).

256x256@76Hz calculations:
Code: [Select]
arcade@arcade ~/src/SwitchRes $ ./switchres -calcgame zookeep -mon d9200 -v
Display line for zookeep is:
  type: raster
  rotate: 0
  width: 256
  height: 256
  refresh: 76.293945
  pixclock: 5000000
  htotal: 256
  hbend: 0
  hbstart: 256
  vtotal: 256
  vbend: 0
  vbstart: 256

Using mame xml: [1 screen] zookeep horizontal 256x256@76.293945 --> 256x256@76.293945 aspect ratio 1.000

#  | Vertical refresh lowered | Horizontal frequency lowered |
# zookeep 256x256@59.14 16.500Khz score: 20
     "256x256" 5.676000 256 272 304 344 256 260 263 279 -HSync -VSync

*** Horizontal frequency 23.900Khz matches monitor range [0]: 23.900Khz - 24.420Khz
#  | Horizontal frequency raised | 18 lines Vertical padding |
# zookeep 256x256@76.29 23.955Khz score: 2
     "256x256" 8.240864 256 280 304 344 256 277 281 314 -HSync -VSync

*** Horizontal frequency 31.000Khz matches monitor range [0]: 31.000Khz - 32.000Khz
#  | Horizontal frequency raised | 107 lines Vertical padding |
# zookeep 256x256@76.29 31.050Khz score: 13
     "256x256" 10.185056 256 264 304 328 256 320 322 407 -HSync -VSync

*** Horizontal frequency 37.500Khz matches monitor range [0]: 37.500Khz - 38.500Khz
#  | Horizontal frequency raised | 209 lines Vertical padding |
# zookeep 256x256@76.29 37.535Khz score: 26
     "256x256" 12.912728 256 272 312 344 256 362 366 492 +HSync +VSync


*** Horizontal frequency 23.900Khz matches monitor range [1]: 23.900Khz - 24.420Khz
# zookeep 256x256@76.29 23.955Khz
     "256x256" 8.240864 256 280 304 344 256 277 281 314 -HSync -VSync


256x256@60Hz
Code: [Select]
arcade@arcade ~/src/SwitchRes $ ./switchres -calcgame zookeep -mon d9200 -v
Using game ini: zookeep 256x256@60.00 aspect ratio 1.000

#  | Vertical refresh lowered | Horizontal frequency lowered |
# zookeep 256x256@59.14 16.500Khz score: 20
     "256x256" 5.676000 256 272 304 344 256 260 263 279 -HSync -VSync

*** Horizontal frequency 23.900Khz matches monitor range [0]: 23.900Khz - 24.420Khz
#  | Horizontal frequency raised | 103 lines Vertical padding |
# zookeep 256x256@60.00 23.940Khz score: 12
     "256x256" 8.235360 256 280 304 344 256 319 323 399 -HSync -VSync

*** Horizontal frequency 31.000Khz matches monitor range [0]: 31.000Khz - 32.000Khz
#  | Horizontal frequency raised | 217 lines Vertical padding |
# zookeep 256x256@60.00 31.020Khz score: 27
     "256x256" 10.174560 256 264 304 328 256 375 377 517 -HSync -VSync

*** Horizontal frequency 37.500Khz matches monitor range [0]: 37.500Khz - 38.500Khz
#  | Horizontal frequency raised | 342 lines Vertical padding |
# zookeep 256x256@60.00 37.500Khz score: 42
     "256x256" 12.900000 256 272 312 344 256 428 432 625 +HSync +VSync


*** Horizontal frequency 23.900Khz matches monitor range [1]: 23.900Khz - 24.420Khz
# zookeep 256x256@60.00 23.940Khz
     "256x256" 8.235360 256 280 304 344 256 319 323 399 -HSync -VSync




I've been doing a ton of cleaning of code of the old cruft, minimalizing lrmc leaning so it eventually can be ripped out easily when no longer needing it, making all the output in verbose modes somewhat nice and readable to help debugging.  Figured now that the newer modeline generator seems less alpha and working pretty good, need to get things cleaner so it'll be easier to move into doing doublescan and figuring out ways to look at lower line limits and possibly using the weighting system more.  So far the weighting system oddly is always pointing at the resolution we autopicked, but if there was a case where we had different ranges of vertical frequencies for 2 fixed horizontal frequency ranges on a monitor (does that ever happen?) then it most likely fail right now at picking the right one.  I currently assume the monitor can do any vertical frequency in it's range for each of the horizontal frequency ranges.

Oh and for tron and other 30Hz games it looks like that redraw patch from Cabmame looks great and OS independent so I can put it into my linux mame patch, and start using it on the mame commmand line for the games like tron and get them to not need throttle hopefully.  Haven't tested that, but looks like it'll all work great, which makes that many fewer games that need throttling when following the monitors vertical refresh rate with waitvsync in Linux and the newer DRM kernel stuff.




Update: The Ubuntu packages for the patched kernel are up on the sourceforge site now, hopefully work nicer with the Ubuntu flavor of Linux and their patches to the system.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .21)
Post by: bitbytebit on November 13, 2010, 03:49:58 am
Ok, now has the framework to do weighting and does it if given the command line option, so there to play with and do tests although mostly gives the same result until we add more checks in the future for lines and such.  The cabmame redraw patch works great and is in the linux patch now, ported to Linux and compatible with the hi_score patch in there too (had a conflict with the standard hi_score patch I had applied since didn't patch both functions they duplicated).  Oddly the redraw patch doesn't help that zookeeper game, although I'm guessing it's a whole different thing going on there, but of course still works fine/great when forcing the .ini to 60Hz.  The code is cleaner, I hopefully made both the output with the verbose -v options much more helpful and

Version 0.21 -
* Major code cleanup, readability and verbose output now much better and informative
* depreciated lrmc even more, most options are gone specific for it (can still use -lrmc command line option for them)
* Merged in cabmame redraw patch to allow nothrottle on games at 30Hz and generally any game not meeting perfect vertical refresh values.
* -useweight option added to test/use new method of using weights for modelines generated when multiple ranges are set (like a d9800)
* d9200 monitor specs made more strict, good example of a trisync monitor with 3-4 fixed 1Khz wide horizontal freq points.
* Rating of modelines is there, really doesn't do anything different than normal checking through them (unless you manually put monitor ranges in the config file and they are out of order of horizontal freq values, then it would be a better choice to weight them).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .21)
Post by: Calamity 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .21)
Post by: bitbytebit 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).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .22a)
Post by: Calamity 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.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .22a)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
Post by: Calamity 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
Post by: Calamity 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
Post by: Calamity 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...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
Post by: bitbytebit 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. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
Post by: Calamity 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
Post by: Calamity 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .23)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .24)
Post by: Calamity 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .24)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .25)
Post by: Calamity 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .25)
Post by: bitbytebit 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 :).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
Post by: ves 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
Post by: Calamity 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.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
Post by: bitbytebit 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/ (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 (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 :).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
Post by: bitbytebit 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.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
Post by: ves 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/ (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 (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?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
Post by: bitbytebit 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/ (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 (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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
Post by: ves 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
Post by: bitbytebit 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. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26a)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26a)
Post by: Calamity 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.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26a)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26a)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
Post by: Calamity 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
Post by: Calamity 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26d)
Post by: Calamity 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

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .26d)
Post by: bitbytebit 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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .27a)
Post by: bitbytebit 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
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .27a)
Post by: Calamity 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...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .27b)
Post by: ves 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=KORYJYUD)
http://www.megaupload.com/?d=48WAAKYJ (http://www.megaupload.com/?d=48WAAKYJ)


Greetings.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .27a)
Post by: bitbytebit on November 19, 2010, 11:12:02 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...


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

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

Code: [Select]

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


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

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

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

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

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


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

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

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


I got it working I think using either a file of dotclocks like yours, but without the index numbers and only dotclocks, or a command line option to say align to some Hz value.  It's interesting, I don't see my OSD saying it's any different for any of the games except for 1 that now says 40Hz instead of 39.9Hz (it only goes out one decimal place on the OSD unfortunately).  So I can't say if the monitor is not exact or that this newer radeon has different clocks, could be working or not, I'm not sure how to tell.  I can push the dotclock increment up to about 10000 and force it to go up but then it's kinda bad cause the lines completely change and kills games like pacman for me at more than 312 lines.  I am starting to think that the increment doesn't matter in Linux and that the monitor is just off on measurement by a .10 value or less.  It seems pretty consistent on the amount it's always off of the calculated vertical refresh and what the xrandr output says is the value for it.  It's at least something you may want to look at and see if you can see anything interesting, and also now of course could be used in WIndows under these restrictions and be more exact there.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .27a)
Post by: Calamity on November 19, 2010, 06:16:08 pm
I'm interested in creating a function to do your same figuring based upon dotclock values not being granular.  One thing I read somewhere, on why the cvt calculations always are in 250 aligned amounts, is because modern video cards they claim aren't often able to get more fine grained than that.  So it would be interesting for that, at least to see how that affects the line padding.  Also then I could test plugging in your table of ATI values and really see if my d9800 suddenly perfectly hits the vrefresh rates on the OSD, I'm not sure if it's an accurate calculation it's doing though so it'd be interesting since if it did suddenly show perfect values it'd prove both the need for the dotclock check and that the OSD is accurate.

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

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

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

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

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

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

Just for having a test list, I remember dbz, one of the newer golden axes, golden tee, any other one?
There was also that other issue with games that reported less xres than real, like thunder force.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .27a)
Post by: bitbytebit on November 19, 2010, 06:36:25 pm
I'm interested in creating a function to do your same figuring based upon dotclock values not being granular.  One thing I read somewhere, on why the cvt calculations always are in 250 aligned amounts, is because modern video cards they claim aren't often able to get more fine grained than that.  So it would be interesting for that, at least to see how that affects the line padding.  Also then I could test plugging in your table of ATI values and really see if my d9800 suddenly perfectly hits the vrefresh rates on the OSD, I'm not sure if it's an accurate calculation it's doing though so it'd be interesting since if it did suddenly show perfect values it'd prove both the need for the dotclock check and that the OSD is accurate.

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

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

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

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

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

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

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


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

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

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

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

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

Code: [Select]

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

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

It's good to have that implemented at least for Windows use. However, it is perfectly possible that your OSD is not accurate. There are also some indirect ways to test it. One is patching Mame to show it's speed in Hz instead of percentages, with several decimals, then you vsync with no-throttle. I believe I posted a patch for doing this some pages ago, though I can confirm its semi-obsolote and needs updating for the newer versions. Instant speed measure will always be a bit erratic as it's measured using cpu's clock that has also it's own granularity, but if you wait enough your average speed will slowly converge to the real one, unless your system is randomly stealing cpu time from your process and Mame gets slowed for an instant, then that average can be corrupted (usual in Windows). I think there's also a way to make normal Mame post it's average speed on exit. I made an special program to measure video modes vfreq. Once you have some confirmed values, you can make calculations backwards and obtain the actual dotclock being used, and if it more or less matches to one you entered, then this stuff won't be necessary at all.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .27a)
Post by: Calamity on November 19, 2010, 06:47:31 pm
Interesting, I can fix the thunder force with my hacks then, seems to work, here's a diff to make them able to get enabled by the config file or command line.  Also the modeline generated after the fix is:

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

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

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

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


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

Yeah the Small Aspect hack works for those, although I don't fully like it because it also catches other games that don't need it like super mario and from what I can tell degrades it slightly at 320x240 instead of the 254x240 it wants.  The Large Aspect hack seems to always work better than any game reporting a large aspect ratio, so it might be somewhat good.  I just can't figure out yet how to tell the games that have the lower aspect ratio which need to be wider and the ones that are fine, not sure if somehow mame may have more info inside of it to help.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 19, 2010, 07:21:58 pm
It's looking quite odd actually when using that SDL fps output.  Seems that your dotclock values do somewhat get the games closer, sometimes the first value is exact then the others are just slightly lower.  Without it sometimes the first value is exact but lower than it still.  Weirdly when I use an alignment of 10 it takes forever but can get just about everything to run at the perfect vertical refresh.  The problem is it seems to add more lines than otherwise, and pacman become wide again and there's a slight top/bottom margin on other games.  So I'm not sure what it means yet, possibly in Linux we can really use any dotclock and the function is just really getting the exact dotclock needed to run it and vertical lines.  At the same time it seems to be adding too many lines and would be nice to avoid that, but I'm not sure if that's impossible and it's a tradeoff.  Otherwise things run pretty much at a .03 or so precision, without the dotclock checks or alignment, they are close but usually 99.9% or something like that.  The value of 250 does seem benign and sometimes makes things run a little closer, and your values do too, still not sure which are more exact.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .27a)
Post by: Calamity on November 19, 2010, 07:45:17 pm
This option -sdlvideofps for SDL mame I think does that, and interestingly shows a slight difference I think but I'm still looking at that.

Great, I didn't know about that option.

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

I see. I think I know what you mean with AVres managing that stuff, are you using the 'proportional' option in that program? BTW, I heard it was proposed to AVres programmer by Elaphe, a folk from the Spanish forums, as a way compensate for non-square pixel aspect of some games. I believe it's kind of repairing those other games too, but not sure if it was aimed for that. However, even if it can be an useful option for people with difficult access to monitor adjustments, and definitely worth having available, I feel that unless necessary, it goes against the philosophy of achieving the real original arcade resolution for each game (some might say our virtualization stuff also does)... as I understand it, in the analog world 4:3 aspect accounts for the shape of the target monitor, not the resolution itself, so we should not do 320/224 = 1.43 and say our aspect ratio is above 4:3, as there were tons of games using this resolution that are genuine 4:3 games, so when the PCB was plugged the guy was supposed to adjust vertical size to the borders of the screen separating scanlines a bit, and it becomes obvious that it was the expected adjustment when you see that explosions and round stuff look like circles and lot ellipses when doing that.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: Calamity on November 19, 2010, 07:54:18 pm
Otherwise things run pretty much at a .03 or so precision, without the dotclock checks or alignment, they are close but usually 99.9% or something like that.  The value of 250 does seem benign and sometimes makes things run a little closer, and your values do too, still not sure which are more exact.

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

There's something, however, that I'm wondering... when those extra lines are added, does your picture get any different, maybe with more vertical margins? That's what I meant when I asked if your monitor was autoadjusting, as usually you don't see any difference when adding more lines as vertical size is constant until you manually adjust it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 19, 2010, 09:46:04 pm
Otherwise things run pretty much at a .03 or so precision, without the dotclock checks or alignment, they are close but usually 99.9% or something like that.  The value of 250 does seem benign and sometimes makes things run a little closer, and your values do too, still not sure which are more exact.

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

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


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

It's weird because basically with pacman it will get wide and still touch the top/bottom evenly, other games putting more lines will squish them down and leave a margin.  Then there's a few of the lower resolution games like food fight, that very rarely but hardly ever come up really skinny but reloading them makes them fine again.  On super mario it's always got about an inch of space on the sides but once in a while, every 20 loads, it'll be perfect and touching the sides of the screen.  So some games rarely get super skinny like they are vertical, some have margins mostly but  once in awhile are perfectly fitting.  It's odd, the pacman thing is extreme and I know exactly how to prevent it now and what causes it.  The others are a mystery but so rare it doesn't really bother me but I am guessing it may be a slight limit issue of lines or the horizontal frequency perhaps. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 20, 2010, 03:20:22 am
I ported the core modeline generator part and the general structure of switchres to C, it's a trimmed down of just the main modeline generation code right now and only takes the height width refresh as args just like other modeline generators do.  This is helpful because with this code we could easily put it into the Linux kernel, it already has CVT in there so this could be an alternative.  Also of course it's easier to deal with in Windows without worrying about Perl, a lot slimmer in resource usage and the code is a lot cleaner cause perl is really weird about variables (they can be anything and this precision math is bad in that setup).  It actually seems a lot easier to write in C because it was simple to pass everything in structures and the math just worked like it should with there actually being a round function and other math stuff there.

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

I figure this can be the 1.00 branch and go from there, with the perl version still following for now till I move the functionality completely into this.  It's interesting since we should be able to link to and do xrandr stuff native in the future and leave it out when compiling for Windows, maybe someday figure out a way to patch this into mame and just have it do the work from there, at least in Linux it would be a useful thing for the -switchres argument to do.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: Calamity on November 20, 2010, 05:42:28 am
Wow it's great to have this in C! It will be easier for Windows users and we could eventually plug the dynamic modeline functionallity into it for people using patched drivers.I'm going to try to compile and do some testing.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 20, 2010, 06:06:55 am
Wow it's great to have this in C! It will be easier for Windows users and we could eventually plug the dynamic modeline functionallity into it for people using patched drivers.I'm going to try to compile and do some testing.

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

I realized that it really would be best to convert it to C, and actually besides some busy work on those string things and config file reading which I mostly have already anyways in other code I've written, it's hopefully going to make this easier to deal with the calculation stuff.  Also definitely was wanting to get away from a Perl dependency, and all the other issues with perl, but it's a great way to prototype and start things.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 20, 2010, 06:40:00 am
Wow it's great to have this in C! It will be easier for Windows users and we could eventually plug the dynamic modeline functionallity into it for people using patched drivers.I'm going to try to compile and do some testing.

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

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

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

Update: More bugs fixed with virtualize function and added minimum yres parameter again to command line for doublescan, also now actually will virtualize too, that was badly broken from some copy/paste errors :).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: Calamity on November 20, 2010, 01:38:01 pm
I've finally compiled the new C version, it works pretty well for what I'm seeing. (I tried to compile before but 'version.h' was not included in the package I think)

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

(version 1.00c)

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

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

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

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

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

I'll keep testing...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: Calamity on November 20, 2010, 02:07:49 pm
Here's an update, I added all the monitor types and now takes a --monitor <type> arg.  There's something odd going on where for some reason on the d9800 and any multi range monitor I am not getting the same results as the perl version.  On all the CGA/h9110 monitors I get the same modelines as the perl version though, so it's definitely a bit strange.  Also this fixes doublescan support, weights things similar to the perl version and prints out verbose info with -v sort of.

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

Definitely a C version will make things easier in Windows. I like learning all this stuff that's new for me, I was amazed at how powerful Perl seems to deal with strings and xml, it was a lot of boring work for me to do that in Basic. However it can be a bit complicated for an average Windows user as me. I'm not a serious programmer after all, just for hobby, and though I've finished some projects with Masm32 and PowerBasic, never seriously touched C, but for reading code and ripping stuff for Masm32, etc. I'm happy that someone with your coding skills has focused development on this stuff, that was really needed for proper emulation.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: Calamity on November 20, 2010, 07:50:00 pm
Interesting: some games affected by bad reported resolutions are from the drivers segas32.c and segac2.c, in MAWS you can read that their resolutions were fixed at some point to this new size, that at least for segac2.c games I'm almost sure is not correct.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 20, 2010, 09:01:43 pm
I've finally compiled the new C version, it works pretty well for what I'm seeing. (I tried to compile before but 'version.h' was not included in the package I think)

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

(version 1.00c)

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

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

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

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

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

I'll keep testing...


It's hitting this code right here...
Code: [Select]

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



Which is originally this...
Code: [Select]


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



Is there a way to get it to keep the correct vertical frequency in that case?  I'm not sure but suspecting it's hitting the limit of the hfreq max and when it lowers it then the vertical frequency has to go up?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 20, 2010, 09:29:46 pm
Here's an update, I added all the monitor types and now takes a --monitor <type> arg.  There's something odd going on where for some reason on the d9800 and any multi range monitor I am not getting the same results as the perl version.  On all the CGA/h9110 monitors I get the same modelines as the perl version though, so it's definitely a bit strange.  Also this fixes doublescan support, weights things similar to the perl version and prints out verbose info with -v sort of.

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

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



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

The version.h file is generated by the version.sh script, but it's a unix bash script and so wouldn't run of course in Windows unless running in Cygwin to compile.  That'll probably be the best way since it's how I'll be compiling it, but of course for Windows I'll be able to make a binary release easily too so won't matter much how it was compiled (definitely nice about windows how that works).  I'm going to have to make a dependency on the libxml stuff anyways (which in perl for switchres I was just raw reading the XML my self, because I had used the perl XML stuff in an early version of genres before lrmc wrote out the .ini files and didn't like it too much cause oddly in XML it's hard to tell some things like when they have 2 display sections for multiscreen games I had to do something different to know there were 2 in Perl and C, Perl it was way more hackish I think, will find out I guess since in C I don't really want to rewrite an XML parser :).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 21, 2010, 02:33:05 am
Here's a snapshot of the C version, now able to use mame for game resolution information from the XML output again, read .ini files properly for the resolution, utilize the switchres.conf file agian and some extra command line options added.  

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

Also I have a precompiled Windows binary and needed .dll files in a .7z package included too so it doesn't have to be compiled for Windows, since needs Cygwin for that and libxml2 development packages for the mame XML output parsing.  
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: Calamity on November 21, 2010, 05:36:03 am
Is there a way to get it to keep the correct vertical frequency in that case?  I'm not sure but suspecting it's hitting the limit of the hfreq max and when it lowers it then the vertical frequency has to go up?

I think I've repaired it by placing this:

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

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

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 21, 2010, 01:36:04 pm
Is there a way to get it to keep the correct vertical frequency in that case?  I'm not sure but suspecting it's hitting the limit of the hfreq max and when it lowers it then the vertical frequency has to go up?

I think I've repaired it by placing this:

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

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



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

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

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

Also I noticed a 1 line difference in some of the vertical values, the front porch and syncpulse I think, which I'm guessing might be good or bad since the in perl it might have been doing the rounding or other math wrong.  Interesting at least, since I suspected Perl might not have handled all the rounding right for stuff like that, but interested if you see the same thing there and can tell which one is doing it correctly.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: Calamity on November 21, 2010, 03:38:52 pm
Hi bitbytebit,

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

By the way, the included dlls are only for using libxml2 or needed for something else?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 21, 2010, 03:51:16 pm
Hi bitbytebit,

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

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


Are you using --montor with two dashes, thats one thing that has changed.  The args need two dashes except -v now.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 21, 2010, 03:58:14 pm
Hi bitbytebit,

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

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


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

Also the xml library/dll is needed for it now, it's linked to it for the mame output.  Im not sure bit in windows right now you might need to have cygwin and be in a shell.  I thonk the way I run mame may be unix specific currently, need to look at that I guess.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: Calamity on November 21, 2010, 04:12:59 pm
This is what it's prompting:

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

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

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

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

Could not find height width or refresh rate to use.

C:\Emuladores\Mame v0.131>

I've also tried with Cygwin, although I have no experience with this, it prompts:
bash: switchres.exe: command not found

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 21, 2010, 04:23:34 pm
In cygwin you may need to type ./switchres.exe since it's not in the PATH in linux the cwd is not usually on the path. 

Ill look closer when I get home, path for the config may ony work of in your home directoy in cygwin too for now.  I did get the custom monitor config option working again, looks like I'll need to do some testing in windows later to run mame right.  In cygwin you'll need a mame.exe in /usr/local/bin/ too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: Calamity on November 21, 2010, 04:48:28 pm
It does work now in Cygwin with ./switchres.exe and mame.exe in /usr/local/bin.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 22, 2010, 01:35:40 am
It does work now in Cygwin with ./switchres.exe and mame.exe in /usr/local/bin.

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

I did update the Perl version and it should have the same fix for the obeying of the vertical resolution too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: Calamity on November 22, 2010, 04:01:30 am

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

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

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

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

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

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

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: Calamity on November 22, 2010, 04:16:12 am
VeS is trying the new distribution, he is finding similar issues as before using patched kernel and stuff, here is the result of his testing:

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

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

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

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

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

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


Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .28)
Post by: bitbytebit on November 22, 2010, 04:17:32 am

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

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

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

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

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

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



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

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

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

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

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

I'll have a new version with the windows compile soon that works on dos command lines hopefully soon, the windows computer is busy right now, I need to get one setup dedicated to compiling stuff I guess eventually.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: bitbytebit on November 22, 2010, 04:26:07 am
VeS is trying the new distribution, he is finding similar issues as before using patched kernel and stuff, here is the result of his testing:

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

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

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

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

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

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




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

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

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

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

The 'c' character in it tells it to use arcade mode.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: bitbytebit on November 22, 2010, 04:30:00 am
VeS is trying the new distribution, he is finding similar issues as before using patched kernel and stuff, here is the result of his testing:

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

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

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

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

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

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




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

video=DVI-I-1:640x480c

So that allows the other output to not do arcade resolutions, so normal monitors will work on the other outputs.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: Calamity on November 22, 2010, 04:44:12 am
Also besides that, which will work for normal Radeon cards, the other issue is the ArcadeVGA cards do not work with the Linux DRM code and Radeon KMS kernel modules.  Since they have a 'custom' bios and the ATI kernel developers don't know about how it works, they seem to not have supported them.  The screen will be all blurry when they do load, but it requires an extra patch and isn't worth it because it's useless and probably bad for the monitor anyways.  A work around of course would be to flash the BIOS of an AVGA with the normal one, but don't expect that to be a great option for people.  I have been wanting to do something, try to get the kernel developers to fix it, but I suspect they won't care much about getting the card to work since it's closed proprietary on what exactly is done in the BIOS different.  I also suspect the Arcade VGA Andy guy may not really want the information out anyways  and for it to work in Linux, since it's aimed at Windows users.  

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

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

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

I'll check the other stuff with VeS, btw.
Yeah I tried to ignore it/add it.  Had a patch for it, but the thing was it booted up all blurry when ignoring that string. 

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

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

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: Calamity on November 22, 2010, 05:14:11 am
Yeah I tried to ignore it/add it.  Had a patch for it, but the thing was it booted up all blurry when ignoring that string. 

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

That might work with older AVGAs, I'll tell VeS to use it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: ves on November 22, 2010, 09:10:40 am
Hi, tonight makes better evidence, however let you know that if you post without the xorg.conf and the pc monitor recognizes the edid and I load the game on the pc monitor letting it look good, then change the cable to arcade monitor and looks but out of sync, so I think that 1 error may come from the EDID of the card.

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

Here the settings I put mine.

Grub video = 640x480c

/etc/modprobe.d/radeon.conf

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

Xorg.conf

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

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

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

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

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

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

Option "DPMS" "false"

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

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

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

Option "DPMS" "true"
EndSection

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

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

Option     "ModeDebug"      "true"

Option      "ForceMinDotClock"    "3"

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

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

Option     "EnablePageFlip" "on"

Option     "ModeDebug"      "true"

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

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

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

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

EndSection



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

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


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




Greetings.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: Calamity on November 22, 2010, 09:48:48 am
Hi VeS,

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

He says that patch didn't work with AVGA3000, but maybe (hopefully) we can make it work with our AVGA9250.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: bitbytebit on November 22, 2010, 11:04:57 am
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: dmarcum99 on November 22, 2010, 12:54:11 pm
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: bitbytebit on November 22, 2010, 01:16:09 pm
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: bitbytebit on November 22, 2010, 01:40:35 pm
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: dmarcum99 on November 22, 2010, 02:08:09 pm
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

#
     "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?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: bitbytebit on November 22, 2010, 03:24:47 pm
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: Calamity on November 22, 2010, 05:41:42 pm
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 (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.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: bitbytebit on November 22, 2010, 06:06:48 pm
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
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: Calamity on November 22, 2010, 06:10:03 pm
I'm testing the 1.00h version now and it works really really well, no issues yet with any game I've tried:

Quote
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

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver .29)
Post by: Calamity on November 22, 2010, 06:46:01 pm
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: bitbytebit on November 22, 2010, 10:44:12 pm
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. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: Calamity on November 23, 2010, 07:03:31 am
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).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: ves on November 23, 2010, 09:06:15 am
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: bitbytebit on November 23, 2010, 09:46:56 am
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).

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: Calamity on November 23, 2010, 09:52:18 am
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?).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: bitbytebit on November 23, 2010, 11:55:09 am
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?

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: Calamity on November 23, 2010, 12:15:48 pm
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.)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: bitbytebit on November 23, 2010, 12:20:58 pm
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: Calamity on November 23, 2010, 12:39:11 pm
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: dmarcum99 on November 23, 2010, 12:47:41 pm
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?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: Calamity on November 23, 2010, 01:06:02 pm
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: bitbytebit on November 23, 2010, 01:31:04 pm
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. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: Calamity on November 23, 2010, 01:58:09 pm
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).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: bitbytebit on November 23, 2010, 02:06:10 pm
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: bitbytebit on November 23, 2010, 03:27:23 pm
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.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: Calamity on November 23, 2010, 04:30:00 pm
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
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00i)
Post by: bitbytebit on November 23, 2010, 04:44:20 pm
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?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00j)
Post by: Calamity on November 23, 2010, 04:58:26 pm
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
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00j)
Post by: bitbytebit on November 23, 2010, 05:25:05 pm
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. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00j)
Post by: bitbytebit on November 23, 2010, 05:51:14 pm
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).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00j)
Post by: Calamity on November 23, 2010, 06:29:37 pm
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...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00j)
Post by: Calamity on November 24, 2010, 05:27:31 am
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.)

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00j)
Post by: bitbytebit on November 24, 2010, 10:14:13 am
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 :).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00k)
Post by: bitbytebit on November 24, 2010, 02:04:03 pm
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r84)
Post by: bitbytebit on November 25, 2010, 02:25:26 am
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r84)
Post by: Calamity on November 25, 2010, 09:11:42 am
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r84)
Post by: bitbytebit on November 25, 2010, 12:56:53 pm
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. 
  
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r84)
Post by: Calamity on November 25, 2010, 01:31:05 pm
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r84)
Post by: bitbytebit on November 25, 2010, 02:02:40 pm
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. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r84)
Post by: Calamity on November 25, 2010, 02:30:56 pm
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.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r84)
Post by: bitbytebit on November 25, 2010, 02:41:47 pm
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.


Yeah it seems like Ubuntu would be great, but digging into it more it just looks like they don't want you to customize it or at least don't very well support it (and instead actually seem like the Ubuntu alterations/patches work against it). 

I always thought Gentoo was the easiest to build a distribution from, because you just untar two main archives to a partition, compile/install a kernel, setup a few of the system files, run a few commands to install the packages you want.  Now to get a distribution out of that, once you've setup a base image and then need some easier features for administration of the system, it might get trickier.  If it was setup though to be for one purpose, like running emulators and having a custom installed X Windows and patched linux kernel, xorg.conf for ATI Radeon cards and basic networking and such.  That might be possible, it just wouldn't work great as a generalized desktop system for everybody to use if they weren't specialized for something like our needs.  For a desktop system, you would have to develop the whole administration interface to change the system around for all the different desktop apps and other setups people might want.  Since we are focused on the arcade monitor and having full control of it, using mostly Radeon cards or other ATI cards, I think Gentoo would be able to do that and be put onto a CD/DVD and easily install systems from.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r84)
Post by: Calamity on November 25, 2010, 04:46:30 pm
So by now I think we should try to replicate what you have there, start with Gentoo and eventually when we have it running with no issues then try to get a distribution out of it. And yes, we just wanted a preconfigured system specific for cabs, it would be nice to have a live cd that was even able to read roms from the hard drive's roms directory at a given path, so you could just burn one cd and start your cab with it, to see the difference and how this modelines really work.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r84)
Post by: bitbytebit on November 25, 2010, 05:07:35 pm
So by now I think we should try to replicate what you have there, start with Gentoo and eventually when we have it running with no issues then try to get a distribution out of it.


Sounds good, the README_Gentoo file and GA.sh script from the older SwitchRes archives of the Perl version have all the information to mostly setup the base system, and what I did basically, at this point the kernel needs to be built and a few system files setup, the genkernel package in gentoo is really easy to use for this using 'genkernel --menuconfig all' does it all for you, except entering the grub.conf entry for it. The GA.sh script does the SDL/mame installation and of course the modular GIT archive for Xorg is done before that to build the base X Windows system.  The major difference of course from those instructions would be to use /usr/ instead of /GA/, I just did that for putting it all on a current system with X already installed to have it separate.  Downloading the 2 Gentoo base .tgz file and portage will give a basic partition the needed files for a skeleton system needing the packages I list installed with emerge/portage, and then can get the GIT package for Xorg modular and following the way to use the build.sh file from there install X, and then use GA.sh to download and install SDL/mame (which you can of course redo mame installation again after that to more tweaking.  Of course there's a few extra things I probably left out, main thing is that running emerge --search "package" to find things, emerge -av "package" to install, look under /usr/portage/ for packages, to build all the emulators may need dependencies.  Also a key is installing portage packages may try and install extra Xorg stuff because it depends on it.  I'd say let it, then redo the Xorg GIT install with modular and then run the command possibly to reinstall/compile the packages that depended on X and installed them (or there might be a command even with emerge to not download extra stuff like depencies of X since we have our own install).  Might even be a way to setup portage overrides to force X to use the newest versions, could be ones already there that have to be 'unmasked'.  The Gentoo website basic howto really tells simple step by step instructions which Ves could use if he needed.  Basically with Gentoo it would really be a fully custom compiled Linux system, but all taken care of the details by portage/emerge.  So in the end, this would make a really nice system.  Getting to know Gentoo, if he doesn't, would probably be a very good thing because sounds like it'd really be the best route for all this.  As long as it's centered at just arcade emulation, running mame or other emulators, no desktop expectations, it should be pretty easy and basic.  I'd recommend a lightweight window manager like fvwm, I use that and can provide any help with a basic config file and window desktop that allows things to work right, wahcade is really nice and I have had very good luck getting it to have all the emulators setup in it.  I definitely can give any help needed on setting up the system, have built Linux distributions, was years ago, Gentoo is closest I've ever seen to the steps to custom build one like I originally did completely from sources part by part, but automates it all for you pretty much besides the main steps you go through to partition/setup a fresh install.  It might be lower level on how it's installed to the users diskdrive, I don't know what level Ves has his distributions install at.  It'd definitely be great though  do it this way in the end, plus a Gentoo system in theory with this setup would be very easy to maintain updating it forever, there aren't blocks where you have to reinstall to upgrade ever.  I have a system I've ran for 3 years and can keep it up to date still with the most current Gentoo packages, with Ubuntu it'll make you reinstall each jump so the distribution would have to be refactored from each of those jumps every few months to a year or how often they release.  There's also some advanced ways to have overlays I guess, basically you can take Gentoo, make your own portage system in a sense so it would know about the newer Xorg we use and a mame install with our patches, the kernel with our patches, all built into the main packaging system for it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r84)
Post by: bitbytebit on November 26, 2010, 06:17:25 am
So by now I think we should try to replicate what you have there, start with Gentoo and eventually when we have it running with no issues then try to get a distribution out of it. And yes, we just wanted a preconfigured system specific for cabs, it would be nice to have a live cd that was even able to read roms from the hard drive's roms directory at a given path, so you could just burn one cd and start your cab with it, to see the difference and how this modelines really work.


I'm doing an experiment using this page http://en.gentoo-wiki.com/wiki/Build_Your_Own_LiveCD_or_LiveDVD (http://en.gentoo-wiki.com/wiki/Build_Your_Own_LiveCD_or_LiveDVD) as a reference and also the 'x11' overlay http://www.gossamer-threads.com/lists/gentoo/dev/188190 (http://www.gossamer-threads.com/lists/gentoo/dev/188190) which basically makes the x11 used the newest one from GIT.  It looks to me like this will essentially build a duplicate of what I have, and also can build a liveCD distribution which is a start and that much closer to a local installed system (basically could be either one, just take out the livecd specifics).

More info on overlays: http://www.gentoo.org/proj/en/overlays/userguide.xml (http://www.gentoo.org/proj/en/overlays/userguide.xml)

So hopefully this will help Ves, and I'm hopefully going to get a liveCD that may just be able to run I hope, I'm building a script and system files setup to be able to show how to do it and recreate it too.

Here's a basic script, not fully tested because I'm at the stage where it downloads all the packages and recompiles everything (will take all night or longer)...
Code: [Select]

#!/bin/sh

if [ $1 = "32" ] ; then
        export DO32BIT="linux32"
fi

# If you have not already installed these tools
emerge -av squashfs-tools cdrtools
export LIVECD=/GentooArcade
mkdir -p ${LIVECD}/source

cd ${LIVECD}/source
if [ $1 = "32" ] ; then
        tar -xvjpf ${LIVECD}/stage3-i686-20101116.tar
else
        tar -xvjpf ${LIVECD}/stage3-amd64-20101021.tar.bz2
fi

tar xvjf ${LIVECD}/portage-latest.tar.bz2 -C usr

cd ${LIVECD}/source
mkdir -p proc dev sys
mount --bind /proc proc
mount --bind /dev dev
mount --bind /sys sys

cp -L /etc/resolv.conf ${LIVECD}/source/etc/
#mkdir -p ${LIVECD}/source/etc/portage/
#echo "dev-lang/perl -minimal" >>${LIVECD}/source/etc/portage/package.use
cp -f ${LIVECD}/fstab ${LIVECD}/source/etc/
cp -f ${LIVECD}/make.conf ${LIVECD}/source/etc/
if [ $1 = "32" ] ; then
        echo "CHOST=\"i686-pc-linux-gnu\"" >> ${LIVECD}/source/etc/make.conf
else
        echo "CHOST=\"x86_64-pc-linux-gnu\"" >> ${LIVECD}/source/etc/make.conf
fi
cp -f ${LIVECD}/net ${LIVECD}/source/etc/conf.d/

${DO32BIT} chroot . /bin/bash --login

#
# now we are in the chrooted environment
#
env-update && source /etc/profile
echo "Set password for the root user:"
passwd # set the root password for the new environment in case of problems later

# Basic system information
export HOSTNAME="arcade"
export DOMAIN="groovy.org"
export TIMEZONE="America/Chicago"

cp /usr/share/zoneinfo/${TIMEZONE} /etc/localtime
cd /etc
echo "127.0.0.1 ${HOSTNAME}.${DOMAIN} ${HOSTNAME} localhost" > hosts
sed -i -e 's/HOSTNAME.*/HOSTNAME="${HOSTNAME}"/' conf.d/hostname
hostname ${HOSTNAME}
hostname -f

# Localization
echo "en_US.UTF-8 UTF-8" > /etc/locale.gen
locale-gen

# Get x11 Overlay
emerge --sync
emerge -av vim git autounmask layman
layman -L
layman -a x11
echo "source /var/lib/layman/make.conf" >> /etc/make.conf
# Unmask x11 overlay
ls /var/lib/layman/x11/*/*/*.ebuild| sed -e s/\.ebuild//g|sed -e     s/\\/var\\/lib\\/layman\\/x11\\///g|awk -F "/" '{ printf("autounmask %s/%s\n", $1,$3) }' |tr '\n' '\n' >/root/unmask_x11.sh
sh /root/unmask_x11.sh
rm -f /root/unmask_x11.sh

emerge -v -e system
emerge -v -e world
emerge -v xorg-server x11 mesa libdrm libsdl \
        memtest86+ localepurge genkernel gentoolkit dmraid \
        livecd-tools emerge scripts mingetty grub \
        chardet numpy pygobject setuptools fvwm \
        radeon-ucode vixie-cron talloc zlib dhcpcd openssh \
        alsa-utils alsa-headers alsa-firmware mercurial \
        subversion libxml2 nasm rar syslog-ng \
        mercurial zip vim unzip vim \
        libpthread-stubs intltool automake automake-wrapper \
        libxslt gperf freetype fontconfig makedepend talloc \
        libpng xkbcomp pygame pygtk gconf

#
# Exit CHROOT
#
exit
# Now outside the chroot, put the environment back
cd ${LIVECD}/source
umount sys proc dev usr/portage/distfiles
env-update
source /etc/profile

mkdir -p ${LIVECD}/target/files/source
rsync --delete-after --archive --hard-links --quiet \
        ${LIVECD}/source/boot ${LIVECD}/target/

cp -a ${LIVECD}/source/isolinux ${LIVECD}/target

rsync --delete-after --archive --hard-links \
        ${LIVECD}/source/ ${LIVECD}/target/files/source


#
# Build Live CD
#

cd ${LIVECD}/target/files
rm -f ${LIVECD}/target/livecd.squashfs
mksquashfs source/ ${LIVECD}/target/livecd.squashfs

touch ${LIVECD}/target/livecd

cd ${LIVECD}
mkisofs -R -b boot/grub/stage2_eltorito \
        -no-emul-boot -boot-load-size 4 -boot-info-table \
        -iso-level 4 -hide-rr-moved -c boot.catalog \
        -o ${LIVECD}/livecd.iso -x files ${LIVECD}/target/
#
# Making changes to live CD
cd ${LIVECD}/source
mount -o bind /proc proc
mount -o bind /sys sys
mount -o bind /dev dev
mount -o bind /usr/portage/distfiles usr/portage/distfiles
chroot . /bin/bash --login
#Chroot to 32 bit environnment if you plan to use the livecd on different arch
linux32 chroot . /bin/bash --login
env-update
source /etc/profile
# LIVECD UPDATE STARTS HERE
# MAKE HERE THE DESIRED UPDATES, for example :
emerge --sync
emerge world
freshclam
# LIVECD UPDATE ENDS HERE
exit
umount sys proc dev usr/portage/distfiles
env-update
source /etc/profile
#




Of course you can't run this script itself, must be split up to the chroot part because after that point it won't run the code since the script is outside the chroot (thinking of making 2 scripts and the middle is in the chroot section, that'd probably do it).  Also I'm to the part where I'm doing the emerge of all the packages, so I haven't tested past that point.  Yet this again should show Ves essentially the basics I think of getting a Gentoo build/install with the newest Xorg setup which would support things properly.  Also I haven't added in the kernel setup/patching/build part yet which goes in there around the exit of the chroot, plus need to setup grub in there, that page link explains it all.

Also if you see the part where I autounmask a list of packages for the x11 overlay, that is a trick that bypasses the issues in the second link I put above.  By default you can't install them, they are masked, but that'll undo it and it seems to be now installing them. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: Calamity on November 26, 2010, 01:17:39 pm
Hi bitbytebit, thanks a lot for all that info and material, it will definitely help us.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: bitbytebit on November 29, 2010, 07:08:53 pm
Hi bitbytebit, thanks a lot for all that info and material, it will definitely help us.

Update on this, I've finally gotten a pretty nice LiveCD using Gentoo and almost exactly my working setup, linux kernel patch, and auto creation of xorg.conf with the changes necessary to it.  I'm right now improving the console menu, but also here's an interesting Perl script that will create a xorg.conf dynamically when given either cga or d9800 or multi as the command line option.  "create_xorg.pl d9800 > xorg.conf".  If ran on the Linux console, it'll use Xorg and edit the output with the correct h/v ranges and proper default modes and debugging output options.  Should have the scripts and files to create the build for the live CD and an iso for 32 bit pretty soon, for a good basic framework/example and possibly nice bare bones mame/emulator system in Linux utilizing all the newest DRM Kernel Mode Switching and vsync openGL stuff, boot up with a frame buffer console on arcade monitors.

Code: [Select]

#!/usr/bin/perl

$monitor = "cga";

if ($ARGV[0] ne '') {
        $monitor = $ARGV[0];
}
print "# $monitor Monitor configuration\n\n";

my $hfreq_range = "";
my $vfreq_range = "";

if ($monitor eq 'cga') {
        $hfreq_range = "15.250-16.500";
        $vfreq_range = "50-60";
} elsif($monitor eq 'd9800') {
        $hfreq_range = "15.1-38";
        $vfreq_range = "40-85";
}

`Xorg -configure 2>&1 >/dev/null`;

my @newfile = `cat xorg.conf.new`;
my $in_monitor = 0;
my $in_device = 0;
foreach(@newfile) {
        my $line = $_;
        chomp ($line);
        if ($line =~ /^Section \"Monitor\"/) {
                $in_monitor = 1;
        } elsif ($line =~ /^Section \"Device\"/) {
                $in_device = 1;
        } elsif ($line =~ /^EndSection/) {
                if ($in_monitor) {
                        if ($hfreq_range && $vfreq_range) {
                                print "\tHorizSync $hfreq_range\n";
                                print "\tVertRefresh $vfreq_range\n";
                                print "\tOption \"DefaultModes\" \"False\"\n";
                                print "\tUseModes \"ArcadeModes\"\n";
                        }
                        $in_monitor = 0;
                } elsif ($in_device) {
                        print "\tOption \"ModeDebug\" \"True\"\n";
                        $in_device = 0;
                }
        }
        print "$line\n";
}

if ($hfreq_range && $vfreq_range) {
        @mode = `switchres 640 480 60.00 --monitor $monitor`;
        foreach (@mode) {
                chomp($_);
                $_ =~ s/\s+/ /g;
                $_ =~ s/^\s//g;
        }

        print "\nSection \"Modes\"\n";
        print "\tIdentifier \"ArcadeModes\"\n";
        print "\t$mode[1]\n";
        print "\t$mode[2]\n";
        print "EndSection\n\n";
}



Basically I've got a build script for creating the system in a directory, runs a separate script in the chroot of that directory to fully setup the system.  There's a few files I have that are copied there, then after that I have a script that can copy that base directory of the system and tailor it into an iso image which currently is only 250 meg and contains mame/mess/zsnes/nestopia/stella/mupen64plus emulators and fully working X Windows from GIT and 2.6.37-rc3 patched kernel with should work on every system possible (from basic Ubuntu .config file), and wahcade right now ready to be setup.  Right now I am looking at the ways to have a drive to use as the ROM directory and other to use for the home directory for the arcade user on it, so they can save stateful information and actually have ROMs to use (have the freely distributable ones on there by default to test). 

So it's sort of a proof of concept to show the most current Linux stuff and switchres working together, but also not looking too bad either as more than that eventually with some more intelligence in how it sets up the writable drives/network and finishing rough edges that may exist.  I figured this xorg.conf creator was pretty useful since it automatically adds the missing parts to allow the X Windows default modes not to happen and can add the correct ranges in needed for arcade monitors.

It'll hopefully give a good template at least, I have done quite a bit extra stuff than on that site to really make this work, but have preserved it all into scripts so hopefully it's now correct and easy to reproduce.  Also I suspect it's not too much of an issue to turn the build into a hard drive install, and I am going to try building the 64 bit version which mostly should just work unless I have bugs in running it for a 64 bit mode build.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: bitbytebit on November 30, 2010, 06:58:18 pm
Hi bitbytebit, thanks a lot for all that info and material, it will definitely help us.

Experimental 32 bit and 64 bit liveCD using Gentoo and my kernel patch and switchres to demonstrate it quickly without any difficult work building a system and patching etc...

http://arcade.groovy.org/ (http://arcade.groovy.org/)

I'm curious about how this works, issues with it or improvements that could be done.  Simple choice of boot up frame buffer types (640x480/800x600/1024x768 in 15-16Khz and SVGA modes), basic console menu to setup a possible mount of /data/ containing roms, possible /home/arcade/ user mount to preserve changes each boot, network setup if desired.  It's pretty raw and basic, but in testing works quite well and most importantly recreates the results I've had with vsync and resolution/mode flexibility and console boot up on an arcade monitor.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: Calamity on December 01, 2010, 04:50:52 am
Great! I'll test it this evening! Thank you very much for doing this. Just one question: is it set for D9800 or can I set it up to work with H9100? I understand that the script you posted above is for the case when it's installed, not for the livecd, isn't it?

I have good news with Catalyst 9.3. After some days messing with it and many blue screens I've been able to patch it so now I have a version that supports up to 137 custom modelines (it was limited to 60) and have removed the problem of hardcoded doublescan with 320x and 400x resolutions.

But the most important is that we have dynamic modelines with this Catalyst too. I've been investigating this dynamic stuff and have found that it's probably been there all the time, so there's no need to do any patching to achieve it. However, for some reason it only works when we have more than 16 custom resolutions defined. There's something else I've seen: in order to force the driver to read the modelines without restarting the system, it seems we only need to call the EnumDisplaySettings API, so it makes things easier than the twisted method I posted before in this thread. In fact that method only worked because it was using EnumDisplaySettings at some point, so the rest of it was just unnecessary. So this can be the key to have dynamic modelines in Windows for the newer ATI cards (up to 4000 family only). Unfortunately, we can't define new modes on the fly, only modify the existing ones, that's why it's important to have more than 60 modes in order to organize a decent precalculated mode table, I think that 137 can be good enough to store the variety of Mame resolutions if we ignore vfreq (later when running Switchres we will set those resolutions to their right vfreq in each case). So it won't be so clean as the way you use in Linux, as this precalculated table is not fully dynamic, and it will need some coding overhead, but the results can be just as good.

I still need to do a lot of tests with this. I've also want to test this with HD4350 I've just received, as by now all the test have been done with a X300.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: bitbytebit on December 01, 2010, 06:27:57 am
Great! I'll test it this evening! Thank you very much for doing this. Just one question: is it set for D9800 or can I set it up to work with H9100? I understand that the script you posted above is for the case when it's installed, not for the livecd, isn't it?

It should work with the H9100/d9200/9800/CGA/SVGA types, I actually changed how I did that.  Basically now on bootup you have a boot menu which is going to have to be in the bios mode output so an Arcade Monitor user won't see that.  That's ok because it defaults to the choice for 15.650 Khz mode, only SVGA or D9800 users would find use to change up to 800x600 or just normal SVGA mode.  Then when the kernel bootup happens it kicks into DRM mode and then you'll see the rest of the bootup.  I don't think we'll ever fix it so we can see the grub boot prompt, just like we can't in Windows either.  Grub does have a video mode thing in it but it's only able to use VESA bios modes or something.  I don't know if it can really be more flexible, or changed to be 15Khz too, I am looking at that some but I don't know if it's really necessary though.

Once booted it'll just have a console with a few questions and one is asking your monitor type, so then it'll use that script or another to create a basic xorg.conf with a 648x480 modeline for the desktop.  Then you can start X Windows from that menu, and go from there (right now probably easiest to open an xterm/terminal with a right click and choosing 'new' from the right mouse menu, and using switchres on the command line for games, which it has all the legally distributable ones from the main site on /data/roms/ by default unless you tell it a drive with them.).  It's definitely a bit rough on the way the menu and stuff works, unless you have the /data directory filled with your roms and then run wahcade setup and have it rescan to run switchres for you.  There's lots of room for improvement there, so any issues you have or suggestions on ways it's confusing would be great.



I have good news with Catalyst 9.3. After some days messing with it and many blue screens I've been able to patch it so now I have a version that supports up to 137 custom modelines (it was limited to 60) and have removed the problem of hardcoded doublescan with 320x and 400x resolutions.

But the most important is that we have dynamic modelines with this Catalyst too. I've been investigating this dynamic stuff and have found that it's probably been there all the time, so there's no need to do any patching to achieve it. However, for some reason it only works when we have more than 16 custom resolutions defined. There's something else I've seen: in order to force the driver to read the modelines without restarting the system, it seems we only need to call the EnumDisplaySettings API, so it makes things easier than the twisted method I posted before in this thread. In fact that method only worked because it was using EnumDisplaySettings at some point, so the rest of it was just unnecessary. So this can be the key to have dynamic modelines in Windows for the newer ATI cards (up to 4000 family only). Unfortunately, we can't define new modes on the fly, only modify the existing ones, that's why it's important to have more than 60 modes in order to organize a decent precalculated mode table, I think that 137 can be good enough to store the variety of Mame resolutions if we ignore vfreq (later when running Switchres we will set those resolutions to their right vfreq in each case). So it won't be so clean as the way you use in Linux, as this precalculated table is not fully dynamic, and it will need some coding overhead, but the results can be just as good.

I still need to do a lot of tests with this. I've also want to test this with HD4350 I've just received, as by now all the test have been done with a X300.



Wow, that sounds really great.  So what part of the modeline can we modify, is it just the back porch front porch sync pulse stuff, dotclock or just active lines?  Sounds interesting, great that it turns out it's simpler to reload it and excited to get that working.  The couple parts I didn't fully look at is the format that Windows stores the details of the modelines, looked like it's a bit different I'm guessing, or at least stored oddly from what I can tell.  I'll have to start looking at that again, was interested in the read/write part of the modeline details.  Now that I think about it, I think I understand what your saying and the part I've read so far with the basic active h/v lines are not changable after bootup, yet the part I haven't dived into reading with the details (and can alter the refresh rate) is the changeable part and changes the refresh rate of course since that one in Windows is just a label in a sense.  So I am guessing what I currently do with looking at those hxw combos is the first step, then once the best fit is found we'd go in and alter the rest to fit our needed vertical refresh or get as close as possible (just using our current modeline calculations with that hxw), then call that EnumDisplaySettingsAPI call.  Also would need to go in and add custom resolutions with some preset amount we come up with that should generally fit about every game but not always be without some padding.  That sounds very cool, and I'm guessing I should some what be able to experiment with that some even with unpatched drivers for now, just limited in modelines for 60 of them right now. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: Calamity on December 01, 2010, 08:02:24 am
Ok, I see what you mean with the livecd setup, perfect. However, this is something I've always wondered when talking with VeS also: is there a direct way to just read C:\Roms\Mame from our Windows partition and use it with Linux?

The part we must keep for each mode is the active resolution width x height and the refresh label. So for convenience we could preset all modes to 60 Hz, and then tweak them before invoking Mame. So we would be using i.e. 320x240@60 label whatever vfreq we have. We have also the possibility of leaving vfreq label undefined when creating the mode in DALNonStandardModes, so the system would have an unique modeline choice for each resolution, however I haven't tested this yet so I believe it's more secure to stick with the 60 Hz label instead.

There's something interesting I've seen with this version: I can't use my xres increment trick for resolutions with similar vfreq I've been using previously. For some reason this Catalyst is overriding the mode label with the xres, yres values directly from the modeline definition, but it's not enough with using i.e. 321 there, as then surprisingly 320 and 321 defined modes will collapse into the same mode, ruining the results. It would be a big problem if we wanted to use an static mode list as I've been doing, but doesn't matter as we are going to change vfreq on the fly.

There's something else: the precalculated dotclocks values I've been using also seem to be correct with this combination of X300 + Catalyst 9.3. I still have to test them with HD4350 to draw conclusions.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: bitbytebit on December 01, 2010, 08:55:00 am
Ok, I see what you mean with the livecd setup, perfect. However, this is something I've always wondered when talking with VeS also: is there a direct way to just read C:\Roms\Mame from our Windows partition and use it with Linux?

Yes, it'll read NTFS partitions in Linux and should be able to do that, although the whole logic of where the ROMS are located will need to be setup of course different than what I currently have hard coded.  If a partition is mounted though as the user directory, like a USB stick/drive possibly, then that would be able to keep the setup of course and that could be one way a person could choose right now and have a pretty nice stateful setup.  You can't write to an NTFS partition from Linux, and I don't have it mount the ROMS partition writable anyways for safety, it only mounts the point if chosen for the arcade user home directory as writable.  There's a basic set of config files for that user in the /home/arcade/ directory, bunch of . dot files mainly, which are pretty useful and should be copied to any writable extra partition/drive used.  Also there's the creation/formatting of the partition which isn't done automatically since right now it's assumed there's already a setup partition for the home directory.  That process of partitioning/formatting is pretty easy on the command line but of course best to use a script to walk through it, and definitely starts to get into some possible danger there if not carefully done. 

I think I have a 64 bit build now, have to test, and also will show me if my whole setup scripts to create the whole thing from scratch are really working right.  I've got that all grouped into a set of scripts to basically run and build the complete development environment, so pretty much all documented on how to create the entire thing in a small bundle of files.


The part we must keep for each mode is the active resolution width x height and the refresh label. So for convenience we could preset all modes to 60 Hz, and then tweak them before invoking Mame. So we would be using i.e. 320x240@60 label whatever vfreq we have. We have also the possibility of leaving vfreq label undefined when creating the mode in DALNonStandardModes, so the system would have an unique modeline choice for each resolution, however I haven't tested this yet so I believe it's more secure to stick with the 60 Hz label instead.

There's something interesting I've seen with this version: I can't use my xres increment trick for resolutions with similar vfreq I've been using previously. For some reason this Catalyst is overriding the mode label with the xres, yres values directly from the modeline definition, but it's not enough with using i.e. 321 there, as then surprisingly 320 and 321 defined modes will collapse into the same mode, ruining the results. It would be a big problem if we wanted to use an static mode list as I've been doing, but doesn't matter as we are going to change vfreq on the fly.

There's something else: the precalculated dotclocks values I've been using also seem to be correct with this combination of X300 + Catalyst 9.3. I still have to test them with HD4350 to draw conclusions.


Interesting, I'm guessing they are aligning everything to 8 then or something, but rounding down possibly?  Also seems like they are are now listening to the actual setting for active lines instead of the label when choosing resolutions, which is how Linux does it through the SDL layer. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: dmarcum99 on December 01, 2010, 09:21:34 am
Hi Guys!

This is good news!!  I can't wait to try out the 64-bit Gentoo Live CD that you're talking about.  I am having good success with switchres as well.  Very impressive!!

I have a question for Calamity...sorry I don't mean to hijack.  :(  Calamity, I have been playing with your hacked 9250drivers and arcade_osd.exe program.  With this program, I can go in and tweak my modeline without having to reboot into dos and play with advv.  I am taking it slow since my time is limited, but for those games where my original modelines were off-centered or over-scanned, this really helped out.  I really want to make use of my 64-bit processor and my radeon 9200SE, but there are no XP 64-bit drivers for this video card.  Is this something you can cook up or is there a good reason why there isn't a 64-bit driver avail?  If I want to go 64-bit, right now I have to use my X850XT and the fan makes it sound like I have a carpet cleaner in my cab!
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: bitbytebit on December 01, 2010, 10:22:58 am
Hi Guys!

This is good news!!  I can't wait to try out the 64-bit Gentoo Live CD that you're talking about.  I am having good success with switchres as well.  Very impressive!!

I have a question for Calamity...sorry I don't mean to hijack.  :(  Calamity, I have been playing with your hacked 9250drivers and arcade_osd.exe program.  With this program, I can go in and tweak my modeline without having to reboot into dos and play with advv.  I am taking it slow since my time is limited, but for those games where my original modelines were off-centered or over-scanned, this really helped out.  I really want to make use of my 64-bit processor and my radeon 9200SE, but there are no XP 64-bit drivers for this video card.  Is this something you can cook up or is there a good reason why there isn't a 64-bit driver avail?  If I want to go 64-bit, right now I have to use my X850XT and the fan makes it sound like I have a carpet cleaner in my cab!

The 64bit system build is looking good, should be up in a day or less, need to investigate how to get my gens build working since it doesn't do 64bit.  I'm surprised that gens seems like the  only issue right now, thought there'd be more issues between the 32 vs. 64 bit build with my scripts but luckily not.  Of course another thing I need to do for both .iso images is figure out the right configuration to make all the emulators besides mame/mess/mupen64plus/stella (which all behave nicely) actually not try to call the GUI interface and load the ROM as smooth as mame does from wahcade or other frontends.  I had all that working in the past, each one (nestopia/zsnes) has a slight different config file tweak to kick them into gear, plus gens is weird and likes to just load 640x480 with a tiny picture else it's off center which is another issue I've not fully figured out.

Yeah my X850 ATI card sounds like that too :D besides the fact mines the crossfire edition with no special cable that you can't get for less than 100 dollars to allow 2 video outputs, the noise alone makes me not use that card right now in anything.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: Calamity on December 01, 2010, 11:06:06 am
Bitbytebit: the megaupload link you posted seems temporaly disabled...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: bitbytebit on December 01, 2010, 11:10:43 am
Bitbytebit: the megaupload link you posted seems temporaly disabled...


Strange, I'll look at getting something better like a dropbox account possibly.  I'm wondering if it'll show back up in a bit, megaupload is odd I guess, I can't even really see in my account that I uploaded the file but the link worked at least a few minutes after I posted it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: Calamity on December 01, 2010, 11:14:29 am
Strange, I'll look at getting something better like a dropbox account possibly.  I'm wondering if it'll show back up in a bit, megaupload is odd I guess, I can't even really see in my account that I uploaded the file but the link worked at least a few minutes after I posted it.

Yes, that happened to me too when uploading drivers there, it might be back by itself later.

I have a question for Calamity...sorry I don't mean to hijack.  :(  Calamity, I have been playing with your hacked 9250drivers and arcade_osd.exe program.  With this program, I can go in and tweak my modeline without having to reboot into dos and play with advv.  I am taking it slow since my time is limited, but for those games where my original modelines were off-centered or over-scanned, this really helped out.  I really want to make use of my 64-bit processor and my radeon 9200SE, but there are no XP 64-bit drivers for this video card.  Is this something you can cook up or is there a good reason why there isn't a 64-bit driver avail?  If I want to go 64-bit, right now I have to use my X850XT and the fan makes it sound like I have a carpet cleaner in my cab!

I'm glad to hear that Arcade_OSD has been useful for you. Unfortunately I haven't done any testing with 64-bit XP or its drivers. From time to time, ATI drops support for its older cards and places them in a legacy driver structure, as far as I know, this has happened twice:

- Catalyst 6.5 -> rebuilt as legacy 6.11
- Catalyst 9.3 -> rebuilt as legacy 10.2

The Radeon 9200 family was dropped since Catalyst 6.6 (first of the above branching) so from there on there are not new drivers available for them, I suppose that includes 64-bit support, so the only possibility would be to force the newer drivers to accept older cards, something that is definitely possible by properly editing driver ini & inf files, though I have not ever tested, and would probably produce blue screens.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: bitbytebit on December 01, 2010, 11:38:17 am
Ah I now realize I could have just used Sourceforge since they'll support large files over 1Gig so these should be fine at 255 and 355 meg (32bit and 64bit).  I'll get them uploaded there, both should be ready, just have to run a quick test on them first.  I fixed an issue with proper setup of the arcade user home directory so this will be better anyways than the one at megaupload.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: bitbytebit on December 01, 2010, 12:38:20 pm
I have 32bit and 64bit version ISO's uploaded, and a git repository containing the scripts that build the distribution/LiveCD ISO.  The scripts mostly download everything needed extra, the Gentoo base files, you'll just need to manually download the right Linux kernel (README file explains more).  Total a build directory takes about 5-6 gig of space per architecture, and takes about a day to completely build, might be a few bugs still but seemed to mostly work smooth when I built the 64bit version.  So Ves may want to look at the git repository for this on the sourceforge site...

arcade.groovy.org (http://arcade.groovy.org)

Update: 32bit one is done uploading, and 64bit one too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: bitbytebit on December 02, 2010, 11:51:52 am
Great! I'll test it this evening! Thank you very much for doing this. Just one question: is it set for D9800 or can I set it up to work with H9100? I understand that the script you posted above is for the case when it's installed, not for the livecd, isn't it?

I have good news with Catalyst 9.3. After some days messing with it and many blue screens I've been able to patch it so now I have a version that supports up to 137 custom modelines (it was limited to 60) and have removed the problem of hardcoded doublescan with 320x and 400x resolutions.

But the most important is that we have dynamic modelines with this Catalyst too. I've been investigating this dynamic stuff and have found that it's probably been there all the time, so there's no need to do any patching to achieve it. However, for some reason it only works when we have more than 16 custom resolutions defined. There's something else I've seen: in order to force the driver to read the modelines without restarting the system, it seems we only need to call the EnumDisplaySettings API, so it makes things easier than the twisted method I posted before in this thread. In fact that method only worked because it was using EnumDisplaySettings at some point, so the rest of it was just unnecessary. So this can be the key to have dynamic modelines in Windows for the newer ATI cards (up to 4000 family only). Unfortunately, we can't define new modes on the fly, only modify the existing ones, that's why it's important to have more than 60 modes in order to organize a decent precalculated mode table, I think that 137 can be good enough to store the variety of Mame resolutions if we ignore vfreq (later when running Switchres we will set those resolutions to their right vfreq in each case). So it won't be so clean as the way you use in Linux, as this precalculated table is not fully dynamic, and it will need some coding overhead, but the results can be just as good.

I still need to do a lot of tests with this. I've also want to test this with HD4350 I've just received, as by now all the test have been done with a X300.


The new version of Switchres now looks at the real information inside the modeline instead of the label.  I realized when working on figuring out what the actual modeline data was, that the labels mean nothing, and were not even always the real heightxwidth as the active lines (my 31.5Khz Soft15Khz 1024x768 only has 600 active vertical lines set it seems).  So that makes it ready for being able to go through and look at the modelines, instead of the labels like it was doing.  I'm guessing running some sort of --init to populate all available modeline slots with dummy modelines (which now I'm guessing they really don't even matter what they are saying they are in the label, or does mame really look at that even?), then alter them before starting the game to match the game.

Actually if mame really looked at the active lines instead of the label, why not just have 1 modeline (well over 16 to kick in the autoreload) and just that one we alter and the other 16 can be way crazy ones like 1024x768 that no game would ever use.  So it'd be just like in Linux where there's only one modeline to choose from anyways.  Also with that, disable all the normal modelines, can't we do that?  and then it'd force mame to pick the one we setup, and have a basic desktop modeline with 648x480 possibly for the desk top as we do in X Windows currently.


Also is there any interaction between the active/official modelines and the custom ones, or are they totally separate from each other?  Basically after reboot, our custom ones don't also show up in the active list do they?  Something I am not fully sure of how that exactly works.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: Calamity on December 02, 2010, 01:17:35 pm
The new version of Switchres now looks at the real information inside the modeline instead of the label.  I realized when working on figuring out what the actual modeline data was, that the labels mean nothing, and were not even always the real heightxwidth as the active lines (my 31.5Khz Soft15Khz 1024x768 only has 600 active vertical lines set it seems).  So that makes it ready for being able to go through and look at the modelines, instead of the labels like it was doing.  I'm guessing running some sort of --init to populate all available modeline slots with dummy modelines (which now I'm guessing they really don't even matter what they are saying they are in the label, or does mame really look at that even?), then alter them before starting the game to match the game.

Modeline data is only supposed to be read by the driver, so no Windows programs, Mame, or even Windows itself ever reads that data, it's the driver that reads it and reports the labels as available video modes to the system. That's why all information that is used by the system API has integer values for everything, and the real vfreq values are not calculated ever, and are only the result of feeding the videocard hardware registers with modeline data, so there's no way Mame or AVres or MameResTool may know what the real vfreq will be, the only way is to read the registry and really perform the calculations as we are doing.

Actually if mame really looked at the active lines instead of the label, why not just have 1 modeline (well over 16 to kick in the autoreload) and just that one we alter and the other 16 can be way crazy ones like 1024x768 that no game would ever use.  So it'd be just like in Linux where there's only one modeline to choose from anyways.  Also with that, disable all the normal modelines, can't we do that?  and then it'd force mame to pick the one we setup, and have a basic desktop modeline with 648x480 possibly for the desk top as we do in X Windows currently.

 ;D I already had thought about that, indeed I intended to have a reserved mode named 1234x678, to do all dynamic stuff out of it! Unfortunately that's not possible. The problem is that from the system point of view, resolution labels are real. So if you have a 1234x678 label the system will reserve memory for that size, even if you define it internally as 320x240, and Mame will try center the frame (remember the problem we were having with xres increment loosing pixels on the right side).

Vfreq label is also important because if our monitor has an EDID, the system will filter the modes which vfreq is not supported by it. That's why I think we should use 60 Hz as a standard, because modes labeled with 50 Hz disappear when we connect a LCD.

Also is there any interaction between the active/official modelines and the custom ones, or are they totally separate from each other?  Basically after reboot, our custom ones don't also show up in the active list do they?  Something I am not fully sure of how that exactly works.

Built in video modes are overridden by custom ones. So if you don't define any custom modeline for 800x600, you will be able to use the built in 800x600 vga modes, with several different vfreqs: 60, 70, 72, 100, etc (if your monitor has EDID the ones it doesn't support will be removed). But if you define a custom 800x600@60 modeline, it will override the native 800x600@60, the others will still be available (this is what happens with Catalyst 9.3, however with cat 6.5 all the other vfreqs where also overriden with our custom one! I believe it was a bug).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 02, 2010, 01:38:57 pm
BTW I've finally tested HD4350 with my Cat 9.3 patched drivers, and it works flawlessly it seems. I have to connect it using the dvi with a dvi-vga adapter, otherwise I get no video, as dvi is defined as primary device in these cards. The number of total video modes is way lower than the number I was using with 6.5, so I don't get such good results with a static mode table as before. However, the aim is to get dynamic modelines with this, so it's not so important after all. Native bios modes have a slightly different frequency to the ones from previous Radeon, so even if jpac allows me to have a readable split screen during system boot, the picture is badly distorted. So I will try to have these new patched drivers ready to download for this weekend.

I have also tested your livecd in my 2 cabs:

- With ArcadeVGA 9250, I can see the boot with a perfect progressive mode (AVGA Bios), then select CGA monitor, video mode switches to what seems 640x480 31 KHz (problem I believe), split screen but still can see the system prompting stuff, then we reach the part were I select monitor, mount drive, etc. and start X-Windows, with a perfect 640x480 interlaced mode, and I think it's 32 bits color as the icons look good, although I am not sure (if it was 4 bits it would mean it's a bios mode, bad). Unfortunately, I didn't have a mouse to use around the cab in that house, so I couldn't get to click to Wahcade and try anything, but it seemed to work.

- With HD4350, unfortunately I get no video right before the part where we're asked to select monitor, mount drives and stuff, so I can't see those menus, I know the system is not locked as I still hear the cd when I choose random options from my keyboard (no picture) but haven't managed to make it load X-Windows. The boot is also difficult to see as I have that distorted picture I mentioned before, but that's not the problem. I've tried to choose from the different modes for the console at the firt menu, but nothing changes. I've also tried to start the cab either with the monitor plugged to the vga or the dvi outs, without success. I suspect of the damned EDID issue.

On the other hand, I've seen the menus and stuff and I find it clean and nice to work with, hopefully we will be able to solve those problems.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 02, 2010, 02:11:49 pm
BTW I've finally tested HD4350 with my Cat 9.3 patched drivers, and it works flawlessly it seems. I have to connect it using the dvi with a dvi-vga adapter, otherwise I get no video, as dvi is defined as primary device in these cards. The number of total video modes is way lower than the number I was using with 6.5, so I don't get such good results with a static mode table as before. However, the aim is to get dynamic modelines with this, so it's not so important after all. Native bios modes have a slightly different frequency to the ones from previous Radeon, so even if jpac allows me to have a readable split screen during system boot, the picture is badly distorted. So I will try to have these new patched drivers ready to download for this weekend.

I have also tested your livecd in my 2 cabs:

- With ArcadeVGA 9250, I can see the boot with a perfect progressive mode (AVGA Bios), then select CGA monitor, video mode switches to what seems 640x480 31 KHz (problem I believe), split screen but still can see the system prompting stuff, then we reach the part were I select monitor, mount drive, etc. and start X-Windows, with a perfect 640x480 interlaced mode, and I think it's 32 bits color as the icons look good, although I am not sure (if it was 4 bits it would mean it's a bios mode, bad). Unfortunately, I didn't have a mouse to use around the cab in that house, so I couldn't get to click to Wahcade and try anything, but it seemed to work.

- With HD4350, unfortunately I get no video right before the part where we're asked to select monitor, mount drives and stuff, so I can't see those menus, I know the system is not locked as I still hear the cd when I choose random options from my keyboard (no picture) but haven't managed to make it load X-Windows. The boot is also difficult to see as I have that distorted picture I mentioned before, but that's not the problem. I've tried to choose from the different modes for the console at the firt menu, but nothing changes. I've also tried to start the cab either with the monitor plugged to the vga or the dvi outs, without success. I suspect of the damned EDID issue.

On the other hand, I've seen the menus and stuff and I find it clean and nice to work with, hopefully we will be able to solve those problems.


Yeah the boot up part to where it finally works, that's basically where Grub is running the show and uses BIOS Vesa modes.  That part we'll never be able to change, because Grub seems pretty hard to alter and it really doesn't have room I guess to put a lot of code in to do modelines so it just chooses BIOS ones till the Linux DRM layer kicks into play.  That's when things work for at least the first card, I'm not sure what is going on with the 4350 since that's the kind I'm using, really odd.  It's 32bit color for X Windows, and basically a 640x480 60Hz interlaced modeline generated with switchres using the CGA monitor type and put statically in the kernel headers.  So since the first card works, then it means it must be something odd with the second one and the DRM layer (my 4350 is a diamond one, maybe the branding version is different and another BIOS on it than mine?).  If you can attach another computer monitor to the other input, it would maybe help a lot seeing what the dmesg output is saying or /var/log/dmesg also is the bootup messages (less /var/log/dmesg) or just (dmesg) at the command prompt.  The DRM layer messages hopefully will say something interesting, I might need to have the livecd startup with networking enabled so you can ssh into it if it's hard to get the arcade monitor and a normal monitor working together.

 I think this sequence will allow you to access it with ssh possibly and start X Windows...

1. boot up (give it a while)
2. push enter
3. type eth0
4. push enter
5. At this point should be able to ssh into box, password for root is 'arcade'
6. push enter
7. push enter
8. type h9110
9. type 1
10 push enter

That should be the sequence, and allow both remote access with ssh to see dmesg output, and see if X Windows has any better luck at showing a display.  I get the feeling possibly the DRM layer is oops'ing or something weird, but hopefully not.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 02, 2010, 02:46:48 pm
I'll try that when I get home, my card is an ATI ASUS HD4350 PCX DDR2 HDMI SILENT, btw does your D9800 have an EDID?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 02, 2010, 02:52:57 pm
I'll try that when I get home, my card is an ATI ASUS HD4350 PCX DDR2 HDMI SILENT, btw does your D9800 have an EDID?


Nope it doesn't, which the DRM patch does expect no EDID else it would probably use the EDID  information as I'm guessing it should.  So in theory you should be able to hook up a normal monitor to the other port, and get both different, although the command line option for the kernel may override that somewhat.  Another option is to try with both your cards in the system and boot up trying either/or for attaching the arcade monitor and another, see if we can get the system information of what is going on in the logs from doing that, although hopefully the remote ssh or a monitor on the second port also works.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: bitbytebit on December 02, 2010, 03:29:46 pm
The new version of Switchres now looks at the real information inside the modeline instead of the label.  I realized when working on figuring out what the actual modeline data was, that the labels mean nothing, and were not even always the real heightxwidth as the active lines (my 31.5Khz Soft15Khz 1024x768 only has 600 active vertical lines set it seems).  So that makes it ready for being able to go through and look at the modelines, instead of the labels like it was doing.  I'm guessing running some sort of --init to populate all available modeline slots with dummy modelines (which now I'm guessing they really don't even matter what they are saying they are in the label, or does mame really look at that even?), then alter them before starting the game to match the game.

Modeline data is only supposed to be read by the driver, so no Windows programs, Mame, or even Windows itself ever reads that data, it's the driver that reads it and reports the labels as available video modes to the system. That's why all information that is used by the system API has integer values for everything, and the real vfreq values are not calculated ever, and are only the result of feeding the videocard hardware registers with modeline data, so there's no way Mame or AVres or MameResTool may know what the real vfreq will be, the only way is to read the registry and really perform the calculations as we are doing.

Actually if mame really looked at the active lines instead of the label, why not just have 1 modeline (well over 16 to kick in the autoreload) and just that one we alter and the other 16 can be way crazy ones like 1024x768 that no game would ever use.  So it'd be just like in Linux where there's only one modeline to choose from anyways.  Also with that, disable all the normal modelines, can't we do that?  and then it'd force mame to pick the one we setup, and have a basic desktop modeline with 648x480 possibly for the desk top as we do in X Windows currently.

 ;D I already had thought about that, indeed I intended to have a reserved mode named 1234x678, to do all dynamic stuff out of it! Unfortunately that's not possible. The problem is that from the system point of view, resolution labels are real. So if you have a 1234x678 label the system will reserve memory for that size, even if you define it internally as 320x240, and Mame will try center the frame (remember the problem we were having with xres increment loosing pixels on the right side).

Vfreq label is also important because if our monitor has an EDID, the system will filter the modes which vfreq is not supported by it. That's why I think we should use 60 Hz as a standard, because modes labeled with 50 Hz disappear when we connect a LCD.

Also is there any interaction between the active/official modelines and the custom ones, or are they totally separate from each other?  Basically after reboot, our custom ones don't also show up in the active list do they?  Something I am not fully sure of how that exactly works.

Built in video modes are overridden by custom ones. So if you don't define any custom modeline for 800x600, you will be able to use the built in 800x600 vga modes, with several different vfreqs: 60, 70, 72, 100, etc (if your monitor has EDID the ones it doesn't support will be removed). But if you define a custom 800x600@60 modeline, it will override the native 800x600@60, the others will still be available (this is what happens with Catalyst 9.3, however with cat 6.5 all the other vfreqs where also overriden with our custom one! I believe it was a bug).


Ah so basically I need to read it to know what it actually is, but use the label for the mame command line to direct it to use that specific modeline.  Although since giving mame that size won't it not fit, if they are smaller in actual active line sizes in the actual modeline?  I guess that's where needing the 60+ modelines comes in, to match everything as exact as possible with HxW to allow the match and size of mame display to both work right.  If only it worked like in Linux and actually looked at the active parts, seems like this modeline thing and the label for them just has allowed for software to not be consistent since some look at labels, some at actual real active line information.  I now almost think the idea of having labels for modelines was a bad idea, should have always just been the raw modeline only and have that speak for itself.  It just gets way too messy all the combinations of modeline name/label formats and then how different parts of each system parses that or doesn't look at that or does look at it on some levels but not others. 

That did sound too good to be true, able to only use one main modeline.  Sounds easy though to override the built in modelines since if one exists that overlaps it sounds like it won't matter and use our custom one.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: Calamity on December 02, 2010, 04:57:14 pm
Ah so basically I need to read it to know what it actually is, but use the label for the mame command line to direct it to use that specific modeline.

Yes that's it.

Although since giving mame that size won't it not fit, if they are smaller in actual active line sizes in the actual modeline?

I guess that wouldn't work as you still need to call DirectDraw from Mame to do mode switching, and ddraw would create a framebuffer of the fake label size instead of the real one.

I guess that's where needing the 60+ modelines comes in, to match everything as exact as possible with HxW to allow the match and size of mame display to both work right.

Yes, we would need to get a list of needed modes parsing Mame.xml and ignoring vfreq value, then add a list of other emulators we want to have (that's the idea behind this ReslList.txt file I use), and see if we can keep it lower than our top number of modes. We would need some kind of normalizing of values in order to get a shorter list, probably starting with yres. This is not a problem with Mame but some emulators insist to do a dirty stretching when you give them a resolution with extra lines, so we should be able to preserve the original resolution in some cases to avoid that.

If only it worked like in Linux and actually looked at the active parts, seems like this modeline thing and the label for them just has allowed for software to not be consistent since some look at labels, some at actual real active line information.  I now almost think the idea of having labels for modelines was a bad idea, should have always just been the raw modeline only and have that speak for itself.  It just gets way too messy all the combinations of modeline name/label formats and then how different parts of each system parses that or doesn't look at that or does look at it on some levels but not others.

It's seems this is the way that driver developers have figured out to introduce modeline support in Windows. Unfortunately they decided that no one would ever need more than 60 custom video modes.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper (ver 1.00r86)
Post by: bitbytebit on December 02, 2010, 05:24:08 pm
Ah so basically I need to read it to know what it actually is, but use the label for the mame command line to direct it to use that specific modeline.

Yes that's it.

I've just fixed it so it should use the label, but yet choose by what the actual modeline is. Also now am storing the modeline data pretty much like you did, so am prepared to be able to alter any modelines seen.  My idea to make it simplest, would be to have Soft15khz be our vehicle to setup usermodes for us as the 60+ ones we have to work with.  So it can take care of dealing with all the initial setup, then past that we just fiddle with the modelines we see in switchres tuning/tweaking them to what we need. 

I had actually pretty much created a way to generate lists of the resolutions in lrmc that way pretty good, but using this modeline generator of course is needed since the generation of the list depends most likely on the monitor type and modeline generator we are using, to know what is possible and what we'll get for each game/system (using mess for the others besides mame).  I'll look at that, since creating an option to generate a usermodes.txt file for Soft15khz to input, then enabling write back to the modelines in the registry to change values to what we need, all sounds like it'll be possible pretty quickly.   

Can see the change I did in the git on sourceforge, which now is always going to be current by the minute updated since I'm using that for my GIT repository now.  I've been pretty happy with getting this all merged into one repository, which if you've not noticed now switchres source and the liveCD build script stuff is all basically together to keep things synced and simple for me to update easier.  Also now to get the base source of the livecd build git snapshots are the only option, possibly will eventually make just Windows builds and all linux/source downloads be from GIT like this.  Am slowly moving into the sourceforge site completely since it has all the space and git repository access, pretty amazing I can upload the .iso images there, I don't even know if they have a storage limit, at least anything I'd ever hit.

Commit:
http://gentooarcade.git.sourceforge.net/git/gitweb.cgi?p=gentooarcade/gentooarcade;a=commitdiff;h=4f71e754c435882ce13e720ce1b9c80308b5032c;hp=090c47b4bde46f4e069dc31ffe32817866f0b58a (http://gentooarcade.git.sourceforge.net/git/gitweb.cgi?p=gentooarcade/gentooarcade;a=commitdiff;h=4f71e754c435882ce13e720ce1b9c80308b5032c;hp=090c47b4bde46f4e069dc31ffe32817866f0b58a)

Source snapshot:
http://gentooarcade.git.sourceforge.net/git/gitweb.cgi?p=gentooarcade/gentooarcade;a=snapshot;h=refs/heads/master;sf=tgz (http://gentooarcade.git.sourceforge.net/git/gitweb.cgi?p=gentooarcade/gentooarcade;a=snapshot;h=refs/heads/master;sf=tgz)


Although since giving mame that size won't it not fit, if they are smaller in actual active line sizes in the actual modeline?

I guess that wouldn't work as you still need to call DirectDraw from Mame to do mode switching, and ddraw would create a framebuffer of the fake label size instead of the real one.

I guess that's where needing the 60+ modelines comes in, to match everything as exact as possible with HxW to allow the match and size of mame display to both work right.

Yes, we would need to get a list of needed modes parsing Mame.xml and ignoring vfreq value, then add a list of other emulators we want to have (that's the idea behind this ReslList.txt file I use), and see if we can keep it lower than our top number of modes. We would need some kind of normalizing of values in order to get a shorter list, probably starting with yres. This is not a problem with Mame but some emulators insist to do a dirty stretching when you give them a resolution with extra lines, so we should be able to preserve the original resolution in some cases to avoid that.

If only it worked like in Linux and actually looked at the active parts, seems like this modeline thing and the label for them just has allowed for software to not be consistent since some look at labels, some at actual real active line information.  I now almost think the idea of having labels for modelines was a bad idea, should have always just been the raw modeline only and have that speak for itself.  It just gets way too messy all the combinations of modeline name/label formats and then how different parts of each system parses that or doesn't look at that or does look at it on some levels but not others.

It's seems this is the way that driver developers have figured out to introduce modeline support in Windows. Unfortunately they decided that no one would ever need more than 60 custom video modes.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 02, 2010, 05:56:18 pm
That sourceforge thing looks really cool! I didn't know that could be done. Using soft15KHz for this is a good thing as it will open this to more video cards. However I don't know if other cards (non Ati) will allow dynamic modelines.

BTW I've seen you using "dvi" commands somewhere with your grub line, could that make any difference in my case?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 02, 2010, 06:01:13 pm
That sourceforge thing looks really cool! I didn't know that could be done. Using soft15KHz for this is a good thing as it will open this to more video cards. However I don't know if other cards (non Ati) will allow dynamic modelines.

BTW I've seen you using "dvi" commands somewhere with your grub line, could that make any difference in my case?
No since that just specifies to only do that mode on one single interface, and without it the output is on all interfaces (which I don't have any specified on the liveCD, so it will output the same to all interfaces).  There are checks though that say if an EDID is found it'll use those modes, so should allow combinations of arcade monitors and normal ones together.  So it basically should be the same as it was for the other monitor, although you could try either output of the video card since there's no restrictions on which you use, whatever is plugged in will get the output and be the default if there's only one even if it's the second (unlike how Windows works I guess).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 02, 2010, 06:08:15 pm
That sourceforge thing looks really cool! I didn't know that could be done. Using soft15KHz for this is a good thing as it will open this to more video cards. However I don't know if other cards (non Ati) will allow dynamic modelines.

I wonder why that enum active function call reloads them if there's over a certain number, and if it does that for all drivers possibly or not.  Do the other drivers use different registry keys and methods for storing extra custom modelines?  Well at least it'll all work for ATI and other cards at least can manually load up Soft15khz with anything extra and reboot as they do now.  Under Linux it's questionable if other cards besides ATI ones will work well right now and allow both modeswitching with xrandr and vsync with OpenGL.  Seems like ATI is the current opening that mostly is ready, but every other video card driver is being worked on just about to use KMS and the OpenGL vsync stuff.  So it's all very promising in the future, I suspect the Nvidia cards are going to work well pretty soon, they might work now with the current build even, I have support for them but don't know if it works or not.  OpenGL doesn't like to play with Intel cards, have to use software video for that it seems for some reason (may be that I compile openGL and libdri on a system with a Radeon and it knows, need to look into that more).  It may just be the maturity of  OpenGL and DRM/KMS is not ready for Intel cards, it should be though for Nvidia Nouveau DRM/KMS though, just needs testing and maybe I need to tweak the dotclock limits lower for those too in the kernel patch eventually (but would be interesting to see if it just can modeswitch and vsync right now). 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 02, 2010, 06:19:38 pm
I wonder why that enum active function call reloads them if there's over a certain number, and if it does that for all drivers possibly or not.  Do the other drivers use different registry keys and methods for storing extra custom modelines?

I also wonder why, it might even not be supposed to do so. I have the feeling all the time that this is an unexpected property that might suddendly vanish on us. I'm almost sure it won't work with other drivers. Unfortunately each driver uses it's own format for modelines, so this one is only for Catalyst (the newer ones), so it's a good idea to have Soft-15Khz deal with that.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 02:31:06 am
BTW I've finally tested HD4350 with my Cat 9.3 patched drivers, and it works flawlessly it seems. I have to connect it using the dvi with a dvi-vga adapter, otherwise I get no video, as dvi is defined as primary device in these cards. The number of total video modes is way lower than the number I was using with 6.5, so I don't get such good results with a static mode table as before. However, the aim is to get dynamic modelines with this, so it's not so important after all. Native bios modes have a slightly different frequency to the ones from previous Radeon, so even if jpac allows me to have a readable split screen during system boot, the picture is badly distorted. So I will try to have these new patched drivers ready to download for this weekend.

I have also tested your livecd in my 2 cabs:

- With ArcadeVGA 9250, I can see the boot with a perfect progressive mode (AVGA Bios), then select CGA monitor, video mode switches to what seems 640x480 31 KHz (problem I believe), split screen but still can see the system prompting stuff, then we reach the part were I select monitor, mount drive, etc. and start X-Windows, with a perfect 640x480 interlaced mode, and I think it's 32 bits color as the icons look good, although I am not sure (if it was 4 bits it would mean it's a bios mode, bad). Unfortunately, I didn't have a mouse to use around the cab in that house, so I couldn't get to click to Wahcade and try anything, but it seemed to work.

- With HD4350, unfortunately I get no video right before the part where we're asked to select monitor, mount drives and stuff, so I can't see those menus, I know the system is not locked as I still hear the cd when I choose random options from my keyboard (no picture) but haven't managed to make it load X-Windows. The boot is also difficult to see as I have that distorted picture I mentioned before, but that's not the problem. I've tried to choose from the different modes for the console at the firt menu, but nothing changes. I've also tried to start the cab either with the monitor plugged to the vga or the dvi outs, without success. I suspect of the damned EDID issue.

On the other hand, I've seen the menus and stuff and I find it clean and nice to work with, hopefully we will be able to solve those problems.


Is it a different monitor for each, is it possible the 640x480 modeline works on one but not the other?  I'm thinking of recreating that modeline, here's what it is right now...
Code: [Select]
+static struct drm_display_mode drm_cga_modes[] = {
+       /* 640x480@60.000 */
+       { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 13004, 640, 664,
+                  728, 832, 0, 480, 482, 488, 521, 0,
+                  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
+                       DRM_MODE_FLAG_INTERLACE) },
+       /* 800x600@49.06 */
+       { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 16353, 800, 832,
+                  912, 1040, 0, 600, 602, 608, 641, 0,
+                  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
+                       DRM_MODE_FLAG_INTERLACE) },
+       /* 1024@768@40.54 */
+       { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 21806, 1024, 1072,
+                  1176, 1320, 0, 768, 774, 780, 815, 0,
+                  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
+                       DRM_MODE_FLAG_INTERLACE) },
+};


Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 03, 2010, 03:47:22 am
Is it a different monitor for each, is it possible the 640x480 modeline works on one but not the other?  I'm thinking of recreating that modeline, here's what it is right now...

No, it's the exact same Hantarex MTC 9110, until last week both cabs had an AVGA 9250 in them, now one has the HD4350, so it's a good way to test both generations of cards. I know that the modeline is not being used at all (at least outside X Windows) cause I have a split screen, which means that it's a 31 KHz signal being filtered by the jpac board, and I'm seeing the same thing with both cabs, I can barely read the texts thanks to jpac. If the modeline was being used but somewhat out of the monitor range I would be easy to know, but that's not the case... well, just a moment: I need to check if interlace is being activated despite the split screen with my former cab: that would mean your modeline is partially considered but its hfreq is ignored...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 07:58:43 am
Is it a different monitor for each, is it possible the 640x480 modeline works on one but not the other?  I'm thinking of recreating that modeline, here's what it is right now...

No, it's the exact same Hantarex MTC 9110, until last week both cabs had an AVGA 9250 in them, now one has the HD4350, so it's a good way to test both generations of cards. I know that the modeline is not being used at all (at least outside X Windows) cause I have a split screen, which means that it's a 31 KHz signal being filtered by the jpac board, and I'm seeing the same thing with both cabs, I can barely read the texts thanks to jpac. If the modeline was being used but somewhat out of the monitor range I would be easy to know, but that's not the case... well, just a moment: I need to check if interlace is being activated despite the split screen with my former cab: that would mean your modeline is partially considered but its hfreq is ignored...
Oh, it's split screen all the way till you start X Windows?  It should be split up to a point of the boot messages, until it gets to the udev startup stuff, but past that is when the DRM modeline *should* kick in.  Odd if it isn't, guess it could be ignoring the interlacing but not sure why it'd do that.  Seeing the output of `dmesg` command and /the /var/log/dmesg file contents might help though, since the drm stuff is pretty verbose right now in the kernel messages so it very likely would tell me more.  I am thinking of making another build that perhaps only will output something like 320x240 at 15Khz to not need interlacing and hardwire it for the most part to that, maybe also enable some more debug messages for the dmesg output too. 

Could it be that the bootup part to the point of switching into DRM mode throws the monitor into an odd state somehow, since up to that point in boot up it's definitely some vesa based bios mode that grub uses to get things going.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 09:33:20 am
Is it a different monitor for each, is it possible the 640x480 modeline works on one but not the other?  I'm thinking of recreating that modeline, here's what it is right now...

No, it's the exact same Hantarex MTC 9110, until last week both cabs had an AVGA 9250 in them, now one has the HD4350, so it's a good way to test both generations of cards. I know that the modeline is not being used at all (at least outside X Windows) cause I have a split screen, which means that it's a 31 KHz signal being filtered by the jpac board, and I'm seeing the same thing with both cabs, I can barely read the texts thanks to jpac. If the modeline was being used but somewhat out of the monitor range I would be easy to know, but that's not the case... well, just a moment: I need to check if interlace is being activated despite the split screen with my former cab: that would mean your modeline is partially considered but its hfreq is ignored...

I am going to try and use a hopefully better strategy to how the kernel/X Windows stuff works.  It sounds like I should probably have 2 boot modes, just CGA or VGA and use 320x240 for CGA or 640x480 for VGA (possibly a 3rd SVGA where I don't pass any extra command arg to the kernel).  With that, I am thinking of a way to improve how the whole EDID check works in the kernel to make sure it's not somehow altering the choice of CGA or VGA mode.  I'm not sure what it's doing, but if interlace isn't working for certain cards it's one thing or if possibly the DRM stuff is not working for certain ones that is another, or if it's somehow being tricked into thinking there is an EDID for certain cards somehow.  Also I'm going to update to 2.6.37-rc4 because there is some interesting changes they made that have to do with interlacing in the last week...

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c49948f4bd39e27dd06a1cdb0c3743ca2a734f5e;hp=0ec80d645661dda50acd417bdfcb33df2e5dd31e (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c49948f4bd39e27dd06a1cdb0c3743ca2a734f5e;hp=0ec80d645661dda50acd417bdfcb33df2e5dd31e)

So that's suspicious, but also it's interesting that one of your cards works in the framebuffer mode and other doesn't?  Or do they both do the same thing?  Since that change in the kernel seems like it might indicate something like what your seeing could occur depending on the type of outputs on the cards since they all vary in combinations of HDMI/VGA/DVI or whatever others there might be or subtypes of those I guess.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 03, 2010, 12:05:38 pm
I've taken some pictures of the boot, these is the cab with the ArcadeVGA 9250, right before mode switching:

1.- (using AVGA BIOS mode)
(http://img256.imageshack.us/img256/1880/03122010215.th.jpg) (http://img256.imageshack.us/i/03122010215.jpg/)

... and this is right after mode switching, sorry for the bad quality:

2.-
(http://img337.imageshack.us/img337/5127/03122010216.th.jpg) (http://img337.imageshack.us/i/03122010216.jpg/)

The one with HD4350, has split screen at point 1, and no video at all at point 2. It's connected via DVI-VGA (the 9250 is connected via VGA only). What makes me suspect of the EDID thing is that it seems this 4350 is really turning video off, no signal at all, it's not out of sync or anything. I'll try again with this one this evening, probably will plug the network cable to see if I can do ssh (no idea of what I should type however, I'll read the latests posts as it's probably been explained already).

Today I brought a mouse with me to test the first cab (9250) and finally was able to get into Wahcade. Video looks really nice inside X Windows. However, when I select a game, I expected some error message not finding the roms, but what happens is that X Windows exits to the console with an error message. By the way, during setup I mount /dev/sda1 as the roms drive but I can't figure out how to teach it to just point to C:\Roms\Mame.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 12:29:21 pm
I've taken some pictures of the boot, these is the cab with the ArcadeVGA 9250, right before mode switching:

1.- (using AVGA BIOS mode)
(http://img256.imageshack.us/img256/1880/03122010215.th.jpg) (http://img256.imageshack.us/i/03122010215.jpg/)

... and this is right after mode switching, sorry for the bad quality:

2.-
(http://img337.imageshack.us/img337/5127/03122010216.th.jpg) (http://img337.imageshack.us/i/03122010216.jpg/)

The one with HD4350, has split screen at point 1, and no video at all at point 2. It's connected via DVI-VGA (the 9250 is connected via VGA only). What makes me suspect of the EDID thing is that it seems this 4350 is really turning video off, no signal at all, it's not out of sync or anything. I'll try again with this one this evening, probably will plug the network cable to see if I can do ssh (no idea of what I should type however, I'll read the latests posts as it's probably been explained already).

Today I brought a mouse with me to test the first cab (9250) and finally was able to get into Wahcade. Video looks really nice inside X Windows. However, when I select a game, I expected some error message not finding the roms, but what happens is that X Windows exits to the console with an error message. By the way, during setup I mount /dev/sda1 as the roms drive but I can't figure out how to teach it to just point to C:\Roms\Mame.



I think this sequence will allow you to access it with ssh possibly and start X Windows to look at the 4350 remotely...

1. boot up (give it a while)
2. push enter
3. type eth0
4. push enter
5. At this point should be able to ssh into box, password for root is 'arcade'
6. push enter
7. push enter
8. type h9110
9. type 1
10 push enter

you will want to look at possibly the output of the 'dmesg' command when your ssh'd into it (ssh root@IPADDRESS to access it, password above).  That's one issue but the other is concerning too with the video off center horizontally like that.  Is it possibly a bad modeline, it should be this...

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

Although in theory it's the same as in X Windows so if that works then somehow the DRM layer is messing with the console video for the frame buffer I'm guessing.  Possibly I need to use 320x240 I guess because it avoids interlace and maybe the frame buffer just isn't great at interlaced modelines, hopefully 320x240 is safe.  Is there any better modeline resolution you think would be a good console one without any interlacing?

on the 9200 box, you can when in the console after it crashes, check /var/log/Xorg.0.log by running (less /var/log/Xorg.0.log) first of course choosing the menu option for the command prompt, and possibly see what is going on there.  If you have network access possibly sending me that file, transfering it to another system with (ssh -rC /var/log/Xorg.0.log user@system:) first. 

The rom directory probably doesn't have to be mounted/mapped for now to test because I have the default free roms from mamedev there right now to test with, but if you do map a drive it looks in the roms directory on that drive (so /data/roms/, where your drive is mapped to /data/).  I have a new layout file showing the layout in the GIT repository I just uploaded and also am starting to get support for configuring links to where ever the actual roms/artwork is and lnking it properly.  Here's the basic layout of /data/ right now that Wahcade looks at...


#
# Default directory layout for WahCade
#
## ROMS
/data/artwork_all
/data/samples
/data/roms
/data/biosroms
/data/Games/NES
/data/Games/SNES
/data/Games/Coleco
/data/Games/N64
/data/Games/C64
/data/Games/Atari2600
/data/Games/SegaGenesis
#
## Snap shots
/data/screen_shots/NES/snaps
/data/screen_shots/SNES/snaps
/data/screen_shots/Coleco/snaps
/data/screen_shots/N64/snaps
/data/screen_shots/C64/snaps
/data/screen_shots/Atari2600/snaps
/data/screen_shots/SegaGenesis/snaps
## Mame control/info files
/data/ctl
## Mame snapshots
/data/mrq
/data/cab
/data/fly
/data/cat
/data/pcb
/data/ttl
/data/prv
/data/ico


I do have the configuration menu able now to save all the information entered upon new boots and even auto find the home directory chosen after it's been setup, and since the config is saved there, then can read that and probably just boot into X Windows after 1 setup.  I really would like to try and get away from using the console for anything but when your in console mode at first it's the root administrator user so it can do all the configuration from there, then I startup X Windows as the arcade user so it's non-privileged after that point.  I might figure out a way to do it though so in X Windows the configuration can be done although that gets into the issue of needing to know the monitor type first :) Definitely some tricky stuff to figure out with all that, but I am seeing it definitely harder to support card/arcade monitor/TV/monitor combinations than I had thought at first, and hopefully having a more basic generic console mode for at least Arcade monitors (and need ones for TV's in NTSC/PAL too) will make it work for both your cards (seems like that linux kernel change for interlacing might be to blame so getting away from interlaced consoles would be nice).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 12:49:15 pm
I've taken some pictures of the boot, these is the cab with the ArcadeVGA 9250, right before mode switching:



Do these look like good modelines for the framebuffer?
Code: [Select]

# [CGA] switchres 320 240 60 --monitor h9110
#  320x240@60.00 15.6600Khz
        ModeLine          "320x240x60.00" 6.639840 320 336 368 424 240 242 245 261 -HSync -VSync

# [CGA] switchres 640 480 60 --monitor generic
#  640x480@60.00 15.7500Khz
        ModeLine          "640x480x60.00" 13.104000 640 664 728 832 480 484 490 525 -HSync -VSync interlace

# [NTSC] switchres 720 480 59.95 --monitor ntsc
#  720x480@59.95 15.7369Khz
        ModeLine          "720x480x59.95" 14.855610 720 752 824 944 480 484 490 525 -HSync -VSync interlace

# [PAL] switchres 768 576 50 --monitor pal
#  768x576@50.00 15.6250Khz
        ModeLine          "768x576x50.00" 15.625000 768 800 872 1000 576 582 588 625 -HSync -VSync interlace



When using the h9110 monitor type, it is slightly different but not sure if that would make a difference, I'm thinking though that the CGA without interlace in 320x240 mode might work though since avoids interlacing at least.  Seeing the dmesg though would be helpful to know how the DRM stuff is acting about the EDID, mine just spits out a bunch of stuff about an invalid EDID or empty one basically, all 0xFFFFFFFFF's basically.  
Code: [Select]

radeon 0000:01:00.0: DVI-I-1: EDID block 0 invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID
[drm:radeon_atom_dac_detect], Bios 0 scratch 2 00000001
[drm:radeon_atombios_connected_scratch_regs], CRT1 connected
[drm:radeon_atombios_connected_scratch_regs], DFP2 disconnected
[drm:drm_mode_getconnector], [CONNECTOR:17:?]
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:17:DVI-I-1]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................

[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................

[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................

[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................

radeon 0000:01:00.0: DVI-I-1: EDID block 0 invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID
[drm:radeon_atom_dac_detect], Bios 0 scratch 2 00000001
[drm:radeon_atombios_connected_scratch_regs], CRT1 connected
[drm:radeon_atombios_connected_scratch_regs], DFP2 disconnected
[drm:drm_mode_getconnector], [CONNECTOR:13:?]
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:13:VGA-1]
[drm:radeon_atom_dac_detect], Bios 0 scratch 2 00000010
[drm:radeon_atombios_connected_scratch_regs], CRT2 disconnected
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:13:VGA-1] disconnected
[drm:drm_mode_getconnector], [CONNECTOR:13:?]
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:13:VGA-1]
[drm:radeon_atom_dac_detect], Bios 0 scratch 2 00000010
[drm:radeon_atombios_connected_scratch_regs], CRT2 disconnected
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:13:VGA-1] disconnected
[drm:drm_mode_getconnector], [CONNECTOR:15:?]
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:15:HDMI Type A-1]
[drm:radeon_atombios_connected_scratch_regs], DFP1 disconnected
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:15:HDMI Type A-1] disconnected
[drm:drm_mode_getconnector], [CONNECTOR:15:?]
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:15:HDMI Type A-1]
[drm:radeon_atombios_connected_scratch_regs], DFP1 disconnected
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:15:HDMI Type A-1] disconnected





Update:

Ah just found a bug, where I transfered over the values for the h9110 wrong, did the same timing vertically as the cga definition, not sure if that is an issue...
Code: [Select]
diff --git a/build_iso.sh b/build_iso.sh
index 619b7cc..a72b14a 100755
--- a/build_iso.sh
+++ b/build_iso.sh
@@ -1,6 +1,6 @@
 #!/bin/bash

-export VERSION=1.01
+export VERSION=1.02rc1
 export LIVECD=`pwd`
 export DO32BIT=
 export TARGET=${LIVECD}/target
diff --git a/src/SwitchResC/monitor.c b/src/SwitchResC/monitor.c
index b6c6531..7ef3e8e 100644
--- a/src/SwitchResC/monitor.c
+++ b/src/SwitchResC/monitor.c
@@ -255,8 +255,8 @@ int SetMonitorMode(char *type, MonitorMode monitor[MAX_MODES]) {
                monitor[0].HsyncPulse  = 4.700;
                monitor[0].HbackPorch  = 8.000;
                monitor[0].VfrontPorch = 0.064;
-               monitor[0].VsyncPulse  = 0.192;
-               monitor[0].VbackPorch  = 1.024;
+               monitor[0].VsyncPulse  = 0.160;
+               monitor[0].VbackPorch  = 1.056;
                monitor[0].HsyncPolarity = 0;
                monitor[0].VsyncPolarity = 0;
                monitor[0].ActiveLinesLimit = 288;



Also I'm wondering if that's an issue, how the h9110 has a lower Hfreq range, not 15.725-15.750 like the generic cga monitor would have?   How does that work, I'm pretty sure the Soft15Khz modelines and ArcadeVGA ones all tune to 15.750 but in the definition for it it's lower than that...




Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 03, 2010, 01:01:41 pm
Perfect, that's some stuff to start tests with.

That's one issue but the other is concerning too with the video off center horizontally like that.  Is it possibly a bad modeline, it should be this...

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

I'm almost sure those modelines are just ok, as the CGA ones you've posted, they should work fine with Hantarex. But it's not that: if you see the second picture it's not that it's off center, its duplicated, split screen as I'm using jpac, so it's a 31 KHz signal, so possibilities are DRM is reading 640x480 but using it's own timings.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 01:18:04 pm
Perfect, that's some stuff to start tests with.

That's one issue but the other is concerning too with the video off center horizontally like that.  Is it possibly a bad modeline, it should be this...

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

I'm almost sure those modelines are just ok, as the CGA ones you've posted, they should work fine with Hantarex. But it's not that: if you see the second picture it's not that it's off center, its duplicated, split screen as I'm using jpac, so it's a 31 KHz signal, so possibilities are DRM is reading 640x480 but using it's own timings.



Interesting, I am kind of suspecting this may be the AVGA bios issue because come to think of it that's what mine does actually.  That's the part I said about how it'll have really wild values for the refresh rate, like the programming of it in the DRM layer just doesn't do it right at all and it's just way off in setting the mode.  So for the AVGA card, that might be what's going on, similar to what mine does how it boots like it should with the AVGA bios but then when DRM kicks in it's all weird (since I have a d9800 I guess it doesn't double screen, it's just an odd odd mode setting with way high refresh rate and wrong horizontal freq). 

With the other card, split screen makes sense on boot, till the DRM layer, then it's breaking and maybe the DRM layer is crashing completely which is one possibility.  I'm not sure why that would occur, but it seems like the behavior that happens, possibly trying a normal monitor and seeing if it works on there and get some dmesg output.  I suspect it'd break on either one, Arcade or computer monitor, and might be some bug in the linux kernel ATOM bios code.

So sounds like probably the modelines are ok, I'm going to change them though or add these new ones I think and maybe make 320x240 default since we don't need a big console for the menu for now (and I'm hopefully going to move that into X Windows I think, at least seems like it's possible to just check and use the same modeline we booted with at the menu prompt and a 640x480 interlaced default should in theory work for everyone except TV users and I'd check for that). 

Does X fix the console though, to look normal, that would be something somewhat hopeful seeing that it's just the DRM layer not getting the ATOM bios programmed right for the frame buffer (although it's odd since it in theory is programming the X Windows modelines too), and on the other card the 4850 maybe if X started up on boot perhaps that'd also fix it if the DRM layer isn't breaking. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 03, 2010, 01:27:27 pm
Ah just found a bug, where I transfered over the values for the h9110 wrong, did the same timing vertically as the cga definition, not sure if that is an issue...

That wouldn't be really important but for 256 lines modes and such, where you might start loosing lines at the top of the screen, this is a different issue, believe me.

Also I'm wondering if that's an issue, how the h9110 has a lower Hfreq range, not 15.725-15.750 like the generic cga monitor would have?   How does that work, I'm pretty sure the Soft15Khz modelines and ArcadeVGA ones all tune to 15.750 but in the definition for it it's lower than that...

H9110 has a range that covers 1 KHz (a bit more), so CGA range is included inside H9110 range. You can move that 1 KHz range up and down a little bit using a potenciometer, so if I set it so it can synchronize at 16.7 KHz (256 lines@60 Hz), then the lowest frequency it will admit is more or less 15.62 KHz. I can adjust the potenciometer down so I can use frequencies like 15.5 KHz, but then it will only admit 16.5 Khz or so on the upper side.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 03, 2010, 01:35:34 pm
So sounds like probably the modelines are ok, I'm going to change them though or add these new ones I think and maybe make 320x240 default since we don't need a big console for the menu for now (and I'm hopefully going to move that into X Windows I think, at least seems like it's possible to just check and use the same modeline we booted with at the menu prompt and a 640x480 interlaced default should in theory work for everyone except TV users and I'd check for that).

640x480i is perfect for TV users also, no problem with that. 

Does X fix the console though, to look normal, that would be something somewhat hopeful seeing that it's just the DRM layer not getting the ATOM bios programmed right for the frame buffer (although it's odd since it in theory is programming the X Windows modelines too), and on the other card the 4850 maybe if X started up on boot perhaps that'd also fix it if the DRM layer isn't breaking. 

I believe DRM is not crashing with HD4350 as even with no video I was typing random stuff through your menus and could hear the cd spinning and stopping when doing that. It's just turning the video off, as when I boot in Windows with the cable connected to the vga output.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 01:43:33 pm
So sounds like probably the modelines are ok, I'm going to change them though or add these new ones I think and maybe make 320x240 default since we don't need a big console for the menu for now (and I'm hopefully going to move that into X Windows I think, at least seems like it's possible to just check and use the same modeline we booted with at the menu prompt and a 640x480 interlaced default should in theory work for everyone except TV users and I'd check for that).

640x480i is perfect for TV users also, no problem with that. 

Does X fix the console though, to look normal, that would be something somewhat hopeful seeing that it's just the DRM layer not getting the ATOM bios programmed right for the frame buffer (although it's odd since it in theory is programming the X Windows modelines too), and on the other card the 4850 maybe if X started up on boot perhaps that'd also fix it if the DRM layer isn't breaking. 

I believe DRM is not crashing with HD4350 as even with no video I was typing random stuff through your menus and could hear the cd spinning and stopping when doing that. It's just turning the video off, as when I boot in Windows with the cable connected to the vga output.

Ah cool, that's good to know it's not crashing at least, so can get dmesg output's and those should partly help clear it up I think.  Next version of the .iso will have more debug information output about DRM for dmesg to show, so that might even be better but it should probably say something interesting in the logs/dmesg still.  I need to enable the first ethernet interface I guess by default to make it easier to get into the system remotely in situations like this, that blind menu thing is definitely a pain, and of course maybe it's fixed in the newer linux kernel since I do see they yet again have done more changes to the atom bios stuff.  I'll hopefully have new .iso images by later tonight that may help make it easier to diagnose the issue, and probably will boot straight into X Windows if I find that easy to implement quickly.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 01:56:50 pm
I have a theory about the AVGA card, what it's doing.  Seems it always doubles the Hfreq when trying to actually program the thing through the ATOM bios with the DRM layer.  Would the hacks to make the BIOS do all the modelines in Windows and the bootup BIOS at 15Khz be possibly some kind of thing where he's taking the values given and doing some calculations with them, like it seems to be twice as much and when given this 640x480 15khz mode it's like you see and when I gave it the 640x480 31.5 Khz mode I think it was again way higher than that plus was oddly blurry too.  If we only could figure out the actual calculations to feed the card to get the actual output we want, I get the feeling it's some kind of algorithm, I guess it'd be in the clock stuff in the DRM part of the kernel where it'd need different programming values.  It worked in the old X Windows somewhat probably because it didn't really work with the ATOM bios there ever, now it does, and seems those clocks are needing to have different program methods than the normal ATI bios ones.  I would guess the Windows drivers might be able to listen to the bios better and know what it wants, while the Linux stuff probably isn't that mature to know what the bios wants and a lot of hardcoding of values seem to still be in the linux kernel drm stuff for the radeon. 

Again this might explain the other card too, I know that the x850 card I have doesn't show the console either, but when I start X Windows it does.  So that gives some hope for getting X Windows to startup automatically, might solve the problem.  Interesting that your card shows this issue too, I thought that was just the x850 being an oddball and having that strange cable requirement for the crossfire stuff plus having only one actual output since the others a proprietary cable connector.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 03, 2010, 02:12:53 pm
I have a theory about the AVGA card, what it's doing.  Seems it always doubles the Hfreq when trying to actually program the thing through the ATOM bios with the DRM layer.  Would the hacks to make the BIOS do all the modelines in Windows and the bootup BIOS at 15Khz be possibly some kind of thing where he's taking the values given and doing some calculations with them, like it seems to be twice as much and when given this 640x480 15khz mode it's like you see and when I gave it the 640x480 31.5 Khz mode I think it was again way higher than that plus was oddly blurry too.  If we only could figure out the actual calculations to feed the card to get the actual output we want, I get the feeling it's some kind of algorithm, I guess it'd be in the clock stuff in the DRM part of the kernel where it'd need different programming values.  It worked in the old X Windows somewhat probably because it didn't really work with the ATOM bios there ever, now it does, and seems those clocks are needing to have different program methods than the normal ATI bios ones.  I would guess the Windows drivers might be able to listen to the bios better and know what it wants, while the Linux stuff probably isn't that mature to know what the bios wants and a lot of hardcoding of values seem to still be in the linux kernel drm stuff for the radeon.

I hadn't thought much about that, but are those consoles using by chance text modes? Text modes have a different nature than graphic modes. All the modeline stuff we've been discussing here is valid for graphic modes. However, text modes might follow a different path within the drivers. Windows drivers are only capable of graphic modes, as far as I know. AVGA Bios (at least the older one) is ignored when the Windows drivers take control, so there's no need for them to care about its patches. But the BIOS text modes are indeed invoked when we set a DOS text console to full screen.

Again this might explain the other card too, I know that the x850 card I have doesn't show the console either, but when I start X Windows it does.  So that gives some hope for getting X Windows to startup automatically, might solve the problem.  Interesting that your card shows this issue too, I thought that was just the x850 being an oddball and having that strange cable requirement for the crossfire stuff plus having only one actual output since the others a proprietary cable connector.

That sounds possible in fact.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 02:24:35 pm
I have a theory about the AVGA card, what it's doing.  Seems it always doubles the Hfreq when trying to actually program the thing through the ATOM bios with the DRM layer.  Would the hacks to make the BIOS do all the modelines in Windows and the bootup BIOS at 15Khz be possibly some kind of thing where he's taking the values given and doing some calculations with them, like it seems to be twice as much and when given this 640x480 15khz mode it's like you see and when I gave it the 640x480 31.5 Khz mode I think it was again way higher than that plus was oddly blurry too.  If we only could figure out the actual calculations to feed the card to get the actual output we want, I get the feeling it's some kind of algorithm, I guess it'd be in the clock stuff in the DRM part of the kernel where it'd need different programming values.  It worked in the old X Windows somewhat probably because it didn't really work with the ATOM bios there ever, now it does, and seems those clocks are needing to have different program methods than the normal ATI bios ones.  I would guess the Windows drivers might be able to listen to the bios better and know what it wants, while the Linux stuff probably isn't that mature to know what the bios wants and a lot of hardcoding of values seem to still be in the linux kernel drm stuff for the radeon.

I hadn't thought much about that, but are those consoles using by chance text modes? Text modes have a different nature than graphic modes. All the modeline stuff we've been discussing here is valid for graphic modes. However, text modes might follow a different path within the drivers. Windows drivers are only capable of graphic modes, as far as I know. AVGA Bios (at least the older one) is ignored when the Windows drivers take control, so there's no need for them to care about its patches. But the BIOS text modes are indeed invoked when we set a DOS text console to full screen.

Again this might explain the other card too, I know that the x850 card I have doesn't show the console either, but when I start X Windows it does.  So that gives some hope for getting X Windows to startup automatically, might solve the problem.  Interesting that your card shows this issue too, I thought that was just the x850 being an oddball and having that strange cable requirement for the crossfire stuff plus having only one actual output since the others a proprietary cable connector.

That sounds possible in fact.


The older Linux console uses text mode, 80x24 or something like that.  I think grub actually is either doing that or it's using a VESA BIOS mode number, newer grub versions like in ubuntu do the gfx or graphics boot I guess but I think this older on in gentoo does text mode till it hits the DRM layer. 

So an NTSC TV and PAL one, don't they require a different version of the 640x480@60i modeline or would that supposidly work on everything?  Since booting into X Windows would be much simpler if that were true, else I have to figure out which type of monitor is in use to get the Xorg modeline setup.  Then at the grub prompt it'd have to choose by which one is picked there, which really all I have to go by is what resolution is chosen so it'd have to be a different one per monitor type in hxw.  Then if they can't see that grub prompt, although I suspect all TV users would? but maybe not, well then if not seen there's a problem there since it'll default to CGA mode in grub since for an arcade monitor that'll make it work mostly.  If there was one single modeline that worked on everything, that would be nice, since I can't see how to know what monitor they are using other than guessing it's an arcade one and the TV then might not be able to get chosen interactively. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 03, 2010, 02:48:11 pm
I'd bet that 640x480@60i modeline should work on any tv, either ntsc or pal. It might happen that some old pal tvs might only sync at 50Hz but we shouldn't care about that now, think that AVGA only has that 640x480 mode and is supposed to work with any tv.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 02:56:07 pm
I'd bet that 640x480@60i modeline should work on any tv, either ntsc or pal. It might happen that some old pal tvs might only sync at 50Hz but we shouldn't care about that now, think that AVGA only has that 640x480 mode and is supposed to work with any tv.


Should all arcade monitors/TV's work with text mode of 80x25?  Is that something to try and get at the grub prompt, seems it probably is going into a VESA mode at the prompt and sounds like there might be a way to get it to use text mode.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 03, 2010, 03:27:04 pm
Don't think so, BIOS text modes are usually high resolution modes unless you use a real CGA text mode with 8x8 pixels size characters (640x200), but even then the BIOS would activate doublescan in order to achieve a VGA compatible frequency I believe, so you may need low level patching (I suppose that's what AVGA does). You have to deal with characters height in order to program a text mode, graphic mode's characters are 1 pixel high.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 03:40:35 pm
Don't think so, BIOS text modes are usually high resolution modes unless you use a real CGA text mode with 8x8 pixels size characters (640x200), but even then the BIOS would activate doublescan in order to achieve a VGA compatible frequency I believe, so you may need low level patching (I suppose that's what AVGA does). You have to deal with characters height in order to program a text mode, graphic mode's characters are 1 pixel high.
So I guess the best approach is to use the 640x480 interlaced modeline, boot up into the framebuffer and then start X Windows using that same modeline too.  From there present the setup menu in an xterm, then launch the window manager.  Sounds like I can use that 640x480 interlaced resolution then, and if the user picks another monitor possibly tune xorg.conf to use that type instead and optimize the modeline perhaps.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 03, 2010, 04:28:27 pm
Sure, that would make a rather universal stuff for lowres/multisync crts, and then on a second boot you could have it set up for other monitors. BTW, where's that configuration data supposed to be stored if I have a single NTFS partition in my hd? Will it create its own directory somewhere won't it?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 04:40:01 pm
Sure, that would make a rather universal stuff for lowres/multisync crts, and then on a second boot you could have it set up for other monitors. BTW, where's that configuration data supposed to be stored if I have a single NTFS partition in my hd? Will it create its own directory somewhere won't it?
Well in Linux the NTFS file system isn't writable, it's read only because of dangers writing to NTFS from another operating system other than Windows.  So it'd not be able to do it, normally if a partition is chosen to mount to home I'm (in this newest version not up yet) using a .gentooarcade/config file and store config files in that directory.  The drive/partition could be a usb stick or drive, anything, but needs to be a Linux one like ext4 fs right now to allow writing to it.  I still need to make an option in the menu to actually partition and format if wanting to use an unsetup drive without a partition or the partition not being ext4 fs yet.  It can be a very tiny partition of course, just really will hold text based config files, while the ROMS partition could be NTFS or anything that Linux supports for read access.  A 50 megabyte partition would be more than enough for it for example, but of course the whole user interface isn't there yet to setup such a thing unless you know about using fdisk and running the ext2fs tools on the command line.

I think I have the kernel patch improved a bit to actually be a bit more arcade monitor friendly in how it acts without an EDID, so it'll do the arcade resolutions if no EDID exists no matter what.  In theory it negates the need for the kernel command line option and makes it easier to mix/match monitor types without having to tell the video= parameter what each one is.  Need to test it though and see, takes awhile to compile so I can start looking at getting X Windows to start automatically.  Should be able to have the menu config happen, then restart X automatically with the new modeline, and go on into the window manager.  Shouldn't need a reboot at all :).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 03, 2010, 11:11:18 pm
I'm uploading new .iso images now, should be a few hours before they are up there, will be livecd32_12-03-2010_1291434263.iso and livecd64_12-03-2010_1291434978.iso.  These should boot directly into X Windows and use the newest kernel, more statefull saving of configured information if there's a home directory.   Also the enable the ethernet interface by default when booted the first time and in configuration mode, so should be able to get into them easier if they don't work and see what the logs say.  There's definitely a few rough edges still but should be good hopefully to test the theory that X Windows may work while the DRM console doesn't. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 04, 2010, 09:18:56 am
I'm uploading new .iso images now, should be a few hours before they are up there, will be livecd32_12-03-2010_1291434263.iso and livecd64_12-03-2010_1291434978.iso.  These should boot directly into X Windows and use the newest kernel, more statefull saving of configured information if there's a home directory.   Also the enable the ethernet interface by default when booted the first time and in configuration mode, so should be able to get into them easier if they don't work and see what the logs say.  There's definitely a few rough edges still but should be good hopefully to test the theory that X Windows may work while the DRM console doesn't. 

Ah found a bug in the new one, well a couple :/.  Will let you know when I get them fixed, had restricted the xorg.conf hsync too tightly for the generic modeline used to setup, and the kernel changes seem to have totally allowed the frame buffer to be way too free with what modelines it used too.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 04, 2010, 12:05:35 pm
Sure, that would make a rather universal stuff for lowres/multisync crts, and then on a second boot you could have it set up for other monitors. BTW, where's that configuration data supposed to be stored if I have a single NTFS partition in my hd? Will it create its own directory somewhere won't it?

I've found something interesting, from the changes I made to the newer .iso which had problems it's led me to see a little more of how the DRM stuff works with the modelines.  I realized that the default modelines are all basically divided by 1000, so 6000 is 6Mhz actually.  Well looking through the code more I see that what they are doing is in the DRM layer having it all the value divided by 1000 so the precision of course is never better than that and when we have anything more precise it's probably being rounded/aligned to 1000 for the pixel clock.  I see they then multiply that value by 1000 again to grow it back to the right amount before directly feeding the hardware, so it's not like the hardware wants it like this and they do it generically for all drivers using the DRM layer. 

So is it worth it to go through and make this accept the Mhz correctly and not divided by 1000, how much is that going to be an issue in being exact?  I'm guessing this goes on from the top to bottom, from the X server possibly although I'm not sure if it's input is divided by 1000 when hitting the DRM layer, and then throughout the DRM layer and into each individual DRM driver.  So it'd all have to be overhauled, quite irritating they chose to be so rough with the calculations but then again I guess those CVT calculations always do similar stuff it seems and that seems to be all they have really counted on getting else an EDID modeline from the display.

I do think the way I'm doing the setup should be good now, but I changed the kernel somewhat and it allowed the crazy modelines back in and didn't for some reason take my custom ones on the FB (which wouldn't have mattered now if the extra modelines didn't creep in).  I at least know what to fix and am fixing it, and it's showing me more insight into how the DRM stuff works too.  Hopefully have a good working ISO up here later today.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 04, 2010, 04:47:21 pm
I've tried your second liveCD in my HD4350 cab. I still can't get into X Windows, I just get stuck with the black screen. So I've returned to your first liveCD, to try to follow the sequence you posted. However I can't get into X Windows either, so I'm trying to access it by ssh at least. I have my HD4350 cab plugged to the router, I'm seeing it as 192.168.0.100 arcade in my laptop, but when I try to ssh it (OpenSSH) I'm getting this:

ssh root@192.168.0.100
ssh: connect to host 192.168.0.100 port 22: Connection refused

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 04, 2010, 04:56:39 pm
Sure, that would make a rather universal stuff for lowres/multisync crts, and then on a second boot you could have it set up for other monitors. BTW, where's that configuration data supposed to be stored if I have a single NTFS partition in my hd? Will it create its own directory somewhere won't it?

I've found something interesting, from the changes I made to the newer .iso which had problems it's led me to see a little more of how the DRM stuff works with the modelines.  I realized that the default modelines are all basically divided by 1000, so 6000 is 6Mhz actually.  Well looking through the code more I see that what they are doing is in the DRM layer having it all the value divided by 1000 so the precision of course is never better than that and when we have anything more precise it's probably being rounded/aligned to 1000 for the pixel clock.  I see they then multiply that value by 1000 again to grow it back to the right amount before directly feeding the hardware, so it's not like the hardware wants it like this and they do it generically for all drivers using the DRM layer. 

So is it worth it to go through and make this accept the Mhz correctly and not divided by 1000, how much is that going to be an issue in being exact?  I'm guessing this goes on from the top to bottom, from the X server possibly although I'm not sure if it's input is divided by 1000 when hitting the DRM layer, and then throughout the DRM layer and into each individual DRM driver.  So it'd all have to be overhauled, quite irritating they chose to be so rough with the calculations but then again I guess those CVT calculations always do similar stuff it seems and that seems to be all they have really counted on getting else an EDID modeline from the display.

I do think the way I'm doing the setup should be good now, but I changed the kernel somewhat and it allowed the crazy modelines back in and didn't for some reason take my custom ones on the FB (which wouldn't have mattered now if the extra modelines didn't creep in).  I at least know what to fix and am fixing it, and it's showing me more insight into how the DRM stuff works too.  Hopefully have a good working ISO up here later today.

Interesting... but which of the values are being divided by 1000, dotclocks only or the other stuff too??? This is similar of what happens in Windows, where if you need to have, say 6.596345 MHz for the dotclock, then the most accurate you can be is the integer 659 figure, are you able to be more accurate there?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 04, 2010, 05:03:07 pm
I've tried your second liveCD in my HD4350 cab. I still can't get into X Windows, I just get stuck with the black screen. So I've returned to your first liveCD, to try to follow the sequence you posted. However I can't get into X Windows either, so I'm trying to access it by ssh at least. I have my HD4350 cab plugged to the router, I'm seeing it as 192.168.0.100 arcade in my laptop, but when I try to ssh it (OpenSSH) I'm getting this:

ssh root@192.168.0.100
ssh: connect to host 192.168.0.100 port 22: Connection refused



Yeah the second was a flop it turns out but helped me figure some things out.  I've got another about to upload as  soon as the ISO images are done, this one looks pretty good at being able to boot directly into X to setup, then it restarts with the new settings and on future reboots if there was a home directory used it'll boot straight into X windows with the pre-configured setup.   It'll be a good test at least, should be able to get your system into X Windows whether or not the frame buffer works, and see what happens then.  Now basically the frame buffer isn't ever really used, so doesn't matter if it doesn't show up.  There's no real way to get into this one remotely before a setup is done, but hopefully we won't need to anyways.  Setting up remote access hopefully won't be necessary, I *think* once we get into X Windows we're safe, at least hopefully so.

I'll post again when it's uploaded, probably be a few hours at most.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 04, 2010, 05:16:00 pm
Sure, that would make a rather universal stuff for lowres/multisync crts, and then on a second boot you could have it set up for other monitors. BTW, where's that configuration data supposed to be stored if I have a single NTFS partition in my hd? Will it create its own directory somewhere won't it?

I've found something interesting, from the changes I made to the newer .iso which had problems it's led me to see a little more of how the DRM stuff works with the modelines.  I realized that the default modelines are all basically divided by 1000, so 6000 is 6Mhz actually.  Well looking through the code more I see that what they are doing is in the DRM layer having it all the value divided by 1000 so the precision of course is never better than that and when we have anything more precise it's probably being rounded/aligned to 1000 for the pixel clock.  I see they then multiply that value by 1000 again to grow it back to the right amount before directly feeding the hardware, so it's not like the hardware wants it like this and they do it generically for all drivers using the DRM layer. 

So is it worth it to go through and make this accept the Mhz correctly and not divided by 1000, how much is that going to be an issue in being exact?  I'm guessing this goes on from the top to bottom, from the X server possibly although I'm not sure if it's input is divided by 1000 when hitting the DRM layer, and then throughout the DRM layer and into each individual DRM driver.  So it'd all have to be overhauled, quite irritating they chose to be so rough with the calculations but then again I guess those CVT calculations always do similar stuff it seems and that seems to be all they have really counted on getting else an EDID modeline from the display.

I do think the way I'm doing the setup should be good now, but I changed the kernel somewhat and it allowed the crazy modelines back in and didn't for some reason take my custom ones on the FB (which wouldn't have mattered now if the extra modelines didn't creep in).  I at least know what to fix and am fixing it, and it's showing me more insight into how the DRM stuff works too.  Hopefully have a good working ISO up here later today.

Interesting... but which of the values are being divided by 1000, dotclocks only or the other stuff too??? This is similar of what happens in Windows, where if you need to have, say 6.596345 MHz for the dotclock, then the most accurate you can be is the integer 659 figure, are you able to be more accurate there?


Just the dotclock, and that value in Linux it seems to turn into 6596 * 1000, so it's a little more accurate but just not exact.  I emailed the Alex guy that does the DRM ATI stuff and hopefully he helps at least give some idea of the amount of work it is to change this, and if he'll at all help or if they care at all.  I definitely looks like a big job to go through the whole DRM layer and change this calculation, there's so much stuff there unfortunately that's very complex and hard to fully understand since it's been pulled probably from datasheets and not fully explained in the code or wanting people to understand it since it's from proprietary companies stuff/intellectual property just given out to let Linux work.  At least it's making me look closer at the clock and pll calculations, but they are definitely crazy and complex, and I just get the feeling it's like most chip stuff where the things they are doing aren't going to make much sense unless you saw the secret datasheets and then it's usually filled with workarounds for all the bugs in the asic they have to avoid, so not easy to go through and just alter values to what seems like it'd be correct and to change the divide by 1000 part I'm probably going to have to try and understand a lot of the obfuscated code. I guess it's working pretty well as it is, but I do see some oddness in the frame buffer modelines at least, I think this at least explains why it's just slightly off always and like 99.999% correct but missing that .1 percent, how pacman runs at 60.599 probably instead of 60.606... or something.  It does explain something though, when I had the code doing the checks for the vertical refresh I saw that aligning everything to 1000 seemed to somewhat work well, I do remember that was a good number.  The only thing was I didn't like how lines were added to do so and then it always seemed like it took longer and I don't know if my calculations were really as good as yours were.  I need to revisit that possibly, although the best solution of course is to go through the DRM code and make it use the exact dotclocks we give it, but I'm worried that'll end up needing to change xrandr and Xorg too, which hopefully the Alex guy can answer those questions and maybe give more information on why it's done.  I think it's just an age old way that the framebuffer always worked in Linux, they just used the reduced values from what I can tell, and seems no one thought to ever make it more precise.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 04, 2010, 07:11:48 pm
The 32bit version has uploaded to test.

Also here's the reply back from the Alex guy, seems like he's saying it doesn't matter?


                    The pixel clock is stored in khz units in the mode structs in the
                   |kernel and in X.  We expand it to hz in the pll divider calculations.
                   |Then it's reduced to 10 Khz units for the atom methods, but at this
                   |point it doesn't matter as the pll dividers have already been
                   |calculated, so I don't think it's an issue.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 05, 2010, 05:26:16 am
The 32bit version has uploaded to test.

Also here's the reply back from the Alex guy, seems like he's saying it doesn't matter?


                    The pixel clock is stored in khz units in the mode structs in the
                   |kernel and in X.  We expand it to hz in the pll divider calculations.
                   |Then it's reduced to 10 Khz units for the atom methods, but at this
                   |point it doesn't matter as the pll dividers have already been
                   |calculated, so I don't think it's an issue.


I don't understand what 'atom methods' would require dotclock values once the pll dividers have been worked out, however we could check if we can add the extra digits when it's expanded into hz, right before the pll divider is calculated, and see if it makes any difference.

I'll test the new version in a while.

UPDATE: I've tested new version of liveCD 32, with HD4350, unfortunately with same results (black screen), have tested also 320x240 init mode but makes no difference. I can't see the arcade machine in the network now either. I'm starting to think that it's related to the card, not for it being faulty as it's working well, but for some reason the video is turned off when it reaches that point (DRM?), maybe for not detecting any monitor or whatever else, but it's interesting that the same code was more or less working with old AVGA 9250 (I tested liveCD 32 version 1) and same monitor. So I definitely need to test this stuff with the HD4350 plugged to a pc monitor to check if I have video with it. Unfortunately I don't have one around at this place where the cab is but will try to get one here soon.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 06, 2010, 02:10:40 pm
The 32bit version has uploaded to test.

Also here's the reply back from the Alex guy, seems like he's saying it doesn't matter?


                    The pixel clock is stored in khz units in the mode structs in the
                   |kernel and in X.  We expand it to hz in the pll divider calculations.
                   |Then it's reduced to 10 Khz units for the atom methods, but at this
                   |point it doesn't matter as the pll dividers have already been
                   |calculated, so I don't think it's an issue.


I don't understand what 'atom methods' would require dotclock values once the pll dividers have been worked out, however we could check if we can add the extra digits when it's expanded into hz, right before the pll divider is calculated, and see if it makes any difference.

I'll test the new version in a while.

UPDATE: I've tested new version of liveCD 32, with HD4350, unfortunately with same results (black screen), have tested also 320x240 init mode but makes no difference. I can't see the arcade machine in the network now either. I'm starting to think that it's related to the card, not for it being faulty as it's working well, but for some reason the video is turned off when it reaches that point (DRM?), maybe for not detecting any monitor or whatever else, but it's interesting that the same code was more or less working with old AVGA 9250 (I tested liveCD 32 version 1) and same monitor. So I definitely need to test this stuff with the HD4350 plugged to a pc monitor to check if I have video with it. Unfortunately I don't have one around at this place where the cab is but will try to get one here soon.



Very odd that it isn't showing up even after X Windows starts, seems like the card is either only outputting video on one output or none of them after the DRM stuff kicks in.  Yeah I took out the network startup actually for now since it slows down startup without it connected and also forces the network interface on in the config, I need to think more of a better way to enable that for the first config.  It definitely would be good to see with a normal monitor what is going on, I am pretty sure what is happening has to do with the driver/card interaction and output video is possibly thinking the monitor isn't there, probably good otherwise if it'd only see the monitor connection.  It is interesting, the log will most likely show the issue and I'm guessing the monitor detection for the connectors is for some reason not saying anything is attached.  I'm working a newer .iso which I'll try to make sure there is  a network setup for the ethernet interface, to ssh into the box and grab /var/log/messages and /var/log/dmesg and output for the `dmesg` command. 

The next .iso I'm hopefully getting to do a few things, like have it ask you where the roms are, which you can now use one single home/data drive and it'll ask where each rom/snap directory is actually located and link it to the expected default location and do that on future boots.  Also looking into being able to install this onto the hard drive, I think it might not be that difficult so it'll be both a liveCD and installation CD too.  Need to make a menu option when unformatted drives are seen to actually partition and format them, so can really get the partitions setup from scratch.

There's something interesting too, the page flipping support for all Radeon cards is coming very soon, in 2.6.38 but is already in the GIT stuff and the Alex guy showed me the places to get that so I'll hopefully be able to build that in soon too...


  http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?h=kms-pflip&id=69639ef377a9d6701cdef902f8a1c5e0b58cf833 (http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?h=kms-pflip&id=69639ef377a9d6701cdef902f8a1c5e0b58cf833)


Is that monitor any different with the VGA connection than possibly the d9800?   It seems that what is going on, I suspect, is the DRM connector checking doesn't see it and turns it off.  We could in theory force it on, with xrandr possibly or at the linux boot prompt I can specify it to always be on too for DRM outputs.  Actually once I get a version up with ssh access enabled, you can do this from another system and send me those files...

scp -rC root@arcadesystem:/var/log/messages messages
scp -rC root@arcadesystem:/var/log/dmesg dmesg
ssh root@arcadesystem (then when in type dmesg > dmesg.log)
scp -rC root@arcadesystem:/root/dmesg.log dmesg.log

Using `arcade` as the password.

Also the person using the PAL TV seemed to not be able to use the 640x480 default we had, but it does work with the PAL DRM modeline I put in there, so something interesting, I think I have it now setup where it'll go into X Windows to setup also using that same modeline if the PAL option is chosen at the boot prompt (odd that the boot prompt shows up, not sure why that is for sure).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 06, 2010, 04:18:14 pm
Quote
Is that monitor any different with the VGA connection than possibly the d9800?

My cab uses a jamma connector for the monitor + control panel, so I'm using a Jpac board to interface it with the vga connection.

Quote
It seems that what is going on, I suspect, is the DRM connector checking doesn't see it and turns it off.

Yes I think so too, it seems Jpac is not being noticed by DRM and it's turning the video off. It may be this issue:

http://forum.arcadecontrols.com/index.php?topic=66402.msg982901#msg982901 (http://forum.arcadecontrols.com/index.php?topic=66402.msg982901#msg982901)

Quote from: SailorSat
If you get a black screen after windows starts up with the J-PAC, try using the OTHER port on the Radeon. You may need a DVI-to-VGA dongle.
Modern cards "sense" monitors via the RGB-to-Ground resistors (usually 75 Ohms), but the J-PAC doesn't have these.
Soft-15kHz enforces detection of BOTH VGA ports and on newer cards, the primary is "in" the DVI port.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 06, 2010, 04:19:42 pm
I'll try it with a pc monitor as soon as I can. Good news also those new options for roms paths, possible installation and that. I'll be patient.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 06, 2010, 04:48:08 pm
I'll try it with a pc monitor as soon as I can. Good news also those new options for roms paths, possible installation and that. I'll be patient.

We can force all connectors to on with the option on the linux command line like this 'video=640x480ec' where the 'e' part tells it to force each video output to be on even if nothing is detected.  Hopefully this works, it makes some sense actually I think to just do that and so each interface that doesn't detect EDID will basically be ready for an arcade monitor to connect at any time even if not present at bootup.  I'll test that option some, looking like I should have something rather good in a day or less, am working on having a graphical partition manager to partition/format the drives if needed and the method of taking the liveCD and writing it out to a partition to permanently install it.  The install thing is probably not going to be fully ready but the improvements other than that hopefully should make things work with the jpac and your monitor.  So I suspect it's not seeing the arcade monitor just on the one card because of possibly the either the arcade VGA card having something done to the vbios different or your using either DVI on one and VGA on the other, possibly with an adaptor?

Hopefully this rom path thing is easy to understand and works right, basically it's logic is that there's a /home/arcade/ directory and you can say /data is just a link to that.  Then it'll ask you for every path's actual location, like /data/roms might be /home/arcade/Mame/ROMS for you so you type that when it asks and it'll link the /data/roms directory to /home/arcade/Mame/ROMS.  The /data directory though if using an NTFS partition for rom locations might have an issue I can see that it'll not be able to make links into /data/ so I think I need to have another actual directory to map the NTFS partition onto like /data1 instead and then link everything from /data1/Roms to /data/roms on the fly each bootup.  So it's half way thought out and operational but I can now see the NTFS case needs some work.  I did get it though were I should be able to startup the ethernet interface on install and not have it permanently enable it unless setup by command line.  This is definitely interesting figuring out all the issues with an installation, but hopefully will be bare bones enough to be specifically for mame and other emulators plus utilized the most newest Linux kernel features and X Windows ones too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 06, 2010, 05:26:35 pm
So I suspect it's not seeing the arcade monitor just on the one card because of possibly the either the arcade VGA card having something done to the vbios different or your using either DVI on one and VGA on the other, possibly with an adaptor?

My testing has been HD4350 through DVI (DVI-VGA adapter) and ArcadeVGA 9250 through VGA. It could also happen that this detecting feature is only implemented by DRM for the newer BIOS  ???
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 06, 2010, 05:53:48 pm
So I suspect it's not seeing the arcade monitor just on the one card because of possibly the either the arcade VGA card having something done to the vbios different or your using either DVI on one and VGA on the other, possibly with an adaptor?

My testing has been HD4350 through DVI (DVI-VGA adapter) and ArcadeVGA 9250 through VGA. It could also happen that this detecting feature is only implemented by DRM for the newer BIOS  ???


Hopefully it's either the ArcadeVGA has something different with the vbios tricking the card into saying a monitor is always connected, or  it is a difference in chips and how the DRM layer treats them.  At least will have this next version of the .iso have the network connection, if it doesn't work still then that'll be the way to really see what is going on with it.  Also of course having another monitor connected I'm guessing will be interesting and might tell just as much. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 06, 2010, 10:29:41 pm
In a few hours there's going to be new .iso images uploaded, named livecd32_12-06-2010_1291689634.iso and livecd64_12-06-2010_1291690462.iso, which have the 'always on' setting for the video outputs.  Also have gparted graphical partition/formatting and better setup for the /data/ drive making all the links and asking about locations of Roms.  I have a sort of experimental option in the menu, and should have all the stuff there to allow in theory installing to a partition and setup of it for a real installation.  That's not complete, there's probably some extra stuff needed, I need to work on that more  still to completely setup an installation that isn't a liveCD altered installation to a hard drive partition and get it to boot up properly.  Also this version will have the ssh access working when first started and in setup mode, so should be able to access it remotely if things are still not working right.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 07, 2010, 12:09:18 pm
Calamity:

Found an interesting thing about generating TV modelines or mainly ones with a single fixed Horizontal frequency.  This also duplicates LRMC behavior in generating the vtotal lines too...
Code: [Select]

diff --git a/src/SwitchResC/modeline.c b/src/SwitchResC/modeline.c
index 6e0a55a..485d24f 100644
--- a/src/SwitchResC/modeline.c
+++ b/src/SwitchResC/modeline.c
@@ -175,13 +175,16 @@ int ModelineCreate(ConfigSettings *cs, GameInfo *game, MonitorMode *monitor, Mod
        mode->vtotal = round(mode->hfreq / mode->vfreq);
        if (interlace == 2)
                mode->vtotal += 0.5;
-       while ((mode->vfreq * mode->vtotal) < monitor->HfreqMin) {
+       while ((mode->vfreq * mode->vtotal) < monitor->HfreqMin && (mode->vfreq * (mode->vtotal+1.0)) < monitor->HfreqMax) {
                if (monitor->cs->verbose > 1)
                        fprintf(stderr, "Increasing 1 line from horizontal freq %.3f to %.3f\n",
                                (mode->vfreq * mode->vtotal), (mode->vfreq * (mode->vtotal+1)));
-               mode->vtotal++;
+               mode->vtotal = mode->vtotal + 1.0;
        }

+       while (((mode->vfreq+0.001) * mode->vtotal) < monitor->HfreqMin)
+               mode->vfreq += 0.001;
+
        /* calculate new horizontal frequency */
        mode->hfreq = mode->vfreq * mode->vtotal;


This is switchres vs. lrmc now with this change... (before it was creating a 15.650Khz horizontal refresh for PAL modelines sometimes)

Switchres:
Code: [Select]
MonitorLimits 15624.99-15625.00,50.00-50.00,2.000,4.700,8.000,0.064,0.192,1.024,0,0,312.5,576
Setup monitor limits min=184x148 max=0x592
Decreased vertical frequency to 50.000
Starting with Horizontal freq of 15.385 and Vertical refresh of 50.00
Increased horizontal frequency from 15.385 to 15.625
Original Vref 60.606061 != 50.079995
Using 4 lines padding
# 15.625Khz -> 15.625Khz: ( | Hfreq Change | Vref Change | Vpad +4 lines | )
# pacman [3] 384x288@50.08 15.6250Khz
     "384x288x50.08" 7.874979 384 400 440 504 288 291 294 312 -HSync -VSync

# pacman 384x288@50.08 15.6250Khz
        ModeLine          "384x288x50.08" 7.874979 384 400 440 504 288 291 294 312 -HSync -VSync

LRMC:
Code: [Select]
arcade src # lrmc 384 288 50 -pal -v -v -v -v -v -n

        # 384x288x50.00 @ 15.625kHz
        Modeline "416x288x50.08"  8.000000  416 432 472 512  288 293 296 312  -HSync -VSync


What do you think, is this the right way to do this in the diff above, or is there possibly a problem with checking  we don't go above hfreqMax and then afterwards altering vfreq by .01 increments till we find the exact hfreq we need?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 07, 2010, 01:48:19 pm
I sometimes wondered how would it behave when introducing a very narrow hfreq interval, like the TV case, I'll have a look at it though it seems that change will be harmless. I'm curious about the TV tolerance and ranges, I was surprised of your reporting that PAL TV not accepting 640x480, this seems to be very highly dependant on each TV chassis, as I know of a friend's Sony Trinitron 29" being able to accept nearly the same continuous range as my arcade monitor.

I'm testing a new way to deal with the integer vfreq issue, now that I'm having problems with the xres increment trick. It's about storing vfreq x10, so 57.55 would be 576. I still have to test it but it seems to work. Another digit of precision was too much, raising the label to 4 figures made the system ignore those modes.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 07, 2010, 02:14:37 pm
I sometimes wondered how would it behave when introducing a very narrow hfreq interval, like the TV case, I'll have a look at it though it seems that change will be harmless. I'm curious about the TV tolerance and ranges, I was surprised of your reporting that PAL TV not accepting 640x480, this seems to be very highly dependant on each TV chassis, as I know of a friend's Sony Trinitron 29" being able to accept nearly the same continuous range as my arcade monitor.

I'm testing a new way to deal with the integer vfreq issue, now that I'm having problems with the xres increment trick. It's about storing vfreq x10, so 57.55 would be 576. I still have to test it but it seems to work. Another digit of precision was too much, raising the label to 4 figures made the system ignore those modes.



It's interesting that the 'e' addition to force all outputs on seems to have possibly caused some issue with multiple monitors connected and xrandr functionality.  I'm going to have to test it more, but need to do some sort of different approach to choosing the xrandr output when all are forced on like that.  Will be interesting to see though if that fixes your system with Jpac and the newer radeon card. It's something I've seen before with how xrandr by default with multiple monitors attached has them all mirrored with the same display/screen, so then of course switching modes doesn't work because it always uses the modeline which would fix the non-arcade monitor.  I'm curious if this really happens though with the 'e' force enabled option and only one monitor attached.

I think I fixed it so should be able to have usb stick support for booting instead of a CD, and the install part is improving but still need to test it.  Unfortunately my easier way to test the general working part  of the scripts, using the qemu program (similar to VMWare) to boot it virtually, doesn't seem to allow installing greater than 1.6 Gig onto the virtual hard drive files (whole installation decompressed is about 1.7 Gig).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 07, 2010, 04:34:47 pm
We're getting closer! Now I have video right after the first mode switching (it was black before), I can see it detecting the network and stuff. But then when it performs the second mode switching I get out of video again. I've tested this same cd today with AVGA 9250 and at that point it was showing a blue line box prompting questions inside, really nice... but I can't reach there with my HD4350 cab yet, but definitely the issue is related with monitor not being detected.

Now... I need some help with ssh as this is new to me. I can see the files you need: dmesg.log and messages are at this moment in what seems to be the main path of the arcade system, but I don't know what to type to bring those files to my notebook!
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 07, 2010, 04:57:51 pm
We're getting closer! Now I have video right after the first mode switching (it was black before), I can see it detecting the network and stuff. But then when it performs the second mode switching I get out of video again. I've tested this same cd today with AVGA 9250 and at that point it was showing a blue line box prompting questions inside, really nice... but I can't reach there with my HD4350 cab yet, but definitely the issue is related with monitor not being detected.

Now... I need some help with ssh as this is new to me. I can see the files you need: dmesg.log and messages are at this moment in what seems to be the main path of the arcade system, but I don't know what to type to bring those files to my notebook!

Interesting, so it's X Windows which is failing it seems at that point.  One thing you can do at that point is type Ctl+Atl+F2 and it'll bring you to a console on the system which sounds like it should work and will be easier to work from there possibly than remotely.  You can type `/root/startup.pl -rs` to run the menu system from there too, if wanting to try to run through the setup that way.

With the network running, which hopefully it is (can use the setup otherwise), you'll want an ssh client on another system and then get them from the arcade system by running `scp -rC root@arcadesystem:/path/to/log C:\localdir\` and that will copy them over, using arcade as the password.  I need to put an ftp client on the CD because that'll make this easier, could have just ftp'd them from the system to somewhere that way. 

At the console though hopefully you can see if the /etc/X11/xorg.conf file exists and what it exactly contains, using `less /etc/X11/xorg.conf` to page through it, make sure it has at the top the right monitor 'generic' listed and at the bottom has the modeline generated for it.  It's weird, because I thought the DRM layer would be the only part that didn't like the connectionless Jpac thing but maybe Xorg also is having an issue with it and might need a flag to force it on too.  I will have to research that, but the /var/log/Xorg.0.log file might be very important, combined in checking that /etc/X11/xorg.conf is as expected with the right modeline generated in it.  Using the 'less' command can view these files at least, you might be able to see something in them and hopefully can get scp to copy them from the server.  Look for OpenSSH, a Windows build, and you might be able to install an exe for that and use it from a dos prompt. 

This might be a good client compile of it...

http://sourceforge.net/projects/sshwindows/files/OpenSSH%20for%20Windows%20-%20Release/3.8p1-1%2020040709%20Build/ (http://sourceforge.net/projects/sshwindows/files/OpenSSH%20for%20Windows%20-%20Release/3.8p1-1%2020040709%20Build/)

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 07, 2010, 05:13:22 pm
Hi bitbytebit, I'll try that right now. However I'm already using OpenSSH for Windows and have an open console on arcade ~ #, I've run the scp commands you had posted some posts before and seeing the files when doing dir, it's just that I don't know what to write for destination back to my notebook, 192.168.0.101?? Anyway I'll try from the cab instead.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 07, 2010, 05:23:30 pm
The console is working on the cab! I've run startup.pl, gone through the menu and finally pressed 1 to get into X-Windows, interesting, it reports: /bin/bash: usr/bin/startx: Input/output error

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 07, 2010, 05:34:09 pm
The console is working on the cab! I've run startup.pl, gone through the menu and finally pressed 1 to get into X-Windows, interesting, it reports: /bin/bash: usr/bin/startx: Input/output error



Try to type at the console...

killall startup.pl
killall startup.pl
killall xterm
su - arcade
startx


See what that says then, and the the log file might be interesting too and give more information, /var/log/Xorg.0.log

I think that what is happening is X is already running on console1, so you'll need to first kill off startup.pl (takes 2 times actually) then the xterm which will stop X.  Although it seems to me that most likely X will still startup the same most likely (unless perhaps the xorg.conf is better after manually configuring it). 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 07, 2010, 05:39:21 pm
Also try the other output of the card too, possibly X is showing up on the other input since with both turned on and it not knowing which is actually real, I get the feeling it might just output on one interface.

Update:

Also this might be an option...

Option "Enable"  "True"

Which would be right below the Option "DefaultModes" "False" line in /etc/X11/xorg.conf

That might force it to be on even if not seen as connected.

Past this we might then run into xrandr not knowing it's connected, definitely multiple layers to go through it seems.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 07, 2010, 06:39:30 pm
This is rather weird. I do the killall stuff above and still get that i/o error all the time, *even* when running less. I can explore the file system through the console and see the files you're saying, though it's distressing as I can't do anything useful like sending those files to my laptop (it's my fault, had never used this stuff), it's the trivial things like figuring out how to address network paths what's blocking me...  :banghead:

But, I've seen interesting things. First it doesn't work to switch cables on the fly, you must restart the system with the cable plugged to be able to use that connection. And when I start with VGA connection, it's funny but I get no video after first mode switching but then I have it back at second and can see the blue box with the setup! But then again, it goes black when entering X Windows. But now, I go out to the console and do the killall sequence (by the way, it says it cannot find xterm process, the same happened before with DVI connection). But now when I run startx I'm getting this:

startx

[...]

Fatal server error:
Server is already active for display 0
  If this server is no longer running, remove /tmp/.X0-lock and start again

[...]

XIO Fatal IO error 11 (Resource temporaly unavailable) on X server ":0"

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 07, 2010, 06:52:33 pm
This is rather weird. I do the killall stuff above and still get that i/o error all the time, *even* when running less. I can explore the file system through the console and see the files you're saying, though it's distressing as I can't do anything useful like sending those files to my laptop (it's my fault, had never used this stuff), it's the trivial things like figuring out how to address network paths what's blocking me...  :banghead:

But, I've seen interesting things. First it doesn't work to switch cables on the fly, you must restart the system with the cable plugged to be able to use that connection. And when I start with VGA connection, it's funny but I get no video after first mode switching but then I have it back at second and can see the blue box with the setup! But then again, it goes black when entering X Windows. But now, I go out to the console and do the killall sequence (by the way, it says it cannot find xterm process, the same happened before with DVI connection). But now when I run startx I'm getting this:

startx

[...]

Fatal server error:
Server is already active for display 0
  If this server is no longer running, remove /tmp/.X0-lock and start again

[...]

XIO Fatal IO error 11 (Resource temporaly unavailable) on X server ":0"



What kind of processor is on the system, I'm wondering if possibly the i/o error is something to do with the processor.  It seems odd, not sure why that's not working for those commands but others, but may be something to do with being compiled with flags wrong for that processor.

It definitely needs to have things connected like they will be from boot up, otherwise it'll not know for sure what to setup for the output, the dynamic stuff seems to not work well right now for the DRM stuff.  The odd thing is that the blue box/setup screen is booted up into X so it seems that after that it fails when restarting X.  So it'll work, but I'm not sure why but it's turning off sometimes.  From what I can tell that option "Enable" for xorg.conf might help make it always be on, it's possibly meant for situations like this.

Yeah the whole switch into Linux from Windows has some odd little things that all add up to make it rather confusing, I know how that is from mostly always have used Linux but learned Windows later.  Basically for the most part in Linux you use / instead of C:\ for the root and slashes are the same in each system as the root one.  I'll have lftp in the next .iso which may help since you'll be able to just ftp files from the system.  Also that "Enable" option setup in xorg.conf too, although I am also confused why the i/o error is happening exactly.  That part is the oddest, not sure if it's some compile/processor support issue but strange that some programs are working but others aren't.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 07, 2010, 07:11:22 pm
Does that less program try to go full screen?
I'm very far from being an expert on this but it seems unlikely there's something wrong with your compile not suiting my processor as the system seems rather stable appart from that. That IO issue definitely seems related with the problem on detecting/mapping each connection I'm experimenting. BTW this may be a different issue but reminds me VeS was doing some testing with previous versions + AVGA9250 and had X-Windows restarted each time he started Mame from the frontend, I'll review his email tomorrow.

There's more interesting stuff as the blue box screen being interlaced + doublescanned in my test, so the lower part was missing. I'll do my best to get some skills with this consoles but a ftp would definitely make a difference for me, a nice thing of the ditribution made by VeS is that I could browse the directories from the explorer as network folders so I could edit the stuff easily.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 07, 2010, 07:26:16 pm
Does that less program try to go full screen?
I'm very far from being an expert on this but it seems unlikely there's something wrong with your compile not suiting my processor as the system seems rather stable appart from that. That IO issue definitely seems related with the problem on detecting/mapping each connection I'm experimenting. BTW this may be a different issue but reminds me VeS was doing some testing with previous versions + AVGA9250 and had X-Windows restarted each time he started Mame from the frontend, I'll review his email tomorrow.

There's more interesting stuff as the blue box screen being interlaced + doublescanned in my test, so the lower part was missing. I'll do my best to get some skills with this consoles but a ftp would definitely make a difference for me, a nice thing of the ditribution made by VeS is that I could browse the directories from the explorer as network folders so I could edit the stuff easily.

The less program is just like more, actually try 'more' instead :) maybe that'll work better, or even do a `cat filename` to see the file (can do a shift+page-up or shift+page-down at the console to scroll up/down). 

I'm uploading new .iso right now that have lftp included, and also have the Enable on always for xorg.conf.

That interlace/doublescan thing is very odd, I'm doubting it can even do that, but the blue box is just an xterm up in the lefthand corner at 25x80 and the rest of the screen should be black. 

When the new .iso images are up, should be able to use `lftp -u username ftp://site` to ftp things somewhere.  The goal of course is to make this easy to use and not have to know about Linux, but since just at the start of getting this stuff working it's definitely not there yet, so actually helps that your less familiar with Linux since it's making me think about things a bit better since to me a lot of stuff is second nature that isn't to most people who have used Windows mostly.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 07, 2010, 07:30:13 pm
It's something I've seen before with how xrandr by default with multiple monitors attached has them all mirrored with the same display/screen, so then of course switching modes doesn't work because it always uses the modeline which would fix the non-arcade monitor.  I'm curious if this really happens though with the 'e' force enabled option and only one monitor attached.

Oh, that is the infamous Catalyst 'clone' feature or it's equivalent. That really needs to be disabled somehow in order to have each display as independent, otherwise, at least in Windows, they will work as a block and you won't have access to the advanced features as vsync for each display.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 08, 2010, 04:46:55 am
The less program is just like more, actually try 'more' instead :) maybe that'll work better, or even do a `cat filename` to see the file (can do a shift+page-up or shift+page-down at the console to scroll up/down).

I was trying to use 'type' DOS command but it has some different use here :)

I'm uploading new .iso right now that have lftp included, and also have the Enable on always for xorg.conf.

That interlace/doublescan thing is very odd, I'm doubting it can even do that, but the blue box is just an xterm up in the lefthand corner at 25x80 and the rest of the screen should be black. 

Interlace + doublescan is actually pretty possible although we are not considering that option in our calculations as I can't imagine a use for it. It's more of an issue than anything else, when trying to do a 320x480i resolution with regular Catalyst, you get your requested interlace but as Catalyst are hardcoded to react at 320x and 400x resolutions activating doublescan for them, then you end up having doublescan + interlace, and the lower half of the screen is chopped (what really happens is that the upper half is stretched to cover the screen because of lines doubling). That issue is one of the main reasons for my patching them btw. The funny part is that with AVGA9250 that blue box part is perfect, no doublescan, and is indeed located on the lefthand corner.

So there are probably different issues getting mixed at the same time. Hopefully they'll be figured out sooner or later. I had missed the other thread were Quinny is testing, and the PAL issue and that, interesting. I hope I'll be able to try the new iso later today. Most of the time I have a baby around now and my wife is starting to get crazy each time I unroll the network cable through the house ;)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 08, 2010, 10:37:46 am
The less program is just like more, actually try 'more' instead :) maybe that'll work better, or even do a `cat filename` to see the file (can do a shift+page-up or shift+page-down at the console to scroll up/down).

I was trying to use 'type' DOS command but it has some different use here :)

I'm uploading new .iso right now that have lftp included, and also have the Enable on always for xorg.conf.

That interlace/doublescan thing is very odd, I'm doubting it can even do that, but the blue box is just an xterm up in the lefthand corner at 25x80 and the rest of the screen should be black.  

Interlace + doublescan is actually pretty possible although we are not considering that option in our calculations as I can't imagine a use for it. It's more of an issue than anything else, when trying to do a 320x480i resolution with regular Catalyst, you get your requested interlace but as Catalyst are hardcoded to react at 320x and 400x resolutions activating doublescan for them, then you end up having doublescan + interlace, and the lower half of the screen is chopped (what really happens is that the upper half is stretched to cover the screen because of lines doubling). That issue is one of the main reasons for my patching them btw. The funny part is that with AVGA9250 that blue box part is perfect, no doublescan, and is indeed located on the lefthand corner.

So there are probably different issues getting mixed at the same time. Hopefully they'll be figured out sooner or later. I had missed the other thread were Quinny is testing, and the PAL issue and that, interesting. I hope I'll be able to try the new iso later today. Most of the time I have a baby around now and my wife is starting to get crazy each time I unroll the network cable through the house ;)


Yeah, I can understand that, but the odd thing is there isn't any ability to output interlace/doublescan in any of my modelines in the DRM (all are hardwired) or in the switchres modeline it'll setup for xorg.conf by default.  So it's really impossible for it to do that from what I can tell, unless it's using the default modes which might be possible.  

When you have it with the blue box, what does `xrandr -display :0.0 -q` show?   That might be interesting, and also `xrandr -display :0.0 -q --verbose` might be helpful too (after doing the Alt+Ctl+F2 to get to the second terminal, also check Alt+Ctl+F1 since that's the first terminal that X started up in).  This new version has lftp on it so if you do those commands and >log.txt for each, and ftp them somwhere and post them for me, that might show me something (and also check what is in /etc/X11/xorg.conf when in the blue window too, see what the modeline is it's using).  

I am thinking that one big thing needed, at least with Jpac, is going through all the connectors and disabling all but the main one and do like Soft15Khz and require the first output to be used only.  Since we can't see the monitors and they are 'invisible' with Jpac, it seems like the only way to really work with it.  Basically force connector 1 (DVI-I-1) on permanently and every other one off.  Does that sound like the way Windows users are used to doing this?  I figure dual screens are only useful for testing, although another option is to basically force the card to act like an AVGA card and always have the first output be CGA no matter what and second VGA.  I can specify at the grub.conf stuff which connectors do what and sounds like this might be what I need to do.  The one issue though is knowing what is the first one, because there are VGA- connectors and DVI-I- connectors and then HDMI-I- connectors too.  So hard to know for sure what will work in all cases, not sure if best to choose the VGA-1 and DVI-I-1 or not.  The other confusing thing is that is how the DRM stuff calls them by those names, but in xrandr we get different ones like DVI-0 is possibly DVI-I-1 from the DRM layer, but not with all cards so it's not consistent (it's all so new though, must be expected, I think all this stuff will become easier to work with in a few months when they start realizing some of this odd issues and get X Windows working with it more consistently).  


Update:

See the other thread with the possibly grub command line changes to try, try this with the new .iso and see if anything is better using them if the default doesn't work better. Basically there's ways to specify the exact connector to force on and the resolution to use for it.  
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 08, 2010, 12:52:54 pm
Yeah, I can understand that, but the odd thing is there isn't any ability to output interlace/doublescan in any of my modelines in the DRM (all are hardwired) or in the switchres modeline it'll setup for xorg.conf by default.  So it's really impossible for it to do that from what I can tell, unless it's using the default modes which might be possible.

I see what you mean and indeed suspected some of the default modes stuff was somehow being invoked as I also got that unexpected 31 Khz mode on my AVGA cab right before X Windows was started.

I am thinking that one big thing needed, at least with Jpac, is going through all the connectors and disabling all but the main one and do like Soft15Khz and require the first output to be used only.  Since we can't see the monitors and they are 'invisible' with Jpac, it seems like the only way to really work with it.  Basically force connector 1 (DVI-I-1) on permanently and every other one off.  Does that sound like the way Windows users are used to doing this?  I figure dual screens are only useful for testing, although another option is to basically force the card to act like an AVGA card and always have the first output be CGA no matter what and second VGA.  I can specify at the grub.conf stuff which connectors do what and sounds like this might be what I need to do.  The one issue though is knowing what is the first one, because there are VGA- connectors and DVI-I- connectors and then HDMI-I- connectors too.  So hard to know for sure what will work in all cases, not sure if best to choose the VGA-1 and DVI-I-1 or not.  The other confusing thing is that is how the DRM stuff calls them by those names, but in xrandr we get different ones like DVI-0 is possibly DVI-I-1 from the DRM layer, but not with all cards so it's not consistent (it's all so new though, must be expected, I think all this stuff will become easier to work with in a few months when they start realizing some of this odd issues and get X Windows working with it more consistently).

According to SailorSat newer ATI cards use DVI as their primary device, and VGA as second, it's the opposite to the older Radeon like 9250. So the expected behaviour is that they'll boot with both connections on, but if no monitor is detected in either of them, they will go to the default setup turning on primary device only (DVI). However there are many cards with two DVIs, HDMIs and no VGA, so it will be different there. So what you're saying will do that also, and might work. Dual screen support could be added when we have this simpler scheme fully working, but it's not required now, what we must make sure is that the 'clone' feature is not added, as it's a kind of fake dual screen thing that many people are using in their home cinemas without knowing it really sucks.

The interesting thing is that when starting your previous cd with either one of the connections plugged, it seemed that after the boot, that is displayed simultaneousy through both connections, each of the parts was showing on a different device, so the missing part with DVI was the one that showed on VGA. This is independant to the issue with default(?) modes I was commenting that I think has been there from previous versions.

I don't really know if that behaviour with connection management and how it is different with newer cards has to do with software (drivers,...) or is a BIOS feature. However that DRM stuff in development seems promising as once it's mature hopefully it could also work with HD5000 family and above, that definitely don't support anything without EDID on Windows.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 08, 2010, 01:22:23 pm
Yeah, I can understand that, but the odd thing is there isn't any ability to output interlace/doublescan in any of my modelines in the DRM (all are hardwired) or in the switchres modeline it'll setup for xorg.conf by default.  So it's really impossible for it to do that from what I can tell, unless it's using the default modes which might be possible.

I see what you mean and indeed suspected some of the default modes stuff was somehow being invoked as I also got that unexpected 31 Khz mode on my AVGA cab right before X Windows was started.

I am thinking that one big thing needed, at least with Jpac, is going through all the connectors and disabling all but the main one and do like Soft15Khz and require the first output to be used only.  Since we can't see the monitors and they are 'invisible' with Jpac, it seems like the only way to really work with it.  Basically force connector 1 (DVI-I-1) on permanently and every other one off.  Does that sound like the way Windows users are used to doing this?  I figure dual screens are only useful for testing, although another option is to basically force the card to act like an AVGA card and always have the first output be CGA no matter what and second VGA.  I can specify at the grub.conf stuff which connectors do what and sounds like this might be what I need to do.  The one issue though is knowing what is the first one, because there are VGA- connectors and DVI-I- connectors and then HDMI-I- connectors too.  So hard to know for sure what will work in all cases, not sure if best to choose the VGA-1 and DVI-I-1 or not.  The other confusing thing is that is how the DRM stuff calls them by those names, but in xrandr we get different ones like DVI-0 is possibly DVI-I-1 from the DRM layer, but not with all cards so it's not consistent (it's all so new though, must be expected, I think all this stuff will become easier to work with in a few months when they start realizing some of this odd issues and get X Windows working with it more consistently).

According to SailorSat newer ATI cards use DVI as their primary device, and VGA as second, it's the opposite to the older Radeon like 9250. So the expected behaviour is that they'll boot with both connections on, but if no monitor is detected in either of them, they will go to the default setup turning on primary device only (DVI). However there are many cards with two DVIs, HDMIs and no VGA, so it will be different there. So what you're saying will do that also, and might work. Dual screen support could be added when we have this simpler scheme fully working, but it's not required now, what we must make sure is that the 'clone' feature is not added, as it's a kind of fake dual screen thing that many people are using in their home cinemas without knowing it really sucks.

The interesting thing is that when starting your previous cd with either one of the connections plugged, it seemed that after the boot, that is displayed simultaneousy through both connections, each of the parts was showing on a different device, so the missing part with DVI was the one that showed on VGA. This is independant to the issue with default(?) modes I was commenting that I think has been there from previous versions.

I don't really know if that behaviour with connection management and how it is different with newer cards has to do with software (drivers,...) or is a BIOS feature. However that DRM stuff in development seems promising as once it's mature hopefully it could also work with HD5000 family and above, that definitely don't support anything without EDID on Windows.



So are you able to see the grub menu on bootup with both cards, or just the AVGA one?

I'm now looking at the difference between the 'e' option and 'D' option which seems to be that e is force it on while D is force it on digitally.  I'm not fully sure why it wouldn't know if the output is digital or analog in the DRM stuff.  It has VGA connectors and DVI connector types, also TV connector types but I'm also sort of confused about that too and if I should call it a TV-1 for a person with a PAL/NTSC TV or still use the DVI-I-1 output.  I think the best default is the 640x480 CGA mode and Enable forced on just the DVI-I-1 output, hopefully rest aren't connected. 


The clone screen thing in X Windows requires setup with virtually expanding the desktop larger and having monitors both fit on it.  This will never work though because they are still connected, only the Nvidia proprietary drivers can actually treat both outputs like two independent screens.  Anyways under Linux dual monitor support doesn't work for mame, and also seems it's really tricky to either setup xorg.conf for this in a generic way (if that's even possible).  Using xrandr you can sort of setup things but you still need to make a big virtual desktop for a single card with 2 outputs, and why it's really just one screen and the modeswitching just won't work.  So it's probably best to avoid dual monitors on a card and expecting the arcade mode to work, unless doing tests of course.  I actually use 2 video cards on my desktop for dual monitors because otherwise it's not fully independent in Linux, on my arcade cab I have an older radeon in there to allow output to a normal LCD monitor if necessary because having the other output connected confuses xrandr and it won't switch to arcade resolutions at all.  I had in the perl switchres to basically turn off all monitors except the one chosen, which you have to choose because it's hard to tell which connected one is the one you want.  I might need to do something similar, perhaps just turn off everything besides the first output/DVI.


So your saying that if I pick DVI-I-1 as the only arcade output, this will duplicate the behavior of Soft15Khz and always make the first output work?  Or would that require an AVGA card to use the digital connection?  That's the main issue I have with it, if I pick DVI would only newer radeons work on the first output and if I pick VGA only older ones on the first output and need to have a VGA connection too.  Not sure how to just always have the first output  enabled in both cases with one simple grub config option, that also is viewable upon boot.  Although I guess since the AVGA can output to 15Khz on boot then there could be a separate grub option for it using the VGA-1 output instead?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 08, 2010, 03:59:45 pm
I won't be able to try the new iso until tomorrow but I've managed to copy the config file and log from the previous one for you to check. I copied them doing ssh from my laptop to the cab. I'm also very slowly getting familiar with the consoles trying to restart X Windows with different options, etc. Editing xorg.conf with that 'vi' command is a complicated, reminds me of DOS edlin. At some point I was able to have video on X desktop while switching consoles by CTRL + ALT + 1, 2, 3 but it was out of range (no option changed, just restarting it).

I can see the grub menu on both cards but with HD4350 it's out of range (jpac however allows a duplicated distorted picture).

On boot, both connections are on, I believe this happens with all cards (ATI, nVidia, etc), and they output the same standard vesa mode. But at some point during startup it's when monitor checking is done and then the secondary device is turned off if there is no monitor plugged. In Windows that point is right after the driver is loaded, in Linux it seems to be when DRM is started. However, trying to answer your question (I'm not sure), forcing DVI as primary should only be done for the newer Radeon, and for the older ones the VGA should be the primary (bear in mind that Radeon 9250 DVI is only digital, not digital/analog like in HD4350, so the DVI-VGA adapter wouldn't even fit) so I can't think of an easy choice for you to do, but to have both options on grub menu and the user selecting it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 08, 2010, 04:27:15 pm
I won't be able to try the new iso until tomorrow but I've managed to copy the config file and log from the previous one for you to check. I copied them doing ssh from my laptop to the cab. I'm also very slowly getting familiar with the consoles trying to restart X Windows with different options, etc. Editing xorg.conf with that 'vi' command is a complicated, reminds me of DOS edlin. At some point I was able to have video on X desktop while switching consoles by CTRL + ALT + 1, 2, 3 but it was out of range (no option changed, just restarting it).

I can see the grub menu on both cards but with HD4350 it's out of range (jpac however allows a duplicated distorted picture).

On boot, both connections are on, I believe this happens with all cards (ATI, nVidia, etc), and they output the same standard vesa mode. But at some point during startup it's when monitor checking is done and then the secondary device is turned off if there is no monitor plugged. In Windows that point is right after the driver is loaded, in Linux it seems to be when DRM is started. However, trying to answer your question (I'm not sure), forcing DVI as primary should only be done for the newer Radeon, and for the older ones the VGA should be the primary (bear in mind that Radeon 9250 DVI is only digital, not digital/analog like in HD4350, so the DVI-VGA adapter wouldn't even fit) so I can't think of an easy choice for you to do, but to have both options on grub menu and the user selecting it.


Sounds good I will look at the logs, thanks.

Yeah I'm right now hopefully making it so it has the multiple boot menu options for DVI or VGA, and also making a script run that will turn off all other monitors/outputs besides the first one and one we picked at boot basically (at X startup that is, using xrandr, it can turn off monitors/outputs).  This will at least make sure that mode switching works right, since if those other outputs are on it won't, and also at the same time should allow us to force on connectors (although right now I'm forcing on only the first DVI or VGA one in this newest work I'm doing).

So might have an .iso up tonight which may be something to test tomorrow too.  Also I do have disk installation fully working now although need to figure out the changes for the way the startup.pl script work then because it no longer is the same startup (no autologin once installed on the harddrive).  Also hopefully usb stick bootup will work eventually but there's some issues with it finding the root file system since it's a usb stick and not a CD drive (probably just simple grub command line issues I think).  

Hopefully we've got the video issues somewhat cornered with getting the output forced on but yet only for the first input so Jpac is happy but does't take out modeswitching in the process.  It's interesting because this seems to be a big issue with truly getting modelines to work with xrandr and generally the newest Linux DRM stuff working when things like Jpac are used or TV's, real Arcade Monitors.  So I'm figuring this isn't going to be easy, I now realize that this d9800 makes it a lot easier and I didn't suspect there was so many issues actually.  So am glad I started working on this now, seems like to get things working with Linux and the newest stuff (which is what allows the vsync and modeline switching to work close to ideal) is sort of uncharted territory and we're wading through some interesting issues.  I just wish the Linux DRM people cared more about this, the Alex guy has been very helpful, yet there's really no interest in any actual changes in the core Linux code itself to figure out the Arcade Monitor issues (since I admit it's quite a crazy thing, try to figure out how to work with monitors that basically give no information back and with Jpac the monitor is invisible and that's just not the easiest problem to solve).  How does Windows exactly output to a Jpac connected monitor, if it can't see it, is that something only Soft15Khz solves or an ArcadeVGA card?  Oh, you mean they always enable the first monitor even if not connected?  Which I guess the DRM layer doesn't even do, interesting, so we do have the ability to do more and possibly enable only one of any of the outputs, as long as we know which is preferred ahead of time (and without a viewable grub menu, possibly only setup ahead of time with a normal monitor would be the way to do it, like I guess arcadeVGA and Soft15khz sometimes require).

Also you can use the nano editor and it'll be much nicer than vi :)  


Update:

Yeah from the xorg logs I definitely see that it's bad to have enabled all the interfaces like that, so newer changes I have done should be much better about that.  I think it might have to do with how the HDMI is shared with the other output, and for HDMI it's seeing all the default modes and that might be part of the issue. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 08, 2010, 04:58:00 pm
How does Windows exactly output to a Jpac connected monitor, if it can't see it, is that something only Soft15Khz solves or an ArcadeVGA card?  Oh, you mean they always enable the first monitor even if not connected?

Yes, that's how it works in my experience (don't mean it's the rule). In fact with Windows I have video through DVI-VGA with default Cat 9.3 options. However, if I wanted to plug the arcade monitor to the VGA (second device), I believe I should start the system with a pc monitor connected to the DVI and the arcade monitor to the VGA, then activate the second display on screen/properties, and then it should be already on for the next Windows session, provided I didn't unplug the VGA cable in the middle (then it would disable it).

Yeah from the xorg logs I definitely see that it's bad to have enabled all the interfaces like that, so newer changes I have done should be much better about that.  I think it might have to do with how the HDMI is shared with the other output, and for HDMI it's seeing all the default modes and that might be part of the issue. 

Yes, we have that HDMI there to deal with  :(
Reminds me that's something I have to investigate, as I don't know if DVI and HDMI can be used as independent devices with this card or not, as I intended at the beginning (that would make possible to use the same card with a plasma TV for movies and an arcade monitor or crt TV for games).

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 08, 2010, 05:02:14 pm
How does Windows exactly output to a Jpac connected monitor, if it can't see it, is that something only Soft15Khz solves or an ArcadeVGA card?  Oh, you mean they always enable the first monitor even if not connected?

Yes, that's how it works in my experience (don't mean it's the rule). In fact with Windows I have video through DVI-VGA with default Cat 9.3 options. However, if I wanted to plug the arcade monitor to the VGA (second device), I believe I should start the system with a pc monitor connected to the DVI and the arcade monitor to the VGA, then activate the second display on screen/properties, and then it should be already on for the next Windows session, provided I didn't unplug the VGA cable in the middle (then it would disable it).

Yeah from the xorg logs I definitely see that it's bad to have enabled all the interfaces like that, so newer changes I have done should be much better about that.  I think it might have to do with how the HDMI is shared with the other output, and for HDMI it's seeing all the default modes and that might be part of the issue.  

Yes, we have that HDMI there to deal with  :(
Reminds me that's something I have to investigate, as I don't know if DVI and HDMI can be used as independent devices with this card or not, as I intended at the beginning (that would make possible to use the same card with a plasma TV for movies and an arcade monitor or crt TV for games).



I think I see the issue you saw with interlace/doublescan together when booting into X with the xterm box config on first boot.  It's weird, didn't do that before but I suspect the *fixes* they did for interlace/doublescan have possibly actually done the opposite and broken interlace/doublescan in X Windows (but fine it seems in the frame buffer).  They might have an update for the X driver which works with that change in DRM, else I might have to reverse it for now and report how it seems to actually just doublescan/interlace and end up with what seems to be a progressive half size display.

Update:

I see what causes this now, it's actually the Option "Enable" "True" I added to force the X Windows to work on outputs, I'm hoping that isn't necessary for the Jpac case because it seems to totally destroy overscan.  It might be actually due to the other interfaces also being enabled, it's hard to point to just one output in xorg.conf and tell it what to do.  I may have to use xrandr to do that I'm guessing.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 09, 2010, 05:55:51 pm
Hi bitbytebit,

It's finally working! I've tested CGA-DVI, NTSC-DVI and PAL-DVI and they all get to the desktop without problems (strange but only CGA failed 3 of 4 times, then it worked, but I suspect it could have been the jpac overflowing the keyboard buffer, this happens very very rarely but it could have happened right now corrupting my tests). Apart from that everything was nice and clean, all modes perfectly adjusted. It only seems to fail when run an existing Mame game from Wahcade. When it does not exist, it quickly switches video mode (I can see a big mouse cursor indicating a low res mode) but then switches back Wahcade. But when I select the Gridlee game (just one I see you've included) then unfortunately the screen goes black and never comes back (I'm able to go to the console however). So this seems to be improving a lot. I've attached the logs for you to check, right to the point where I get out of video.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 09, 2010, 06:04:57 pm
Hi bitbytebit,

It's finally working! I've tested CGA-DVI, NTSC-DVI and PAL-DVI and they all get to the desktop without problems (strange but only CGA failed 3 of 4 times, then it worked, but I suspect it could have been the jpac overflowing the keyboard buffer, this happens very very rarely but it could have happened right now corrupting my tests). Apart from that everything was nice and clean, all modes perfectly adjusted. It only seems to fail when run an existing Mame game from Wahcade. When it does not exist, it quickly switches video mode (I can see a big mouse cursor indicating a low res mode) but then switches back Wahcade. But when I select the Gridlee game (just one I see you've included) then unfortunately the screen goes black and never comes back (I'm able to go to the console however). So this seems to be improving a lot. I've attached the logs for you to check, right to the point where I get out of video.


Sounds good, yeah I'm overhauling how Wahcade is setup because the config it uses right now is not really functional, also have really improved the window manager used and selection.  It's going to need a swapspace setup for wahcade to actually generate the filter lists it seems, I discovered that, so really the current wahcade setup isn't going to probably work well.  Does it work though from the command line running `switchres <romname>` ?   That should work from an xterm hopefully (right mouse and 'new' option). 

I've been getting a lot of the setup and general install part working better, and will include a better window manager named lxde which is really nice and also have chromium setup on it now too so there's a web browser. 

I need to add swap space configuration and have wahcade with a generic setup for those free roms at first, also on setup it'll now launch the wahcade setup so everything can be configured from there to  point to the /data_ro/ drive mounted roms possibly. 

Later tonight I should have all that done, and will get some new .iso's up most likely by tomorrow.  Definitely looking interesting now, the PAL TV setup seems to be somewhat working and I think the fixes I've done would probably complete that (can't get desktop but games work).  Also hopefully am going to get a USB stick and fix that installation, and fix up any issues with normal hard drive install.  I think the whole wahcade setup will make things better, since it'll do all the work, just the need for a swap drive unfortunately to create the filter list for the ROMS (seems that process takes way too much memory, although if a system has more than the system I am testing on that's a laptop with 500 meg it might be able to work without swap enabled).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 10, 2010, 06:29:19 am
New .iso files are up, hopefully the Wahcade behavior is better and also the desktop setup might work better too I'm hoping.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 10, 2010, 07:18:13 am
I'll test that later today, as well as Switchres from the console to see if it works that way.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 10, 2010, 05:21:17 pm
Hi bitbytebit,

The new version seems to load quicker and the new Windows environment is very cool, Wahcade also loads now the correct Mame list. However I still have the same issue as soon as I load Mame, either from Wahcade or using switchres romname from lxterm. The video is just turned off, as was happining before in the previous steps. I can bring the desktop back by going into the cosole 1 and pressing ctrl+c. Could it be that xrandr is using a different device for output?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 10, 2010, 05:43:23 pm
Hi bitbytebit,

The new version seems to load quicker and the new Windows environment is very cool, Wahcade also loads now the correct Mame list. However I still have the same issue as soon as I load Mame, either from Wahcade or using switchres romname from lxterm. The video is just turned off, as was happining before in the previous steps. I can bring the desktop back by going into the cosole 1 and pressing ctrl+c. Could it be that xrandr is using a different device for output?


Yeah that might just be what is happening.  From the console when the X Windows screen is black, see what `xrandr -display :0.0 --current` shows you.  Possibly send the output if you can, or just see what modes/displayoutputs are active and have the resolution set to it.  That should show what is going on, it might be getting the current screen wrong I think.  Also see what dmesg output shows at the time when it's still black on the console, it'll show the DRM switching activity, and possibly at the end of your /var/log/Xorg.0.log file it might shed some clues. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 10, 2010, 06:44:12 pm
- xrandr says DVI-0 is enabled, VGA-0 and HDMI-0 disabled. DVI-0 has two available modes, 640x480@30 and 256x240@59 (this one is marked as active and current video mode). So at first sight everything looks correct  ???

- dmesg propts a very long output, at the end of it it was mentioning DVI-I-1 all the time.

Today I hadn't the network plugged, I'll send you the logs as soon as I can.

BTW is there a text editor available from the new desktop environment?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 10, 2010, 07:02:19 pm
- xrandr says DVI-0 is enabled, VGA-0 and HDMI-0 disabled. DVI-0 has two available modes, 640x480@30 and 256x240@59 (this one is marked as active and current video mode). So at first sight everything looks correct  ???

- dmesg propts a very long output, at the end of it it was mentioning DVI-I-1 all the time.

Today I hadn't the network plugged, I'll send you the logs as soon as I can.

BTW is there a text editor available from the new desktop environment?


That is interesting, it technically sounds correct so definitely odd it's going black.  Also when you get logs, xrandr with --verbose added onto that command line will show even more information.  Yeah the DVI-I-1 is equal to DVI-0 in X windows, so that all sounds good, very strange.

The 'nano' text editor is probably the best one to use, which is a lot easier to use than vi.

It'd possibly be interesting to see the output of mame/switchres from the command line, using the '--args -verbose' added to switchres to pass verbose to mame.  So this doesn't happen on the other AVGA card cabinet, just the newer ATI card? 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 11, 2010, 12:28:33 am
I have a SwitchRes version 1.10r91 uploaded now.  I have been able to have Soft15khz modelines installed, and rewrite them to match the one generated by switchres for a game when it loads.  I don't have my windows system setup to test if this really works, so needing to know if it works or not.  Basically I can load all Soft15Khz modelines, run switchres and since it mostly covers the common resolutions it seems to be enough to always have one we can use.  Then at that point after rewriting the appropriate matching modeline I run the ActiveLines RegEnum stuff that should restart the ATI Catalyst drivers.  Calamity, if you could test this and check the latest diff's in the GIT repository to see if this is really working right.  You can basically uninstall/reinstall Soft 15khz to reset the modelines to the defaults again, and this only will alter existing modelines from Soft15khz or other ATI custom modelines.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 11, 2010, 04:45:10 am
I've been thinking of the xrandr thing and it could be working after all, as I do can see the mouse cursor at 256x240 during an instant, right before the screen goes blank, so it definitely must be switching resolutions. So, the issue might happen later, maybe with SDL or something? (I don't have a clear picture of how many layers are actually operating with video in Linux). It's strange because at least I should be able to return from Mame pressing ESC, but it just gets stuck there and I have to CTRL+C from the console. There's a test that I should have done and didn't... it's to check jpac leds to see if we have sync, in case we have that would mean the issue falls on the software part. I'll send you those logs.

Good news you have the Windows part done, I'll test it as soon as I can, however I don't use Soft-15Khz as I'm in the process of testing my patched drivers that do more or less the same thing, but will definitely be interesting to see if they can coexist.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 11, 2010, 04:56:14 am
So this doesn't happen on the other AVGA card cabinet, just the newer ATI card?  

The lastests tests I've done were with the HD4350, I haven't tested the AVGA cab since last week as it's in another place, however remind it was loading X Windows without problems, but was also failing when invoking a game from Wahcade (it was going out from X Windows), so I don't know if it could be the same issue or not.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 11, 2010, 09:49:33 am
So this doesn't happen on the other AVGA card cabinet, just the newer ATI card?  

The lastests tests I've done were with the HD4350, I haven't tested the AVGA cab since last week as it's in another place, however remind it was loading X Windows without problems, but was also failing when invoking a game from Wahcade (it was going out from X Windows), so I don't know if it could be the same issue or not.

It sounds like an SDL/OpenGL (most likely OpenGL) issue I guess, it actually is possibly the same behavior I saw when the vertical active lines were not  aligned to 8.  Of course it can't be doing that, the 8 thing, because it shouldn't be giving those values and I just tested the h9110 monitor type here and doesn't do it, so somehow it's trigging a similar issue in OpenGL but for some other reason card/chip specific.  I do see this behavior when running on an Intel chipset, basically other cards other than the Radeon, but that's somewhat expected because the OpenGL Gallium stuff isn't stable on those yet and I think the compile I am doing might be wrong for them (or they just don't work well yet with KMS/DRM/Gallium).  So it could be an OpenGL bug, I need to recompile those and also check to make sure I'm enabling every possible compatiblity I can, and look at the SDL build too.  They work well on my 4350 card but for some reason there's something different on yours, which is why I'm really curious about the AVGA card.  It could bring up a whole other issue with the crashing, which is interesting, so this is definitely the next level it looks like to work on is getting the actual SDL/OpenGL Gallium stuff working with all chips instead of just a few Radeons.  One interesting thing to see would be the output of `lspc -v` on your 4350 system (can from there see the pci ID and then just run `lspci -v 0:1:0` or similar to shorten the information output) because that will show exactly what RV chip is on there and if it's really the same chipset as mine is.

 
Also some other tests to try would be running with the --xrandr option to switchres, which will use xrandr to mode switch instead of SDL.  Then with that use the `--emulator xterm` and that won't run mame but instead an xterm and will show you if it can switch resolutions and then point to SDL/OpenGL.  Also then after that can try just the `--args -video soft` and use software rendering and see if that works (may have to add -throttle -mt onto that --args line for vsync to work too).  Those are a few interesting things to try, I get the feeling you will see a resolution switch without mame, and you will see it work with software rendering, at least if it's the SDL/OpenGL layer issues I'm guessing it is.

Another test would be running glxgears inside of an xterm and see if OpenGL runs, or the output of glxinfo and see what driver it's using and chipset.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 11, 2010, 05:41:55 pm
Hi bitbytebit,

I've done some tests and definitely is related to OpenGL, as switchres works flawlessly with the -video soft option, but when I use -video openg the screen goes blank. I've saved the logs of both for you to check, as well as the results of the stuff you asked.

This is the output of lspci:

arcade ~ # lspci -v -s 02:00.0
02:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350] (
prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Device 02a8
        Flags: bus master, fast devsel, latency 0, IRQ 67
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Memory at feae0000 (64-bit, non-prefetchable) [size=64K]
        I/O ports at e000 [size=256]
        Expansion ROM at feac0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information <?>
        Kernel driver in use: radeon
        Kernel modules: radeon

By the way 02:00.1 is an audio device of Ati HD4000's family, I guess it's related to HDMI audio part?

arcade ~ # lspci -v -s 02:00.1
02:00.1 Audio device: ATI Technologies Inc R700 Audio Device [Radeon HD 4000 Ser
ies]
        Subsystem: ASUSTeK Computer Inc. Device aa38
        Physical Slot: 16
        Flags: bus master, fast devsel, latency 0, IRQ 65
        Memory at feafc000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information <?>
        Kernel driver in use: HDA Intel
        Kernel modules: snd-hda-intel

For some reason lscpi only works when I ssh from my notepad to root, but the command is not recognized when from my cab (xterm), where is it supposed to be run? I couldn't either run glxgears or glxinfo, these commands are not recognized.

I won't be able to do tests on the AVGA cab for some days, but I'll post the results as soon as I get them.

I've been able to test the Mame roms included and it works great with mode switching, hopefully this issue is figured out soon as I'm eager to test it at its full capabilities.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 11, 2010, 05:49:58 pm
Hi bitbytebit,

I've done some tests and definitely is related to OpenGL, as switchres works flawlessly with the -video soft option, but when I use -video openg the screen goes blank. I've saved the logs of both for you to check, as well as the results of the stuff you asked.

This is the output of lspci:

arcade ~ # lspci -v -s 02:00.0
02:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350] (
prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Device 02a8
        Flags: bus master, fast devsel, latency 0, IRQ 67
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Memory at feae0000 (64-bit, non-prefetchable) [size=64K]
        I/O ports at e000 [size=256]
        Expansion ROM at feac0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information <?>
        Kernel driver in use: radeon
        Kernel modules: radeon

By the way 02:00.1 is an audio device of Ati HD4000's family, I guess it's related to HDMI audio part?

arcade ~ # lspci -v -s 02:00.1
02:00.1 Audio device: ATI Technologies Inc R700 Audio Device [Radeon HD 4000 Ser
ies]
        Subsystem: ASUSTeK Computer Inc. Device aa38
        Physical Slot: 16
        Flags: bus master, fast devsel, latency 0, IRQ 65
        Memory at feafc000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information <?>
        Kernel driver in use: HDA Intel
        Kernel modules: snd-hda-intel

For some reason lscpi only works when I ssh from my notepad to root, but the command is not recognized when from my cab (xterm), where is it supposed to be run? I couldn't either run glxgears or glxinfo, these commands are not recognized.

I won't be able to do tests on the AVGA cab for some days, but I'll post the results as soon as I get them.


I'm updating the OpenGL and SDL/xorg-server and SDL libraries all to the newest versions, hoping maybe that fixes something, also added some support to those for the different extra features of Radeon cards so maybe that'll help.  Your lspci looks exactly the same as mine does here, so is the exact same chip, definitely strange.  In the xterm for lspci you might have to do the 'sudo -s' first to become root, I'm not sure why the glxgears and glxinfo aren't working though, odd. 

I'm also updating mame to version 140u2 with the patches (they changed a bunch of stuff, is requiring refactoring some stuff with the redraw patch).  Also mess 140u2 hopefully, will see how that goes since I had to pull the SVN of it to work with u2.  I'm making Gentoo ebuilds of them too, so will be actual packages for the system which is kind of nice to have available for Gentoo users.

I'll look at the logs more and let you know what I find, there's definitely something odd about OpenGL and supporting different cards, but this is really weird how we have the same one and it's doing the odd stuff on yours but not mine.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 12, 2010, 08:43:06 am
I've got a new 32bit ISO uploaded which has newer OpenGL and SDL libraries, with some extra compile options to possibly help the OpenGL issue.  Also newest mame and mess versions 0140u2 hiscore/galaxian/redraw patched are on it.  I found why glxgears and glxinfo aren't working, I guess they were only built on my 64 bit build so didn't figure that out till after the newest 32 bit version uploaded.  If this version doesn't work then on the next ISO they'll be there to possibly check although I doubt they'll tell too much info though. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 12, 2010, 02:27:35 pm
I've tested dynamic stuff with Soft-15Khz installed, I believe there's some things that need to be modified for it to work. When you read resolutions from registry, you're recalculating vfreq which is good for your inner stuff but you should not redo the label by using 'int (vfreq)', but keep the original one you read from registry (always 60 with soft-15khz) so you will address the correct registry key and system mode label when editing it. So most of the resolutions you read are being relabeled as @59 and passing that as a parameter to Mame, which is using a random resolution as it doesn't find that one. Also you must use the strict ones available in the system. At the moment, if a game is 320x224 you're using that one, when you should go for the next available one: 320x240 and operate on that with the correct vfreq we want, then run Mame with 320x240@60 even if you have tweaked it to be 58.00 Hz. A problem does arise when dealing with vertical games, as the resulting rotated resolution is the one you should check against the mode table, and it won't be there probably. I've been checking the registry while running switchres to see the changes, but I haven't seen any, probably because the right resolutions were not pointed to.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 12, 2010, 02:42:22 pm
I've tested dynamic stuff with Soft-15Khz installed, I believe there's some things that need to be modified for it to work. When you read resolutions from registry, you're recalculating vfreq which is good for your inner stuff but you should not redo the label by using 'int (vfreq)', but keep the original one you read from registry (always 60 with soft-15khz) so you will address the correct registry key and system mode label when editing it. So most of the resolutions you read are being relabeled as @59 and passing that as a parameter to Mame, which is using a random resolution as it doesn't find that one. Also you must use the strict ones available in the system. At the moment, if a game is 320x224 you're using that one, when you should go for the next available one: 320x240 and operate on that with the correct vfreq we want, then run Mame with 320x240@60 even if you have tweaked it to be 58.00 Hz. A problem does arise when dealing with vertical games, as the resulting rotated resolution is the one you should check against the mode table, and it won't be there probably. I've been checking the registry while running switchres to see the changes, but I haven't seen any, probably because the right resolutions were not pointed to.



Odd, I actually am just using the same label from the registry that I read from it, not rewriting it at all, so not sure why the label would change.  I basically am storing the label and modeline (lpValueName and lpData) values, then only changing the lpData values to the modeline switchres created (which should always be less than or equal to the HxW of the label, so the buffer is correctly sized for it).  So I'm really just using the same label, and not giving it any information about the actual vertical frequency, could it be dynamically calculating the label for us?  I do need to use the label for the resolution from the registry for mame though, which probably is the issue, since it's still using the actual parameters and not the label (from the previous change I had made to do that), I kind of forgot about that needing to be done too.  So sounds like if I redo the mame label on the command line to match the labels, maybe it'll start working.  If you run it with -v -v then it'll show the changes it's making in more detail, it should be changing the values, at least is here from the Soft15khz ones put into the registry.  If it doesn't find one that fits though, it'll just default to the old behavior of naming the resolution it wants but not having it in the registry as the default would be without switchres.  I suspect the main issue is the command line to mame needs to be changed, I will do that since it should be a simple change (actually back to how I was originally doing it before I started reading the modeline information details in lpData).

Update:

Actually from what I can tell I actually am using the label completely, with the same vertical refresh rate that is in the registry.  It wouldn't though on older mame versions, since that is given with the separate -refresh argument to mame (are you testing with the older mame version), that might explain what is going on if so.  I'm fixing it so it saves the refresh rate separately from the label for the older mame version, but for newer ones it should be using the exact same registry key label as the -resolution line to mame. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 12, 2010, 03:24:41 pm
I've tested dynamic stuff with Soft-15Khz installed, I believe there's some things that need to be modified for it to work. When you read resolutions from registry, you're recalculating vfreq which is good for your inner stuff but you should not redo the label by using 'int (vfreq)', but keep the original one you read from registry (always 60 with soft-15khz) so you will address the correct registry key and system mode label when editing it. So most of the resolutions you read are being relabeled as @59 and passing that as a parameter to Mame, which is using a random resolution as it doesn't find that one. Also you must use the strict ones available in the system. At the moment, if a game is 320x224 you're using that one, when you should go for the next available one: 320x240 and operate on that with the correct vfreq we want, then run Mame with 320x240@60 even if you have tweaked it to be 58.00 Hz. A problem does arise when dealing with vertical games, as the resulting rotated resolution is the one you should check against the mode table, and it won't be there probably. I've been checking the registry while running switchres to see the changes, but I haven't seen any, probably because the right resolutions were not pointed to.
I am pretty sure I figured out what is going on, was checking for the vfreq when finding the best modes among the registry modelines, which now that we can change them that doesn't matter anymore.  So it wasn't finding one that would work and just using the one it generated instead.

I uploaded a new Windows version that hopefully fixes this correctly, 1.01r107
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 12, 2010, 04:23:48 pm
There's still a bug in it. Have a look at my logs attached. It's filling a 240x240 modeline structure with 320x240 mode, and 320x256 with 384x256, which produces a bad mode as labels don't match modeline resolutions. Good news are it's actually editing registry keys and taking affect, so we are just one step from having it working.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 12, 2010, 04:44:35 pm
There's still a bug in it. Have a look at my logs attached. It's filling a 240x240 modeline structure with 320x240 mode, and 320x256 with 384x256, which produces a bad mode as labels don't match modeline resolutions. Good news are it's actually editing registry keys and taking affect, so we are just one step from having it working.

Cool, good to know it can dynamically change them, now it looks like I need to improve my method of finding the best resolution then :).  Will let you know when I get that improved, had wondered about how well that would work in all cases and seems to be hitting an issue there.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 12, 2010, 05:56:27 pm
There's still a bug in it. Have a look at my logs attached. It's filling a 240x240 modeline structure with 320x240 mode, and 320x256 with 384x256, which produces a bad mode as labels don't match modeline resolutions. Good news are it's actually editing registry keys and taking affect, so we are just one step from having it working.

I think this fixes it, found the issue with having checks with < instead of <=, hopefully doesn't foul up anything else which I don't think it will.  Also now am using the label for the check to make sure it's the right/max width/height the resolution can handle and write back the old value after we are done with running mame and using the modeline to what it was originally.  

This one hopefully works correctly now:

SwitchResWin-1.115-d23d86b.7z

Small bug with 240x240 resolution, well actually any that were 16 pixels larger horizontally it would choose but this fixes that now:


SwitchResWin-1.116-eaaab88.7z
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 12, 2010, 06:26:05 pm
I'll try that one. I suppose you've done it but just in case, for each mode, label height/width and its modeline height/width (active x y) must match, so if a given mode is not found, go for a bigger one where it fits in, but use this second one for all the registry and Mame stuff, only the game's vfreq will be used.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 12, 2010, 06:35:48 pm
I'll try that one. I suppose you've done it but just in case, for each mode, label height/width and its modeline height/width (active x y) must match, so if a given mode is not found, go for a bigger one where it fits in, but use this second one for all the registry and Mame stuff, only the game's vfreq will be used.

I think I've done that, basically using the label HxW for matching, and if the resolution we want is less than the label it picks the one closest but still larger than our modeline so will fit in the allocated buffer for that label/modeline.  I'm using the labels just for matching and mame command line -resolution/-refresh stuff, but internally the real HxW and Vfreq it'll actually set the modeline.  Hopefully the matching always has the AI to pick the best available modeline now. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 12, 2010, 06:50:47 pm
No, that's what I meant. Internally you can't use the real H/W but the one that matches the label :( Otherwise you'll get a bad working mode (it'll be completely out of sync, not only chopped or anything). However I'll test that but it won't work very probably. So once you decide for an existing mode you unfortunately have to ignore your original H/W for calculations and use the label ones.

So if you need to a mode like 384x256@55, and the closest you have is 400x256@60, you'll have to actually calculate a real modeline with 400x256@55, and then call Mame -resolution 400x256@60, that's the best you can do.

That's why I suggested that we need to create a decent mode table (with my patched drivers we can reach to 134 modes), as using a list of about 30 modes will be definitely not enough, although this technique combined with normal Soft-15Khz mode list will still produce much richer results than what's normally achieved.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 12, 2010, 07:00:07 pm
No, that's what I meant. Internally you can't use the real H/W but the one that matches the label :( Otherwise you'll get a bad working mode (it'll be completely out of sync, not only chopped or anything). However I'll test that but it won't work very probably. So once you decide for an existing mode you unfortunately have to ignore your original H/W for calculations and use the label ones.

So if you need to a mode like 384x256@55, and the closest you have is 400x256@60, you'll have to actually calculate a real modeline with 400x256@55, and then call Mame -resolution 400x256@60, that's the best you can do.

That's why I suggested that we need to create a decent mode table (with my patched drivers we can reach to 134 modes), as using a list of about 30 modes will be definitely not enough, although this technique combined with normal Soft-15Khz mode list will still produce much richer results than what's normally achieved.


Ah ok, I see now, interesting.  Yeah looks like with more modelines it would help overcome all the cases, mostly should work decent on common games now I'm suspecting but that'll be nice to have modeline tables then in usermodes.txt.  I'll look at lrmc and see about ripping out the code in there since it basically will do this for the set of mame games, but replace the modeline generation with the switchres one. 

I'll also take a look at regenerating the modeline after the registry match is found, or possibly moving the registry check before modeline calculation and then use the available hxw for calculation.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 12, 2010, 09:08:21 pm
Ok, I think I got it working right, version SwitchResWin-1.117-3bf4ed6.7z will do a recalculation of the modeline so if you only have 240x240 in the registry it'll take a 240x224 resolution and recalculate it to 240x240 instead.  Not sure if there's some missing logic to double check if it needs to use any extra flags but guessing not since that logic should already be in place, I think.  It now just requires a vast number of resolutions to be more accurate, more the better of course.   So the modeline generator part should make this work very well.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 13, 2010, 01:59:50 am
I think I found the issues with crashing/black screen when running mame with opengl support.  Seems to be that the Gallium support (http://en.wikipedia.org/wiki/Gallium3D (http://en.wikipedia.org/wiki/Gallium3D)) for Mesa causes this to happen.  It at least seems to be the difference between what your seeing and what I normally get on my other system, when run on my test laptop with an Intel video card.  So I'm not 100% sure it's really going to fix what your seeing but it does seem to be a very likely candidate, I suspect Gallium support and Mame only work under certain conditions and seems to not be very compatible with multiple card types.  I can still get the same performance without Gallium for mame, so seems to not matter when it isn't used.

I'll have some new .iso files up soon without Gallium support in them, and will see how they work, hopefully fix the issue and can finally see how under Linux the mode-switching works.  I'm still baffled as to why my cabinet can handle Gallium support just fine, but every other system and even yours with the same video card doesn't, very strange, but this at least should be a more compatible stable option all around.  Now hopefully in a few weeks to a month the 2.6.38 kernel will arrive with the page flip support and we'll have a very accurate vblank/sync support to really make any tearing not occur.  It's odd because I don't see tearing as it is, so this change sounds like it'll just be even better which it's already pretty good.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 13, 2010, 09:23:36 am
I've gotten those new .ISO files up and hopefully have fixed the mame/gallium OpenGL issue by removing gallium from OpenGL and using the classic Mesa code instead.  I also have it able to switch back and forth between Gallium mode and non-Gallium mode through running eselect like this...

eselect opengl list ->
 [1]   nogalium *
 [2]   xorg-x11

eselect opengl set 2 -> (will set it to use Gallium)
eselect opengl set 1 -> (will set it to not use Gallium)

Hopefully that works as expected, am taking advantage of a feature of portage/Gentoo packaging for OpenGL where they allow multiple libraries for different video cards.  So a person who has a system like mine where Gallium works and wants to try it can, although I really think it works the same without it because I ran the N64 emulator mupen64plus and didn't see a difference immediately. 

I'm also going to try and find the issue with mame and gallium, although may be one of those very hard to figure out things.  At least am going to see if I can run a debugger and find what code it's actually hitting to segfault (which is what it seems to be doing, either that or it locks like you see with a black screen, right in the middle of switching modes, I also think this might be the same issue that causes the non-aligned to 8 lines height to lock similar to what your seeing).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 13, 2010, 11:08:02 am
I've tested new Switchres and I'm afraid there's still something that prevents it from working, though hopefully I've figured it out. When switching to the just created modeline, the mode is broken, completely out of sync, after that I can't even modify it with Arcade_OSD. I've seen that the registry key is stored with one or more extra zero bytes after the checksum, and that might probably be the issue. Please check that and I'll test it again tonight, as well as the new ISO.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 13, 2010, 11:50:43 am
I've tested new Switchres and I'm afraid there's still something that prevents it from working, though hopefully I've figured it out. When switching to the just created modeline, the mode is broken, completely out of sync, after that I can't even modify it with Arcade_OSD. I've seen that the registry key is stored with one or more extra zero bytes after the checksum, and that might probably be the issue. Please check that and I'll test it again tonight, as well as the new ISO.


I think I know exactly the problem, I was adding a + 1 to the lpcData size calculation and so it makes sense and without that it should do it right.  Am testing that now.  Will have a new Windows binary up soon.

I hopefully have figured out this openGL thing, it's weird because basically when I compile both Gallium and non-Gallium versions then either way with eselect works now.  I think that by compiling both I'm doing something with the OpenGL libraries which is a good thing, maybe it needs both, at least it now works on my 'test case' that had issues and now is fine (a toshiba laptop with an intel i915G or something video card).  It at least was doing a similar thing, so hopefully by fixing that it also will fix the other cases where openGL hangs or crashes from mame.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 13, 2010, 12:13:13 pm
So the livecd32_12-13-2010_01_25_54.iso should already have those changes, doesn't it? I'm eager to test that one.

Yes, it was adding an extra byte and maybe if called twice an additional one, that's why I saw two zeros sometimes, is it possible?

Just a simple question as this really should be easy to do but I still can't get it. Imagine you have a path in your Windows partition named "C:\Roms\Mame" where all your roms reside. What exact answers would you enter through your config setup in order to make the system point to that path? I see there's a logic with that home directory, data, and stuff being mapped somehow, but I really don't know if I can make use of that without actually modifying my path structure in Windows (something I'd rather not doing). It's the same with "C:\Snap\Mame". I always use that logic as I believe is the easiest possible (ie. C:\(Roms, Snap, ...)\Emulator). I can see my hd being mapped as /dev/sda1 or something like that, but can't figure what to do with that and my path to work together.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 13, 2010, 12:29:34 pm
So the livecd32_12-13-2010_01_25_54.iso should already have those changes, doesn't it? I'm eager to test that one.

Yes, it was adding an extra byte and maybe if called twice an additional one, that's why I saw two zeros sometimes, is it possible?

Just a simple question as this really should be easy to do but I still can't get it. Imagine you have a path in your Windows partition named "C:\Roms\Mame" where all your roms reside. What exact answers would you enter through your config setup in order to make the system point to that path? I see there's a logic with that home directory, data, and stuff being mapped somehow, but I really don't know if I can make use of that without actually modifying my path structure in Windows (something I'd rather not doing). It's the same with "C:\Snap\Mame". I always use that logic as I believe is the easiest possible (ie. C:\(Roms, Snap, ...)\Emulator). I can see my hd being mapped as /dev/sda1 or something like that, but can't figure what to do with that and my path to work together.

Yes, it would keep adding an extra byte each time I guess, interesting.  Hopefully this ISO does better, at least I think I'm close at figuring out the issue but of course just have to see how OpenGL acts with that video card now.

You would use the /dev/sda1 or whatever it is as the data drive, it'll mount that under /data_ro, and when asked about the symlinks/rom locations you would then say you want to add them.  Then you would have real rom locations like, /data_ro/Roms/Mame and that would be the value for the C:\Roms\Mame directory, /data_ro/Roms/Mame when it asks where the Mame ROMS are located.  Then it'll use a symlink for you from /data_ro/Roms/Mame -> /data/roms and should work.  Same with the other locations, basically they will be mounted to /data_ro/XXX and should be case sensitive to (so might want to check in another xterm window what are the contents of /data_ro after mounting that drive).  There's a layout file in /home/arcade/.gentooarcade/ after those layouts are made which sort of shows the logic (although that file is only read on startup).  All the admin/setup stuff definitely needs some work, I eventually hope to focus on just making the setup interface better for this kind of stuff (like right now can't go back and redo the layout links after configuration, although if you go manually and do things like 'ln -s /data_ro/Roms/Mame /data/roms' it should work too).

Also you can really not even use the symlinks /data/ directory, if you run wahcade-setup and point it to where you have the Windows drive mounted then you can bypass the need for any of the custom layout stuff.  In a way it's probably better to do it that way right now, just tell wahcade-setup about /data_ro/Roms/Mame and other directories.  Of course to do that you will need a swap drive to do the re-indexing stuff, unfortunately it takes quite a bit of memory for that (may work without it, but probably depends how much memory the system has physically). 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 13, 2010, 12:38:02 pm
Oh, thanks, it's perfectly clear now :)
I'll have a try later, will let you know.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 13, 2010, 12:55:37 pm
Oh, thanks, it's perfectly clear now :)
I'll have a try later, will let you know.


This version, SwitchResWin-1.121-ddbfb81.7z, should no longer add the extra byte.  I was wondering why some entries weren't the same size, must have been the reason.

Also I'm writing a quick Perl script to calculate the needed dummy modes for the usermodes.txt file in Soft15khz.  It's interesting, seems there's about 190 modelines needed to really match every resolution for the most part.  Here's my basic script here, I have some checks for height to reduce the odd ones but probably could remove some more I think. 

Code: [Select]
#!/usr/bin/perl

$MAME_XML = "mame.xml";

my @resolutions = ();
my @lines = `grep "<display" $MAME_XML`;
foreach (@lines) {
        my $line = $_;
        chomp($line);
        my @parts = split(/\s+/, $line);
        my ($height, $width, $refresh, $orientation);
        foreach(@parts) {
                my $part = $_;
                chomp($part);
                my ($key, $value) = split(/=/, $part);
                $value =~ s/\"//g;
                if ($key eq 'width') {
                        $width = $value;
                } elsif ($key eq 'height') {
                        $height = $value;
                } elsif ($key eq 'refresh') {
                        $refresh = $value;
                } elsif ($key eq 'orientation') {
                        if ($value != 0 && $value != 360) {
                                $orientation = 1;
                        }
                }
        }
        if ($orientation) {
                my $tw = $width;
                my $th = $height;
                $height = $tw;
                $width = $height * (4.0/3.0);
        }
        my $new_height = recalc_height($height);
        $width = recalc_width($width);
        if ($new_height) {
                $height = $new_height;
        } else {
                # greater than 768 pixels high
        }
        if ($height && $width) {
                my $exists = 0;
                #print "$width $height $refresh\n";
                for (my $i = 0; $i < scalar(@resolutions); $i++) {
                        if ($resolutions[$i]{'width'} == $width &&
                                $resolutions[$i]{'height'} == $height)
                        {
                                $exists = 1;
                        }
                }
                if (!$exists) {
                        my $len = scalar(@resolutions);
                        $resolutions[$len]{'width'} = $width;
                        $resolutions[$len]{'height'} = $height;
                }
        }
}

for (my $i = 0; $i < scalar(@resolutions); $i++) {
        my ($width, $height);
        $width = $resolutions[$i]{'width'};
        $height = $resolutions[$i]{'height'};
        #print "$width $height\n";
        @mline = `switchres $width $height 60.00`;
        foreach (@mline) {
                my $line = $_;
                chomp($line);
                $line =~ s/\s+/ /g;
                $line =~ s/^\s+//g;
                if ($line !~ /^#/ && $line ne '') {
                        print "$line\n";
                }
        }
}

exit 0;

sub recalc_width($) {
        my $w = shift(@_);

        $w = (($w / 8)+(($w % 8)&0x01)) * 8;

        if ($w < 240) {
                $w = 240;
        }

        return $w;
}

sub recalc_height($) {
        my $h = shift(@_);
       
        if ($h < 192) {
                $h = 192;
        } elsif ($h > 192 && $h < 224) {
                $h = 224;
        } elsif ($h > 224 && $h < 240) {
                $h = 240;
        } elsif ($h > 240 && $h < 256) {
                $h = 256;
        } elsif ($h > 264 && $h < 288) {
                $h = 288;
        } elsif ($h > 288 && $h < 384) {
                $h = 384;
        } elsif ($h > 768) {
                return 0;
        }
        $h = (($h / 8)+(($h % 8)&0x01)) * 8;
        return $h;
}


It's just a rough sketch right now of it, need to do more parsing and checking to reduce things some and have some duplicates too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 13, 2010, 02:05:12 pm
It seems that there's about 104 or so modelines necessary to allow all the different needed resolutions to be created.  I now have a new script, genres.pl, which basically is like the original genres but now uses switchres and works better than genres ever did before...

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob;f=scripts/genres.pl (http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob;f=scripts/genres.pl)

It's in the GIT repository under the scripts/ directory, here's the basic output of the generic monitor type (can specify monitor type, even tell it to use vsync which produces around 200 resolutions)...

I don't know for sure if this is an ok formatting for Soft15khz, suspect it is, and of course the refresh rates don't matter but are there just to show what they are actually for the reference modeline (plus I'm pretty sure Soft15khz changes them for the label anyways to integers and such)..
Code: [Select]
ModeLine "288x224x60.02" 6.038391 288 304 336 384 224 234 237 262 -HSync -VSync
ModeLine "256x224x60.02" 5.535192 256 272 304 352 224 234 237 262 -HSync -VSync
ModeLine "272x240x60.02" 5.786791 272 288 320 368 240 242 245 262 -HSync -VSync
ModeLine "768x224x60.02" 15.724976 768 800 872 1000 224 234 237 262 -HSync -VSync
ModeLine "240x224x60.02" 5.031992 240 256 280 320 224 234 237 262 -HSync -VSync
ModeLine "320x240x57.00" 6.670368 320 336 368 424 240 249 252 276 -HSync -VSync
ModeLine "512x224x60.02" 10.567185 512 536 584 672 224 234 237 262 -HSync -VSync
ModeLine "256x256x57.07" 5.544000 256 272 304 352 256 257 260 276 -HSync -VSync
ModeLine "480x192x60.02" 9.938186 480 504 552 632 192 218 221 262 -HSync -VSync
ModeLine "512x240x60.02" 10.567185 512 536 584 672 240 242 245 262 -HSync -VSync
ModeLine "640x240x60.02" 13.083181 640 664 728 832 240 242 245 262 -HSync -VSync
ModeLine "544x480x60.00" 11.214000 544 568 624 712 480 484 490 525 -HSync -VSync interlace
ModeLine "272x224x60.02" 5.786791 272 288 320 368 224 234 237 262 -HSync -VSync
ModeLine "304x224x60.02" 6.415791 304 320 352 408 224 234 237 262 -HSync -VSync
ModeLine "496x480x60.00" 10.206000 496 520 568 648 480 484 490 525 -HSync -VSync interlace
ModeLine "640x480x60.13" 13.083016 640 664 728 832 480 483 489 523 -HSync -VSync interlace
ModeLine "512x256x57.07" 10.584000 512 536 584 672 256 257 260 276 -HSync -VSync
ModeLine "256x192x60.02" 5.535192 256 272 304 352 192 218 221 262 -HSync -VSync
ModeLine "240x192x60.02" 5.031992 240 256 280 320 192 218 221 262 -HSync -VSync
ModeLine "704x480x59.94" 14.601396 704 736 808 928 480 484 490 525 -HSync -VSync interlace
ModeLine "256x240x60.02" 5.535192 256 272 304 352 240 242 245 262 -HSync -VSync
ModeLine "264x224x59.56" 5.660961 264 280 312 360 224 235 238 264 -HSync -VSync
ModeLine "376x256x57.07" 7.812000 376 392 432 496 256 257 260 276 -HSync -VSync
ModeLine "336x256x57.07" 6.930000 336 352 384 440 256 257 260 276 -HSync -VSync
ModeLine "240x240x50.00" 5.040000 240 256 280 320 240 269 272 315 -HSync -VSync
ModeLine "352x240x60.02" 7.422189 352 368 408 472 240 242 245 262 -HSync -VSync
ModeLine "512x480x60.00" 10.584000 512 536 584 672 480 484 490 525 -HSync -VSync interlace
ModeLine "480x480x60.00" 9.954000 480 504 552 632 480 484 490 525 -HSync -VSync interlace
ModeLine "384x256x55.00" 7.927920 384 400 440 504 256 262 265 286 -HSync -VSync
ModeLine "384x240x60.02" 7.925388 384 400 440 504 240 242 245 262 -HSync -VSync
ModeLine "320x224x60.02" 6.667390 320 336 368 424 224 234 237 262 -HSync -VSync
ModeLine "384x224x60.02" 7.925388 384 400 440 504 224 234 237 262 -HSync -VSync
ModeLine "640x224x60.02" 13.083181 640 664 728 832 224 234 237 262 -HSync -VSync
ModeLine "264x240x60.02" 5.660992 264 280 312 360 240 242 245 262 -HSync -VSync
ModeLine "280x240x60.02" 5.912591 280 296 328 376 240 242 245 262 -HSync -VSync
ModeLine "296x240x60.02" 6.289991 296 312 344 400 240 242 245 262 -HSync -VSync
ModeLine "800x480x60.13" 16.353770 800 832 912 1040 480 483 489 523 -HSync -VSync interlace
ModeLine "360x256x57.00" 7.551360 360 376 416 480 256 257 260 276 -HSync -VSync
ModeLine "360x240x57.00" 7.551360 360 376 416 480 240 249 252 276 -HSync -VSync
ModeLine "400x240x60.02" 8.176988 400 416 456 520 240 242 245 262 -HSync -VSync
ModeLine "280x224x60.02" 5.912566 280 296 328 376 224 234 237 262 -HSync -VSync
ModeLine "336x224x60.02" 6.918990 336 352 384 440 224 234 237 262 -HSync -VSync
ModeLine "664x496x57.52" 13.719050 664 696 760 872 496 503 509 547 -HSync -VSync interlace
ModeLine "416x224x60.02" 8.554388 416 432 472 544 224 234 237 262 -HSync -VSync
ModeLine "1024x480x60.13" 20.882507 1024 1064 1160 1328 480 483 489 523 -HSync -VSync interlace
ModeLine "248x240x57.44" 5.288602 248 264 288 336 240 248 251 274 -HSync -VSync
ModeLine "384x192x60.02" 7.925388 384 400 440 504 192 218 221 262 -HSync -VSync
ModeLine "328x240x58.02" 6.793102 328 344 376 432 240 247 250 271 -HSync -VSync
ModeLine "320x256x57.07" 6.678000 320 336 368 424 256 257 260 276 -HSync -VSync
ModeLine "376x224x59.19" 7.808712 376 392 432 496 224 236 239 266 -HSync -VSync
ModeLine "304x256x57.07" 6.426000 304 320 352 408 256 257 260 276 -HSync -VSync
ModeLine "368x256x57.07" 7.686000 368 384 424 488 256 257 260 276 -HSync -VSync
ModeLine "576x224x59.19" 11.839015 576 600 656 752 224 236 239 266 -HSync -VSync
ModeLine "336x240x60.02" 6.918912 336 352 384 440 240 242 245 262 -HSync -VSync
ModeLine "480x464x60.00" 9.954000 480 504 552 632 464 476 482 525 -HSync -VSync interlace
ModeLine "496x240x60.02" 10.189785 496 520 568 648 240 242 245 262 -HSync -VSync
ModeLine "304x240x60.02" 6.415791 304 320 352 408 240 242 245 262 -HSync -VSync
ModeLine "328x256x57.07" 6.804000 328 344 376 432 256 257 260 276 -HSync -VSync
ModeLine "512x288x51.14" 10.583999 512 536 584 672 288 289 292 308 -HSync -VSync
ModeLine "672x240x60.02" 13.837921 672 704 768 880 240 242 245 262 -HSync -VSync
ModeLine "400x224x60.02" 8.176988 400 416 456 520 224 234 237 262 -HSync -VSync
ModeLine "392x224x60.02" 8.051188 392 408 448 512 224 234 237 262 -HSync -VSync
ModeLine "1024x528x55.08" 20.882493 1024 1064 1160 1328 528 531 537 571 -HSync -VSync interlace
ModeLine "512x192x60.02" 10.567185 512 536 584 672 192 218 221 262 -HSync -VSync
ModeLine "704x528x54.91" 14.597873 704 736 808 928 528 532 538 573 -HSync -VSync interlace
ModeLine "408x256x54.82" 8.432327 408 424 464 536 256 263 266 287 -HSync -VSync
ModeLine "400x256x56.67" 8.191560 400 416 456 520 256 258 261 278 -HSync -VSync
ModeLine "768x576x50.08" 15.750160 768 800 872 1000 576 584 590 629 -HSync -VSync interlace
ModeLine "248x224x60.02" 5.283592 248 264 288 336 224 234 237 262 -HSync -VSync
ModeLine "344x240x60.02" 7.044790 344 360 392 448 240 242 245 262 -HSync -VSync
ModeLine "328x224x60.02" 6.793190 328 344 376 432 224 234 237 262 -HSync -VSync
ModeLine "368x240x60.02" 7.673789 368 384 424 488 240 242 245 262 -HSync -VSync
ModeLine "480x240x59.12" 9.938108 480 504 552 632 240 244 247 266 -HSync -VSync
ModeLine "448x224x60.02" 9.434986 448 472 520 600 224 234 237 262 -HSync -VSync
ModeLine "448x240x60.02" 9.434986 448 472 520 600 240 242 245 262 -HSync -VSync
ModeLine "376x240x60.02" 7.799589 376 392 432 496 240 242 245 262 -HSync -VSync
ModeLine "384x288x51.14" 7.937999 384 400 440 504 288 289 292 308 -HSync -VSync
ModeLine "368x224x60.02" 7.673789 368 384 424 488 224 234 237 262 -HSync -VSync
ModeLine "360x224x60.02" 7.547989 360 376 416 480 224 234 237 262 -HSync -VSync
ModeLine "496x224x60.02" 10.189785 496 520 568 648 224 234 237 262 -HSync -VSync
ModeLine "320x192x60.02" 6.667390 320 336 368 424 192 218 221 262 -HSync -VSync
ModeLine "464x224x60.02" 9.686586 464 488 536 616 224 234 237 262 -HSync -VSync
ModeLine "480x224x60.02" 9.938186 480 504 552 632 224 234 237 262 -HSync -VSync
ModeLine "432x224x59.00" 8.821680 432 448 488 560 224 237 240 267 -HSync -VSync
ModeLine "352x256x57.07" 7.434000 352 368 408 472 256 257 260 276 -HSync -VSync
ModeLine "680x224x60.02" 13.963780 680 712 776 888 224 234 237 262 -HSync -VSync
ModeLine "712x288x50.00" 14.742000 712 744 816 936 288 293 296 315 -HSync -VSync
ModeLine "680x288x50.00" 13.986000 680 712 776 888 288 293 296 315 -HSync -VSync
ModeLine "400x288x50.00" 8.190000 400 416 456 520 288 293 296 315 -HSync -VSync
ModeLine "704x240x60.02" 14.592778 704 736 808 928 240 242 245 262 -HSync -VSync
ModeLine "296x224x60.02" 6.289991 296 312 344 400 224 234 237 262 -HSync -VSync
ModeLine "416x256x57.07" 8.568000 416 432 472 544 256 257 260 276 -HSync -VSync
ModeLine "680x480x60.13" 13.963604 680 712 776 888 480 483 489 523 -HSync -VSync interlace
ModeLine "288x240x60.02" 6.038391 288 304 336 384 240 242 245 262 -HSync -VSync
ModeLine "640x256x57.07" 13.104000 640 664 728 832 256 257 260 276 -HSync -VSync
ModeLine "544x224x60.02" 11.196184 544 568 624 712 224 234 237 262 -HSync -VSync
ModeLine "432x256x57.07" 8.820000 432 448 488 560 256 257 260 276 -HSync -VSync
ModeLine "352x224x60.02" 7.422189 352 368 408 472 224 234 237 262 -HSync -VSync
ModeLine "544x256x57.07" 11.214000 544 568 624 712 256 257 260 276 -HSync -VSync
ModeLine "464x256x57.07" 9.702000 464 488 536 616 256 257 260 276 -HSync -VSync
ModeLine "720x480x60.00" 14.868000 720 752 824 944 480 484 490 525 -HSync -VSync interlace
ModeLine "648x240x60.02" 13.208981 648 672 736 840 240 242 245 262 -HSync -VSync
ModeLine "736x264x55.46" 15.120000 736 768 840 960 264 265 268 284 -HSync -VSync
ModeLine "312x288x51.14" 6.551999 312 328 360 416 288 289 292 308 -HSync -VSync



Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 13, 2010, 05:42:22 pm
I have good news with Switchres, it's working DAMNED WELL!! I've just tested it with Soft15Khz modes, and it's actually performing dynamic modelines with it, so I'm testing non 60Hz games and they're running at their original refresh, 55, 57.55, 58 Hz, etc.

With a richer mode list it's going to be perfect, because I'm seeing some issues, for instance with 384x224@59.xxx, as it goes for the existing 384x288@60 (the only with 384 pixels width) which due to this monitor limitations cannot go any further than 54Hz because of its extreme yres, so the game is unnecesarily slowed. But it's just a matter of doing a decent list. I believe that even with the default 60 modes available in Catalyst we could do something interesting. With my patched Catalyst that is able to manage up to 134 modes, I believe it will be enough.

There's some stuff to work out as how to deal with virtualized modes, as monitor's type is something that's going to determine the list of needed modes so it will have to be considered at first hand when doing the table.

I'm seeing some issues also with virtualized modes, as the streching is not properly passed to Mame, you have to use hwstretch 0/1 in regular Mame. The cleanstretch option is a CabMame one and is additional to the other, but don't know if it is a good idea to use that in the virtualize context (anyway it only works with -video d3d, not needed with -video ddraw).

It's important to remember to rename the Mame ini folder, otherwise I will use the options in them.
There's also a point that could be checked, I normally use 'resolution0' instead of plain 'resolution', it's working here with both but see all the programs doing inis use both simultaneously. I believe the correct way would be to really consider which device to point to (0/1), however, we can leave that by now.

On the other hand, livecd32_12-13-2010_01_25_54.iso still fails when -video opengl is used, works ok with -video soft. The screen goes black and I have to CTRL+C from the cosole to bring it back :(

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 13, 2010, 05:56:22 pm
I have good news with Switchres, it's working DAMNED WELL!! I've just tested it with Soft15Khz modes, and it's actually performing dynamic modelines with it, so I'm testing non 60Hz games and they're running at their original refresh, 55, 57.55, 58 Hz, etc.

With a richer mode list it's going to be perfect, because I'm seeing some issues, for instance with 384x224@59.xxx, as it goes for the existing 384x288@60 (the only with 384 pixels width) which due to this monitor limitations cannot go any further than 54Hz because of its extreme yres, so the game is unnecesarily slowed. But it's just a matter of doing a decent list. I believe that even with the default 60 modes available in Catalyst we could do something interesting. With my patched Catalyst that is able to manage up to 134 modes, I believe it will be enough.

There's some stuff to work out as how to deal with virtualized modes, as monitor's type is something that's going to determine the list of needed modes so it will have to be considered at first hand when doing the table.

I'm seeing some issues also with virtualized modes, as the streching is not properly passed to Mame, you have to use hwstretch 0/1 in regular Mame. The cleanstretch option is a CabMame one and is additional to the other, but don't know if it is a good idea to use that in the virtualize context (anyway it only works with -video d3d, not needed with -video ddraw).

Yeah I didn't know how in Windows that exactly was done, think I need to add the hwstretch option then and only use cleanstretch with that if using the patched/cabmame version.  In Linux seems unevenstretch covers both of those options I guess.

That genres.pl script hopefully by taking the monitor in account and using switchres in theory should be able to figure out all the possible virtualized modes it would go through.


It's important to remember to rename the Mame ini folder, otherwise I will use the options in them.
There's also a point that could be checked, I normally use 'resolution0' instead of plain 'resolution', it's working here with both but see all the programs doing inis use both simultaneously. I believe the correct way would be to really consider which device to point to (0/1), however, we can leave that by now.

Yeah I didn't know for sure, seemed to be just doing resolution covers all the monitor outputs and 0/1 cover specific monitors.  It seems unclear which is the 'right' way, at least in Linux it doesn't really even make sense to use anything else because it doesn't even support multiple monitors but in Windows maybe resolution0 is the best one? or resolution to cover all, seems weird to have to do both and I always assumed those scripts are just doing something unnecessary but I may be wrong.  (probably looking at the source awhile would answer things for certain, I haven't looked too closely except for the Linux side more than Windows and remember that it doesn't really matter in Linux and don't remember what I saw for Windows).

On the other hand, livecd32_12-13-2010_01_25_54.iso still fails when -video opengl is used, works ok with -video soft. The screen goes black and I have to CTRL+C from the cosole to bring it back :(



Ah dang, yeah maybe trying to do the 'eselect opengl list' and then eselect opengl set 1 or 2 and trying both OpenGL builds, see if that does anything different.  So mame basically is hanging it sounds like and holding things in the in-between state of switching to graphics output (but is in the state because the mouse shows?).  Also possibly check the xorg.conf and change the video driver to use "ati" instead of radeon, something to try, and if not that then try it by running the create_xorg-dyn.pl <monitor_type> script and redirect that output to xorg.conf.  It may be an xorg configuration issue, I'm not sure though.  It's just strange that card acts so different than mine does, yet sounds like exactly what mine did/does when giving it vertical active lines not aligned to 8 lines.  Also seeing what happens on your AVGA card may be interesting, seeing if it's just that card and the AVGA works better now with this latest ISO. 

I'll look deeper into OpenGL, any interesting things/logs you see let me know, and I'll explore it some more. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 13, 2010, 06:10:54 pm
Uploaded SwitchResWin-1.124-e69707d.7z Windows build that uses the hwstretch option too, no longer either/or with cleanstretch like before.  Also am using both resolution and resolution0 to be safe and duplicate the .ini files behaviors.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 13, 2010, 06:26:38 pm
I'll keep testing. There's something I've seen, when the screen is black I still have the sync leds on in the jpac, so the mode switching is performed properly, it's just that it hangs after that. I've also tested glxgears and it propmts normal stuff to the console but shows starts a window with nothing inside, just a black background, I suppose there should be something showing there. Then when I kill that window I get the same error message in the console as when I do CTRL+C in the Mame case. If I do glxgears -fullscreen it just goes full screen with the mouse cursor only on a black background, I have to kill this too as there's no way to exit (ALT+TAB does work however, it does not with Mame).

Could this be due to the need of also specifying the target device inside OpenGL? I don't know if this make any sense at all, but I do use that stuff with DirectX. After all, having the same card, the only difference I can think about is the monitor part again...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 13, 2010, 06:29:20 pm
I'll keep testing. There's something I've seen, when the screen is black I still have the sync leds on in the jpac, so the mode switching is performed properly, it's just that it hangs after that. I've also tested glxgears and it propmts normal stuff to the console but shows starts a window with nothing inside, just a black background, I suppose there should be something showing there. Then when I kill that window I get the same error message in the console as when I do CTRL+C in the Mame case. If I do glxgears -fullscreen it just goes full screen with the mouse cursor only on a black background, I have to kill this too as there's no way to exit (ALT+TAB does work however, it does not with Mame).



Also check this command out, 'eselect mesa list' and possibly run eselect set <number> to switch from classic to gallium and back. (need to be root for this, sudo -s).  That looks interesting, just found that can be changed.

Update:
Looks like that command won't actually switch on the LiveCD since it's a read only file system.  I'll look at this more and see what the difference is exactly, and build an ISO with this switched to gallium possibly (odd because I thought it was defaulting to gallium, but seems to be classic).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 14, 2010, 03:10:04 pm
I'll keep testing. There's something I've seen, when the screen is black I still have the sync leds on in the jpac, so the mode switching is performed properly, it's just that it hangs after that. I've also tested glxgears and it propmts normal stuff to the console but shows starts a window with nothing inside, just a black background, I suppose there should be something showing there. Then when I kill that window I get the same error message in the console as when I do CTRL+C in the Mame case. If I do glxgears -fullscreen it just goes full screen with the mouse cursor only on a black background, I have to kill this too as there's no way to exit (ALT+TAB does work however, it does not with Mame).

Could this be due to the need of also specifying the target device inside OpenGL? I don't know if this make any sense at all, but I do use that stuff with DirectX. After all, having the same card, the only difference I can think about is the monitor part again...

Couple of things to try:

Try to turn off the hiscore patch, actually do that for now since there seems to be an odd bug in the SDL part of it and it messes with the OpenGL stuff
  /home/arcade/mame.ini -  disable_hiscore_patch 1

Try changing some of the opengl values in mame.ini, see if turning on filtering, or if turning off the -gl_notexturerect stuff
 


I've possibly done some stuff that might help, but still looking at this and also am going  to try to add the newest DRM/KMS page flipping support too.  That way the next update hopefully will be really a big step forward and I might figure some stuff out too by then. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 14, 2010, 06:43:12 pm
Hi bitbytebit,

I've been doing all kind of tests editing mame.ini, all opengl options I've imagined, filters, screen, turning off vsync, but the issue is still there. As you said, these eselect commands are failing for the readonly file system. I also have a problem with this version not being able to get in ldex when I try to activate eth0, it just gets stuck in a black screen after the config terminal exits and I have to turn off the machine. That also happens if I try to mount a drive. I believe this stuff with the drives, not the network, has been there from previous versions, and may be the reason that I haven't been able to mount a drive yet, but at the beginning I was confused with the other issues, if only I had more experience with this system I could provide you with better feedback. So I keep stuck with this, it could be something silly with my machine, though I never had a problem before, however these days hopefully I'm going to test this on the AVGA cab. As I can't get the network working nor plug a usb stick I can't send you the logs, I've copied by hand some of the output of switchres invoking mame.

Here it's reporting an audio error (btw I haven't been able to have audio working with any live-cd I have tested, not only arcade gentoo). This shouldn't be the cause, but just in case:

Audio: Start initialization
Audio: Driver is
Audio: Initialization failed. SDL error: No available audio device
output: unable to open output notifier file /tmp/sdl_out

[...]

OpenGL: VBO supported
OpenGL: PBO supported
OpenGL: FBO supported
OpenGL: using vid filter: 0
GL texture: copy 1, shader 0, dynamic 1, 256x240 256x240 [PALETTE16, Equal: 0, l: 0, Palette, 1,
            scale 1x1, border 0, pitch 320,256/8192], colors: 2048, bytes/pix 4

... that's the end of the output, right after there it dies.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 14, 2010, 07:16:21 pm
Hi bitbytebit,

I've been doing all kind of tests editing mame.ini, all opengl options I've imagined, filters, screen, turning off vsync, but the issue is still there. As you said, these eselect commands are failing for the readonly file system. I also have a problem with this version not being able to get in ldex when I try to activate eth0, it just gets stuck in a black screen after the config terminal exits and I have to turn off the machine. That also happens if I try to mount a drive. I believe this stuff with the drives, not the network, has been there from previous versions, and may be the reason that I haven't been able to mount a drive yet, but at the beginning I was confused with the other issues, if only I had more experience with this system I could provide you with better feedback. So I keep stuck with this, it could be something silly with my machine, though I never had a problem before, however these days hopefully I'm going to test this on the AVGA cab. As I can't get the network working nor plug a usb stick I can't send you the logs, I've copied by hand some of the output of switchres invoking mame.

Here it's reporting an audio error (btw I haven't been able to have audio working with any live-cd I have tested, not only arcade gentoo). This shouldn't be the cause, but just in case:

Audio: Start initialization
Audio: Driver is
Audio: Initialization failed. SDL error: No available audio device
output: unable to open output notifier file /tmp/sdl_out

[...]

OpenGL: VBO supported
OpenGL: PBO supported
OpenGL: FBO supported
OpenGL: using vid filter: 0
GL texture: copy 1, shader 0, dynamic 1, 256x240 256x240 [PALETTE16, Equal: 0, l: 0, Palette, 1,
            scale 1x1, border 0, pitch 320,256/8192], colors: 2048, bytes/pix 4

... that's the end of the output, right after there it dies.



Yeah I'm hoping the changes I made to the OpenGL compile might help, added some compile time options and if that doesn't work then might try older versions or something.  The drive/network stuff, black screen, might be better in the next version but not sure.   The audio issue sounds like your sound card might be one that Linux doesn't support or needs something special like firmware or another different type of configuration option.  That might be something solvable eventually with possibly looking at the logs more, but for now will worry more about the video output :) the audio device in SDL looks like it just doesn't see it, what kind of sound card is in the machine?

Good news is I have just gotten a running version of the newest Linux kernel working with the page flipping support enabled, with the line accuracy vsync now and it definitely looks nice.  It seems they enabled the vblank interrupts and are using them now, so that's a good thing but definitely need to figure out the video card support in general before can see that :/.

I'll have a new ISO build up in a few hours hopefully, or maybe tomorrow, and you can see how this new OpenGL compile and the newer DRM kernel act.  



Update:
Also this might help some, the Gentoo Linux handbook which basically is the Manual telling how to install/do about anything you need.  So may help at least as a reference when you see an issue, look the topic for it up of what generally is happening and it tells how to setup every aspect of a Linux/Gentoo system.

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1 (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 14, 2010, 07:38:44 pm
One thing I'm wondering, do we even need OpenGL to do the vsync for us if the actual Atom Bios and Kernel DRM layer through the X Server/Driver are following the vblank/sync?  It is one thing I don't fully grasp, how the vsync stuff worked but the page flipping on the actual radeon card wasn't active yet.  Now it is, and besides accuracy I'm wondering what else that gains for us.  Wondering if OpenGL was emulating what now should just be happening in X itself, had read something awhile back where someone said the right place to do it was in Xorg and that was being worked on and OpenGL was just making up for the lack of that.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 14, 2010, 09:58:12 pm
I'm uploading a new 32 bit version now, LiveCD32-Minimal-1.133-aff4e1c.iso (will take a few hours), and 64 bit one after that.  From what I can tell this page flip support is quite amazing because I had debugging on and it turned out with page flipping it was logging to the logfile every page flip.  Amazingly things were mostly ok doing that still, noticed only because the most intense games hit the CPU at 99%.  So if it could handle that type of abuse to a live CD setup, and seeing how the page flipping worked since it was logging every flip, seems pretty promising.

If this one still has issues with the OpenGL, will have to dig into what that texture part is it always gets stuck at.  That is something I've seen, same place when it was sticking on the non 8 line aligned vertical height.  Seems there might be some Mame/SDL specific OpenGL bug there or touchy part of code which for some reason your card is hitting and other odd tests I've done with mame have hit that too in the past.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 15, 2010, 01:10:42 pm
Thanks for the link, I'll have a look.

One thing I'm wondering, do we even need OpenGL to do the vsync for us if the actual Atom Bios and Kernel DRM layer through the X Server/Driver are following the vblank/sync?  It is one thing I don't fully grasp, how the vsync stuff worked but the page flipping on the actual radeon card wasn't active yet.  Now it is, and besides accuracy I'm wondering what else that gains for us.  Wondering if OpenGL was emulating what now should just be happening in X itself, had read something awhile back where someone said the right place to do it was in Xorg and that was being worked on and OpenGL was just making up for the lack of that.

Vsync is a low level feature. So in Windows, the scheme (as I understand it) should be the driver running in ring 1 directly dealing with hardware, so performing the actual low level stuff needed for vsync (doing a loop to read a hardware port for a given value, interrupts, or whatever is done today for vsync), then over that the DirectX/OpenGL layer providing the applications running in ring 3 (Mame) with methods to access those driver features. In Linux the scheme seems different and as I said I don't exactly know which different parts of the system are interfacing with hardware. However, it could be that the DRM was already supporting vsync, but not page flipping, that's a different thing. I believe page flipping is implemented by dynamically modifying the hardware offset that points to the start of framebuffer's video memory, so with next refresh the contents of the screen are completely modified without the need to perform a memory copy, therefore with zero overhead. Without page flipping, one could do vsync as long as the system provides with a method to read the vblank state, but would need to sit waiting there until that happens to quickly do a memory copy to vram before the electron beam reaches the top of the screen. On the other hand, without vsync, one could do page flipping, but would have tearing. So both things are used combined.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 15, 2010, 01:28:45 pm
Thanks for the link, I'll have a look.

One thing I'm wondering, do we even need OpenGL to do the vsync for us if the actual Atom Bios and Kernel DRM layer through the X Server/Driver are following the vblank/sync?  It is one thing I don't fully grasp, how the vsync stuff worked but the page flipping on the actual radeon card wasn't active yet.  Now it is, and besides accuracy I'm wondering what else that gains for us.  Wondering if OpenGL was emulating what now should just be happening in X itself, had read something awhile back where someone said the right place to do it was in Xorg and that was being worked on and OpenGL was just making up for the lack of that.

Vsync is a low level feature. So in Windows, the scheme (as I understand it) should be the driver running in ring 1 directly dealing with hardware, so performing the actual low level stuff needed for vsync (doing a loop to read a hardware port for a given value, interrupts, or whatever is done today for vsync), then over that the DirectX/OpenGL layer providing the applications running in ring 3 (Mame) with methods to access those driver features. In Linux the scheme seems different and as I said I don't exactly know which different parts of the system are interfacing with hardware. However, it could be that the DRM was already supporting vsync, but not page flipping, that's a different thing. I believe page flipping is implemented by dynamically modifying the hardware offset that points to the start of framebuffer's video memory, so with next refresh the contents of the screen are completely modified without the need to perform a memory copy, therefore with zero overhead. Without page flipping, one could do vsync as long as the system provides with a method to read the vblank state, but would need to sit waiting there until that happens to quickly do a memory copy to vram before the electron beam reaches the top of the screen. On the other hand, without vsync, one could do page flipping, but would have tearing. So both things are used combined.


Yeah from what I read it seems that it's like Windows and this give that hardware page flip support in the driver, with Mesa/OpenGL taking advantage of it with the current vsync ability through the SDL part of Mame.  So it basically I guess makes it a lot more efficient and avoid tearing even more than before. 

It's interesting with this oddity with vertical games now, the sides of the screen are full of garbage frame buffer stuff since it doesn't update that part I guess.  I'm looking deeper into the code to see if there's something Mame could do, while hoping the Alex guy from AMD will respond with good news and know how to fix it there.  Suspect it's some oversight in the page flip code, but it's interesting too because it makes sense from how page flipping works.  I wonder if it's an odd case of how mame does vertical games and only updates the game screen and the sides are kind of on their own.  I can see how that's definitely a performance improvement, would think the frame buffer would be able to keep itself clear on each page flip though without overhead, or maybe not.  Also that's making me look at the Mame code with OpenGL which is where you see the hangs, hopefully fixed in the latest ISO :) but am being cautious since I of course am just guessing and hoping the changes I made help it.  Figure if I really get to know that OpenGL code in Mame better it might help me find what could cause issues, probably look at the Mesa OpenGL code from there too.  Definitely interesting, I've been wanting to look at that since I did some of the hacking at the 1.3 SDL parts to get it working and did get somewhat familiar with how it works.  It's interesting that it stops at the texture copy stuff, which is something that some of those mame options say they change but not sure if it's that part it avoids.  Also seems that means it's trying some part of OpenGL your card/chip isn't wanting to do, might mean at a lower level the kernel driver isn't fully enabling it so maybe the newer kernel changes have a chance helping it from that aspect then.  Going backwards in Mesa versions seems like a last resort, so waiting for that, since it gets tricky doing that and still supporting the newer Xorg stuff which we need for vsync to work at all or page flipping.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 15, 2010, 01:57:50 pm
I'm burning the new 'minimal' version right now, will be testing in a while.

That garbage issue sounds like the buffer is not being cleared before it's used, maybe because the cleaning function invoked from Mame right after creating that buffer is not working any more due to the OpenGL version change (the buffer could not be ready yet when trying to clear it), I've seen similar issues with DirectX, I believe due to the small changes in behavior from version to version that make code that has always worked well stop working.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 15, 2010, 02:07:04 pm
I'm burning the new 'minimal' version right now, will be testing in a while.

That garbage issue sounds like the buffer is not being cleared before it's used, maybe because the cleaning function invoked from Mame right after creating that buffer is not working any more due to the OpenGL version change (the buffer could not be ready yet when trying to clear it), I've seen similar issues with DirectX, I believe due to the small changes in behavior from version to version that make code that has always worked well stop working.

I *think* I figured the garbage issue out (at least a work around if it is fixable at the kernel level), am compiling to test my theory.  I found that the screen clear only happens on screen resizes or vector games.  I'm not sure but am checking to see if putting that clear at the initialization fixes it.  It's non-changing garbage so seems only one single clear would remove if, if it cleared the entire screen and not just the visible area.  At least can kind of see something I think, but will be able to run tests quicker once I get mame compiled and then won't take so long per change in the source to hack around with it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 15, 2010, 02:46:03 pm
Well, something interesting. This version does not hang any more. It starts Mame normally, switches video mode, BUT: it runs incredibly slow, 5-6% of speed in all games. I've seen logs and it just the same than before but now the texture lines are for or five and it does not stop there any more. The input lag is so high I have to quickly press esc to get out, otherwise it gets stuck with the game running.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 15, 2010, 03:02:38 pm
Well, something interesting. This version does not hang any more. It starts Mame normally, switches video mode, BUT: it runs incredibly slow, 5-6% of speed in all games. I've seen logs and it just the same than before but now the texture lines are for or five and it does not stop there any more. The input lag is so high I have to quickly press esc to get out, otherwise it gets stuck with the game running.


Check if the /var/log/messages file has any information in it, may be over logging (or output of running 'dmesg').

I fixed the junk stuff on the frame buffer, it's quite interesting, I guess there's now an extra buffer and it's sort of triple buffering perhaps.  I had to increase the number of clear times from two to three, now it's fine (has to run a clear per buffer used I guess).
Code: [Select]
diff -ru --exclude=obj --exclude='*.rej' --exclude='*.orig' ../mame_u2_ga/src/osd/sdl/drawogl.c ./src/osd/sdl/drawogl.c
--- ../mame_u2_ga/src/osd/sdl/drawogl.c 2010-12-11 12:07:43.073333333 -0600
+++ ./src/osd/sdl/drawogl.c 2010-12-15 13:58:22.649966300 -0600
@@ -3225,7 +3225,7 @@
  sdl_info *sdl = (sdl_info *) window->dxdata;
 
  //FIXME: Handled in drawogl_window_draw as well
- sdl->blittimer = 2;
+ sdl->blittimer = 3;
 }

At least can include that fix now in the next ISO.



Definitely not part of the issue your seeing though, seems like an over logging issue but then again maybe something to do with the opengl still.


Also try to run `top` in a terminal window before running mame, see if there's anything eating the CPU that's running.  In top you can do Shift+P to see the CPU processes first, and 'q' to exit out of top. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 15, 2010, 03:31:03 pm
I forgot to say it runs fine with video soft option.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 15, 2010, 03:34:12 pm
I forgot to say it runs fine with video soft option.

How does glxgears run, does it do something similar?  How many FPS does it run at, and does it say it's locked to the refresh rate?  What is the Mesa version and OpenGL version it reports with glxinfo?  That at least will isolate it to either mame or OpenGL.

Seems like we're getting closer, and it will be interesting seeing if things run well on your other cab now with the AVGA card.  If so it'll mean there's probably something bad about the interaction between the current Mesa OpenGL and that specific card.  Although really odd because I went through again the logs you sent of mame startup and your card is identical to mine and even your mame startup, weird.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 15, 2010, 03:58:42 pm
glxgears says running synchronized to the vertical refresh. The frame rate should be approximately the same as the monitor refresh rate... but the glxgears window shows nothing but a black backgroud (should I see something inside that Window?) so I have to close it, and then it prompts the "X10 Fatal IO error 11 (resource temporarily unavailable)...

glxinfo says GLX version 1.4, 2.1 Mesa 7.10-devel

top shows processes running but pressing shift+p several times I can't see any of them using more that 2-3% of cpu.

That tripplebuffer behavior makes a lot of sense with page flipping so it seems this SDL Mame is still behind of current OpenGL implementations, could it be the issue?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 15, 2010, 04:13:33 pm
glxgears says running synchronized to the vertical refresh. The frame rate should be approximately the same as the monitor refresh rate... but the glxgears window shows nothing but a black backgroud (should I see something inside that Window?) so I have to close it, and then it prompts the "X10 Fatal IO error 11 (resource temporarily unavailable)...

glxinfo says GLX version 1.4, 2.1 Mesa 7.10-devel

top shows processes running but pressing shift+p several times I can't see any of them using more that 2-3% of cpu.

That tripplebuffer behavior makes a lot of sense with page flipping so it seems this SDL Mame is still behind of current OpenGL implementations, could it be the issue?

Interesting, so it's still the same issue but is pointing to Mesa/OpenGL just not playing well with the hardware for some reason.  I'm not sure about how the Mesa version plays into the mame version and also if older Mesa versions matter or not with the vsync and page flipping.  I suspect though older versions shouldn't matter as long as they work nicely with Xorg, although it's definitely a bit confusing since it's the same video card and I'm not sure what extra variable is changing how OpenGL reacts (or what could, maybe the mother board or processor perhaps, compile flags, SSE support or MMX type stuff).  The newer Gallium stuff probably won't work any better, I actually tried it here and it failed to run mame or glxgears, although not sure if possibly it was a build issue.  I'll look for more ideas, test an older Mesa version and see if it allows everything to work still and the newer Xorg likes it.  I guess it'll be interesting to see how the other AVGA card and cab act, so if I don't get something by then at least that'll hopefully show something if that card acts better.  Since it's a whole other GPU it's interesting to see, although definitely wondering what else on a Radeon card could change the behavior between ours.  Does your possibly have a different BIOS than mine, do you know what the specs are of the memory on it and stuff? 

Running `sudo grep drm /var/log/dmesg` might be interesting to see the specs of the card.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 15, 2010, 04:31:34 pm
I'll check that now. Mine is an Asrock Intel board, audio integrated, I think it might be something colateral, not the videocard.

UPDATE: Same as yesterday, the system gets stuck before loading ldex if I boot with the network cable, so I can't get the logs for you.
Something interesting however, when running dmesg after exiting Mame, the log is full lines saying "hda-intel: spurious response 0x0:0x0, last cmd=0x3f0012 (and similar ones).

Definitely tomorrow I'll test this with the other cab.

This is my motherboard:

http://www.asrock.com/mb/overview.asp?Model=4COREDUAL-SATA2%20R2.0 (http://www.asrock.com/mb/overview.asp?Model=4COREDUAL-SATA2%20R2.0)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 15, 2010, 11:20:01 pm
I'll check that now. Mine is an Asrock Intel board, audio integrated, I think it might be something colateral, not the videocard.

UPDATE: Same as yesterday, the system gets stuck before loading ldex if I boot with the network cable, so I can't get the logs for you.
Something interesting however, when running dmesg after exiting Mame, the log is full lines saying "hda-intel: spurious response 0x0:0x0, last cmd=0x3f0012 (and similar ones).

Definitely tomorrow I'll test this with the other cab.

This is my motherboard:

http://www.asrock.com/mb/overview.asp?Model=4COREDUAL-SATA2%20R2.0 (http://www.asrock.com/mb/overview.asp?Model=4COREDUAL-SATA2%20R2.0)


Odd, yeah the audio chip in that system just might not be a great one in Linux from what I can tell, but need to look at that some. 

I'm uploading an ISO to a new `Testing/' directory, as LiveCD32-MinimalNoMM-1.140-8757967.iso which has reverted Mesa and libdrm to earlier versions.  It's a stab at seeing if that makes any difference.  Right now I'm actually pushing them back forward in my tree and going to do some testing with the newer Mesa Gallium stuff.  That's because I have found something interesting, first the Alex guy from AMD seems to think that the newest Gallium branch would be the best.  So I tested and found that with that enabled as Gallium it seems to segfault in the r600g Mesa/DRM library when running Mame.  It doesn't do this for glxgears or other applications I suspect, it seems like either an SDL/Mesa or Mame/OpenGL issue going on.  It segfaults at the  shader code, same place as you see issues.  So that seems to tell me possibly in Mame all that code which sets up OpenGL shaders is somehow a bit buggy and the Gallium stuff triggers similar to what you've seen.   I'm just not sure why you can trigger it without Gallium enabled, but I'm thinking it's still related someway.  I am learning more about how the Gallium/Classic Mesa/OpenGL is setup, differences and there's a few different branches in GIT too (the main branch constantly is adding/changing by the minute, it's a quite active development, yet Alex says it's fine and I do sort of believe him). 

So when that ISO is done uploading, would be interesting to test it, just to see if reverting to the 7.9 branch of Mesa works instead of the 7.10 currently active development one. 

I'm compiling a debug build of mame and opengl with gdb on a LiveCD and am going to try to chase this segfault in mame from Gallium down, which I just get the feeling if that is fixed it might fix your issue too plus allow us to use Gallium which is supposed to be the recommended OpenGL branch/mode now.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 16, 2010, 11:19:18 am
I've finally tested the cd on the AVGA cab, and unfortunately can't get to the desktop there, it's quite similar to what I've been suffering in the other cab, with first mode switch I get a split screen, but can still see it thanks to jpac. Then the screen gets perfect when it loads the terminal for the setup menu, I go through the setup, but then, when it should display the lxde desktop, I get out of video (sync led off on jpac). I've tested first of all CGA + First VGA, but as it didn't work have also tried CGA + DVI, PAL + DVI, etc., without success. So we are still stuck in a previous stage with this cab, not being able to get to the desktop and test opengl. However, I can go to the console pressing CTRL + F1, and I've taken a picture of the screen, in case it could be useful (have a look at the line "disable primary dac", should that be there?):

(http://img222.imageshack.us/img222/9743/16122010217.jpg) (http://img222.imageshack.us/i/16122010217.jpg/)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 16, 2010, 11:39:23 am
I've finally tested the cd on the AVGA cab, and unfortunately can't get to the desktop there, it's quite similar to what I've been suffering in the other cab, with first mode switch I get a split screen, but can still see it thanks to jpac. Then the screen gets perfect when it loads the terminal for the setup menu, I go through the setup, but then, when it should display the lxde desktop, I get out of video (sync led off on jpac). I've tested first of all CGA + First VGA, but as it didn't work have also tried CGA + DVI, PAL + DVI, etc., without success. So we are still stuck in a previous stage with this cab, not being able to get to the desktop and test opengl. However, I can go to the console pressing CTRL + F1, and I've taken a picture of the screen, in case it could be useful (have a look at the line "disable primary dac", should that be there?):

(http://img222.imageshack.us/img222/9743/16122010217.jpg) (http://img222.imageshack.us/i/16122010217.jpg/)

Try to specify the 'generic' monitor type on the setup.  Since the setup loads, it's running X fine at that point it seems.  It sounds like it's fouling up at using a h9110 modeline for the desktop.  So see if the generic one, which it's using to load in the first place, helps at all.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 16, 2010, 12:22:25 pm
Quote
Try to specify the 'generic' monitor type on the setup.  Since the setup loads, it's running X fine at that point it seems.  It sounds like it's fouling up at using a h9110 modeline for the desktop.  So see if the generic one, which it's using to load in the first place, helps at all.

It's already using the generic monitor (that's what it shows when loading stuff), ah.. ok you mean to select that on the setup... However I think it's not that, it's the connection issue again, I have no video, not a bad modeline. I'm pretty sure this is the same I was seeing before with the other cab, before you fixed it somehow, I was also seeing the setup but not the desktop. Something strange: I can see there VGA-0 and VGA-1 though the second connection should be DVI.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 16, 2010, 12:28:38 pm
Quote
Try to specify the 'generic' monitor type on the setup.  Since the setup loads, it's running X fine at that point it seems.  It sounds like it's fouling up at using a h9110 modeline for the desktop.  So see if the generic one, which it's using to load in the first place, helps at all.

It's already using the generic monitor (that's what it shows when loading stuff), ah.. ok you mean to select that on the setup... However I think it's not that, it's the connection issue again, I have no video, not a bad modeline. I'm pretty sure this is the same I was seeing before with the other cab, before you fixed it somehow, I was also seeing the setup but not the desktop. Something strange: I can see there VGA-0 and VGA-1 though the second connection should be DVI.


Ah, possibly in your home /home/arcade/ directory there's a file, .xinitrc, and in there remove the line referencing /usr/local/bin/outputs.pl
which may be causing the issue I *think*.  Also are you choosing the VGA menu option for that cab, suspect it'll need to go out only on that
first VGA connection on the AVGA which is what the second option chooses.  Although that script is part of the problem possibly too, but both
issues may be connected.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 16, 2010, 12:50:35 pm
Yes, I'm using the VGA option at the boot menu, also tested the others just in case. So I suppose I should CTRL + F2 and from there kill the desktop somehow (?), edit .xinitrc and restart the desktop (fvwm?).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 16, 2010, 12:54:27 pm
Yes, I'm using the VGA option at the boot menu, also tested the others just in case. So I suppose I should CTRL + F2 and from there kill the desktop somehow (?), edit .xinitrc and restart the desktop (fvwm?).

Actually an easier way would be to change in while in setup.  Basically right when it asks you the monitor type, open another xterm and edit that .xinitrc file to not include that outputs.pl line.  Then go ahead and choose the monitor type, then it should hopefully all startup without it, since running it at all may be a bad thing.  Otherwise you could from the second console edit it, and run `killall xinit`, or switch to the first console and push Ctl+C from there.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 16, 2010, 03:23:26 pm
It's interesting because I'm isolating an issue at the point where it hangs for you, or gets slow at least.  It's weird because it happens when I enable Gallium, it segfaults at the exact point yours either hangs or gets slow/screen goes black (on the 4350 at least).  I'm getting my liveCD build in a test mode with all the layers of mame->sdl->opengl->dri to have symbols and able to debug/backtrace on them.  I have gotten a backtrace up through mame but it didn't have enough symbols to show me more than the function names in the OpenGL libraries in Mesa for the r600g.so module being the culprit.  I hopefully can pinpoint this, I get the feeling if it's fixed and Mesa can use Gallium then things might just work well for you on the 4350 as well as we would be able to use the actively developed Mesa code (classic is depreciated now). 

So I am close I think to getting a backtrace today, possibly filing a bug on the drm lists if I don't figure out how to fix it myself.  Hopefully leads to the 4350 and Mame working even better, since it works for me in Classic mode but I suspect what your seeing and what I am seeing with Gallium enabled points to something touchy and unstable in there somewhere.  It's taking awhile, but I am seeing why finally, this whole Mesa OpenGL/SDL and Mame combination is quite a beast and then add the drm library with kernel mode KMS and Xorg drivers.  It's just a large amount of layers there having to work together, and all very new as of the last 6 months basically.  It'll be worth it because they've made great improvements, which I've seen here, but seems getting this all stable and working on all cards in a 'set' with mame utilizing all of the layers is going to take some time.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 16, 2010, 05:35:18 pm
It will be interesting to have those logs working to figure what's going on. By now I can't use the network so if it's necessary I'll take pictures of the monitor to show you the messages :)

Well, I've doing some tests with the AVGA cab. Removing the /usr/local/bin/outputs.pl line has worked! I did it before selecting h9110 in the setup, then the desktop loaded perfectly. And finally could run glxgears and see the gears moving! So ironically the new stuff is working better on the 9250 than on the 4350. But when I run mame (through switchres) the mode switching was not working, instead the 256x240 frame was showing as a small box on the left top corner on the desktop, the game running perfectly however, and then, when exiting, the whole desktop is set to 256x240. I imagine this is a side effect of removing outputs.pl, and it should be working otherwise (provided the video was on, of course) as I see an error message when exiting Mame saying it can't get back to 640x480, and xrandr --current says both VGAs are disconnected. I've also tested the noMM iso here and it's the same with it. So it could a matter of modifying outputs.pl somehow to still have video and xrandr working again. It's remarkable that the console video mode still doesn't work with this card, it's outputing 31 Khz there, something that is definitely fixed on the 4350.

Back with the 4350, I've tested noMM iso with exactly the same results I had with the new one yesterday, so going to a previous version does not fix things. However, I've seen something interesting today, that was indeed there also yesterday, but I didn't report it as it was so strange I thought it was an error with my tests. When the desktop loads for the first time, I go to the terminal and run switchres gridlee, the screen goes black and I have to CTRL+C to go back to the desktop. It's the second time I run switchres from the terminal when the game actually loads, but I get that slooow frame rate of 2-3%. So it needs to get hang a first time to be able to run later, but something must result corrupted when exiting with CTRL+C that somehow allows it to run later but very slow... glxgears still shows a black window and have to CTRL+C it also to exit. Mode switching however works flawlessly with this cab.

It would be good to have more people testing this to check with other machines also. I'm starting to think that the new kernel could have some troubles dealing with my motherboard, as I have also those other strange problems with the integrated network card, and of course the audio chip, and maybe that's making the system fail somehow. I could try to trace back the problem because I was actually able to use the network before, but haven't been anymore since some versions ago.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 16, 2010, 05:51:56 pm
It will be interesting to have those logs working to figure what's going on. By now I can't use the network so if it's necessary I'll take pictures of the monitor to show you the messages :)

Well, I've doing some tests with the AVGA cab. Removing the /usr/local/bin/outputs.pl line has worked! I did it before selecting h9110 in the setup, then the desktop loaded perfectly. And finally could run glxgears and see the gears moving! So ironically the new stuff is working better on the 9250 than on the 4350. But when I run mame (through switchres) the mode switching was not working, instead the 256x240 frame was showing as a small box on the left top corner on the desktop, the game running perfectly however, and then, when exiting, the whole desktop is set to 256x240. I imagine this is a side effect of removing outputs.pl, and it should be working otherwise (provided the video was on, of course) as I see an error message when exiting Mame saying it can't get back to 640x480, and xrandr --current says both VGAs are disconnected. I've also tested the noMM iso here and it's the same with it. So it could a matter of modifying outputs.pl somehow to still have video and xrandr working again. It's remarkable that the console video mode still doesn't work with this card, it's outputing 31 Khz there, something that is definitely fixed on the 4350.

Back with the 4350, I've tested noMM iso with exactly the same results I had with the new one yesterday, so going to a previous version does not fix things. However, I've seen something interesting today, that was indeed there also yesterday, but I didn't report it as it was so strange I thought it was an error with my tests. When the desktop loads for the first time, I go to the terminal and run switchres gridlee, the screen goes black and I have to CTRL+C to go back to the desktop. It's the second time I run switchres from the terminal when the game actually loads, but I get that slooow frame rate of 2-3%. So it needs to get hang a first time to be able to run later, but something must result corrupted when exiting with CTRL+C that somehow allows it to run later but very slow... glxgears still shows a black window and have to CTRL+C it also to exit. Mode switching however works flawlessly with this cab.

It would be good to have more people testing this to check with other machines also. I'm starting to think that the new kernel could have some troubles dealing with my motherboard, as I have also those other strange problems with the integrated network card, and of course the audio chip, and maybe that's making the system fail somehow. I could try to trace back the problem because I was actually able to use the network before, but haven't been anymore since some versions ago.


Yeah on the AVGA card I suspect it's not getting the input names right, it's odd because on boot up not going into 15khz mode says it probably is labeling the VGA input different, maybe VGA-2 instead of VGA-1 or something.  The outputs.pl script would normally turn off extra outputs, and try to enable the first one or VGA-0 (in xrandr, which is equivalent to VGA-1 for DRM kernel stuff).  I think the outputs must be oddly setup in the vbios on the AVGA card and it's abnormal, where the first input physically might not be the first one xrandr sees.   You could try the other output, and VGA then DVI mode and see if either work with outputs.pl enabled, also same with how it is now if you haven't trying DVI on it just to see.  I suspect logs would point closer to what is going on, mainly 'xrandr --current' output and the /var/log/dmesg output and/or dmesg output to see what the inputs are being mapped to on that system compared to the 4350 (maybe use an older version to see that?).  I suspect that the network/audio issues may be the kernel I'm using, hopefully they push out 2.6.37 soon and get some 2.6.38-rcX versions which are really meant for public consumption.  I am hoping that the 2.6.38 kernel is the one that we can hold at when it's released and wait till normal version changes come out after that.  They just keep fixing little DRM issues here and there right now inbetween 2.6.36 and 2.6.38, some not in 2.6.37 release candidates. 

I did get a good debug trace though, and filed a report here...

https://bugs.freedesktop.org/show_bug.cgi?id=32455

I suspect it's like what your seeing on the 4350 possibly but it just doesn't crash in your case, but there may be something Mame is doing wrong with the OpenGL buffers it passes.  It at least looks like the first one is NULL and in Gallium it crashes, in Classic it might just depend on the system state and on your it gets stuck while mine it acts just fine unless I use Gallium.

I'm going to go over that outputs.pl script some and figure out what I can improve with it, but I think it'll work if we got the right input specified at the grub command line.  If your able you could try to edit the grub command line and try VGA-2 and see if that works.  I think it might be calling DVI-I-1 VGA-1 or something odd like that.  The part about both being VGA outputs and saying they are disconnected is definitely interesting, it sounds like the one we are forcing enabled at bootup isn't the ones your seeing, and of course to force enabled at bootup we can only do one or else all are enabled then it goes haywire with all interfaces though to be connected.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 16, 2010, 06:08:55 pm
Looking at your pictures, I am now guessing that it is VGA-1 in xrandr and VGA-2 in the DRM layer/bootup which are the first output, and so it's not able to force VGA-1 on for the DRM layer and in Xorg not knowing which to choose possibly for the mode switching. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 16, 2010, 06:24:40 pm
Looking at your pictures, I am now guessing that it is VGA-1 in xrandr and VGA-2 in the DRM layer/bootup which are the first output, and so it's not able to force VGA-1 on for the DRM layer and in Xorg not knowing which to choose possibly for the mode switching. 

Yes could be that, will it work if I edit the files in the iso before burning it? However I'm not sure how to modify that outputs.pl to point to the other output.

I've been reading a bit about the drm thing, I imagine it could be possible to patch that in order to provide the drm layer with a fake EDID for arcade monitors, it theory that would avoid the need of forcing displays as it would think it's autodetecting a monitor, even if plugged to the secondary device. And the EDID could provide the drm with the proper arcade modelines.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 16, 2010, 06:33:50 pm
Looking at your pictures, I am now guessing that it is VGA-1 in xrandr and VGA-2 in the DRM layer/bootup which are the first output, and so it's not able to force VGA-1 on for the DRM layer and in Xorg not knowing which to choose possibly for the mode switching. 

Yes could be that, will it work if I edit the files in the iso before burning it? However I'm not sure how to modify that outputs.pl to point to the other output.

I've been reading a bit about the drm thing, I imagine it could be possible to patch that in order to provide the drm layer with a fake EDID for arcade monitors, it theory that would avoid the need of forcing displays as it would think it's autodetecting a monitor, even if plugged to the secondary device. And the EDID could provide the drm with the proper arcade modelines.


Possibly editing the Grub command line, I think you can push 'c' at the menu for grub and it'll let you edit it (says at the bottom of grub menu).  Then the outputs.pl script might still have to be removed for now, I'll have to redo that or remove it all together possibly.

The EDID thing is confusing to me though because how would you know it's an arcade monitor since it just basically says it's found a monitor without an EDID or in the Jpac case it probably doesn't even see the monitor at all.  So you'd never know which one is the right one to choose, since I am guessing only the EDID and general signal like the Jpac happens to remove are how it could detect connected monitors.  So it's definitely a big trickier than I even though I guess, knowing which input is used and adjusting for backwards ones on the AVGA, and then to know what resolution to use plus not knowing if a person would even see the grub menu in most cases.  I'll have to think about that more, is there any way at all that we could detect a monitor in a Jpac mode besides just guessing the first input is working?  Basically my patches do similar to what your saying but don't give it an EDID but have them hard wired into the kernel as modelines for inputs we tell it are arcade monitors (and the force enable switch with that for Jpac).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 16, 2010, 06:52:39 pm
Of course I mean to do this for a dedicated arcade distribution, where you instruct people using it to plug their monitors to the VGA output, whatever it is the first or the second device, so you wouldn't need the grub menu, we would intercept the point where the DRM is reading the VGA DDC (we can know its the VGA from the DRM labels) and if it doesn't find it, feed the thing with a fake arcade EDID, with some basic CGA modelines to go though the startup until we load X Windows and use xrandr. It's the same you are doing but might help to sort the different outputs issue. I don't mean it would be easy to insert that there, but I believe it shouldn't be too hard to implement an EDID structure.

UPDATE: I just remembered there're cards with both DVIs as outputs...anyway.


BTW...

Quote
I think the outputs must be oddly setup in the vbios on the AVGA card and it's abnormal, where the first input physically might not be the first one xrandr sees.   You could try the other output, and VGA then DVI mode and see if either work with outputs.pl enabled, also same with how it is now if you haven't trying DVI on it just to see.

The 9250's I'm testing second output is a digital only DVI, so I couldn't plug the arcade monitor to it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 16, 2010, 11:28:35 pm
Of course I mean to do this for a dedicated arcade distribution, where you instruct people using it to plug their monitors to the VGA output, whatever it is the first or the second device, so you wouldn't need the grub menu, we would intercept the point where the DRM is reading the VGA DDC (we can know its the VGA from the DRM labels) and if it doesn't find it, feed the thing with a fake arcade EDID, with some basic CGA modelines to go though the startup until we load X Windows and use xrandr. It's the same you are doing but might help to sort the different outputs issue. I don't mean it would be easy to insert that there, but I believe it shouldn't be too hard to implement an EDID structure.

UPDATE: I just remembered there're cards with both DVIs as outputs...anyway.


BTW...

Quote
I think the outputs must be oddly setup in the vbios on the AVGA card and it's abnormal, where the first input physically might not be the first one xrandr sees.   You could try the other output, and VGA then DVI mode and see if either work with outputs.pl enabled, also same with how it is now if you haven't trying DVI on it just to see.

The 9250's I'm testing second output is a digital only DVI, so I couldn't plug the arcade monitor to it.

I altered the outputs.pl script and also now have grub have first/second outputs options for both DVI and VGA, so on your AVGA card it should work
and outputs.pl should be able to tell now that it needs to enable VGA-1 only when VGA-2 is enabled on the grub command line.  Also am going to  do
some tests hacking at the Gallium OpenGL side of things with that issue I'm seeing since maybe it'll have more chance working well on the 4350 being
a complete rewrite of what hangs/gets slow currently.  I still think that mame probably is either causing the problem leaving the first buffer of the texture/shape it wants to render (it's a VBO I guess) empty.  I'm seeing if in the Mesa code checking for the NULL buffer and skipping it in those cases (at least avoid accessing it) allows things to work for mame. 

So hopefully next ISO will understand the AVGA cabinet properly and the outputs, when choosing the second VGA option, and will see if this Gallium stuff can actually work on my 4350 properly with some hacking.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 17, 2010, 02:07:34 am
I'm uploading version 1.151-eaaaed6 of the liveCD now, which will have options for the second VGA output.  Not sure if it'll make any difference on the 4350, but always worth a try of course, at least contains the mame buffer fixes and some other odds and ends.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 17, 2010, 03:38:44 pm
I've tested the new one with the AVGA, it works with SECOND VGA grub option (console is still at 31 kHz), desktop is ok (have you removed the outputs.pl from there?). glxgears works. But, switchres does not work now, it makes x windows get restarted. Unfortunately I haven't tested it with video soft, to see if at least mode switching was working, I will as soon as I can.

On the HD4350, the issue persists with glxgears not working and with switchres is the same as before, however I've tested with -video soft and it is working ok (btw, do we really need opengl for vsync or it can be also achieved by the soft option in Linux? it could be a provisional workaround). I've seen that we can also remove here the outputs.pl from .xinitrc and it still works the same, so that makes me think that once it's properly selected in grub menu and xorg.conf could it be enough?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 17, 2010, 03:55:55 pm
I've tested the new one with the AVGA, it works with SECOND VGA grub option (console is still at 31 kHz), desktop is ok (have you removed the outputs.pl from there?). glxgears works. But, switchres does not work now, it makes x windows get restarted. Unfortunately I haven't tested it with video soft, to see if at least mode switching was working, I will as soon as I can.

On the HD4350, the issue persists with glxgears not working and with switchres is the same as before, however I've tested with -video soft and it is working ok (btw, do we really need opengl for vsync or it can be also achieved by the soft option in Linux? it could be a provisional workaround). I've seen that we can also remove here the outputs.pl from .xinitrc and it still works the same, so that makes me think that once it's properly selected in grub menu and xorg.conf could it be enough?


Ah interesting, if it's crashing X Windows, then checking the /var/log/Xorg.0.log.old after that, mainly the end, might be helpful.  Sounds like somehow xrandr switching is crashing X Windows there.  It's still using outputs.pl but now it knows about the second output for VGA from the grub boot menu so working as it should it sounds like.  The outputs.pl script is good to keep the confusion from happening about having an extra normal monitor on the other output of the card since X Windows won't allow modeswitching then and will always use the compatible mode for both monitors (at least won't allow it to go out of range of the other monitor).  If you do a killall startup.pl a few times, then try switchres, then you'll end up at the console after the crash (which I guess is half screen still).  From there hopefully can see some messages on the console, and then can use `sudo -u arcade startx` I think to get back into X Windows without using process.pl.  I think any good information will be in /var/log/Xorg.0.log for that issue, and sounds like it's possibly the xrandr switching and the GPU code in the X driver for it.

Software switching wont work I guess because it's using the OpenGL interface into the card DRM to get to the ability to both vsync and page flip.  Seems like it's the only path to that from what I can tell.  I still am researching OpenGL though and sounds like Alex and the Mesa developers should eventually get to the bug with the backtrace I have in Gallium.  Hopefully Gallium provides a way to fix things.

Also test the AVGA and try to run mame without switchres and still all the same settings as under switchres, so we can possibly see if it's just xrandr directly giving an issue.  I can imagine that card with the altered BIOS could trigger some bugs in the ATOM code where they aren't expecting that cards BIOS and hardwiring settings possibly.  Seems that's most likely the issue I would think there, while the other 4350 probably is hitting a bug in the OpenGL Mesa stuff and similar to the Gallium issue.  Odd thing is with Gallium on mine glxgears works great, so it's odd and I thought that would be a Mame specific thing or something else Mame triggers that glxgears doesn't.  So that is interesting how glxgears goes really slow.  It actually is bad that they don't crash in some ways, because that sounds like it'd be useless to look at it with the gdb debugger then and get any back traces  after a crash.  If it did, then I do have the build with gdb, and gallium.  Another idea I guess is to try Gallium on the 4350 (and possibly the AVGA) and see if it acts any better (assuming the AVGA crash is Mesa related, which it's probably X driver xrandr related).  I might build a test build using Gallium for you to try at least on the 4350, since maybe it acts different and if it doesn't crash like mine then that is even a bigger mystery but might as well find out to see how odd this really is :).

Do you see anything in dmesg output about the network card issue?  The audio stuff might overload it so possibly looking though /var/log/messages would help.  Are they constant messages about it, try a `tail -f /var/log/messages` and see if it's continuously printing things about the audio issue.  It would be good if we eventually get the audio/net working, at least network for now, to be able to see more log information.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 17, 2010, 06:02:09 pm
I've tested the new one with the AVGA, it works with SECOND VGA grub option (console is still at 31 kHz), desktop is ok (have you removed the outputs.pl from there?). glxgears works. But, switchres does not work now, it makes x windows get restarted. Unfortunately I haven't tested it with video soft, to see if at least mode switching was working, I will as soon as I can.

On the HD4350, the issue persists with glxgears not working and with switchres is the same as before, however I've tested with -video soft and it is working ok (btw, do we really need opengl for vsync or it can be also achieved by the soft option in Linux? it could be a provisional workaround). I've seen that we can also remove here the outputs.pl from .xinitrc and it still works the same, so that makes me think that once it's properly selected in grub menu and xorg.conf could it be enough?


Try setting this 'gl_vbo 0' in mame.ini, see if that changes things on the 4350.  Also possibly try on the AVGA but not sure if that matters there.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 18, 2010, 06:55:08 am
I still can't get the network working on the 4350 cab, when I add the eth0 option and the setup ends the machine is completely hang. The gl_vbo option didn't help either.

But I've been digging it /var/log/messages and noticed something interesting:

GroovyArcade kernel: [   789.769052] [drm_mode_getfb] *ERROR* Invalid framebuffer id

Then when I check /var/log/Xorg.0.log it seems the above error comes right after this:

[  789.768] (II) GLX: Initialized DRI2 GL provider for screen 0

(well, it really happens right after the whole GLX: block of messages, that one being the last)

I'll check with the AVGA in a while.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 18, 2010, 07:44:13 am
I still can't get the network working on the 4350 cab, when I add the eth0 option and the setup ends the machine is completely hang. The gl_vbo option didn't help either.

But I've been digging it /var/log/messages and noticed something interesting:

GroovyArcade kernel: [   789.769052] [drm_mode_getfb] *ERROR* Invalid framebuffer id

Then when I check /var/log/Xorg.0.log it seems the above error comes right after this:

[  789.768] (II) GLX: Initialized DRI2 GL provider for screen 0

(well, it really happens right after the whole GLX: block of messages, that one being the last)

I'll check with the AVGA in a while.



I'm guessing this is a symptom from the Jpac issue, in the kernel it seems this means that the frame buffer isn't setup completely.  When we are forcing it on and it has no knowledge of the connection existing like with Jpac I guess it must not have anything ready for OpenGL to use.  I'm looking at it more, definitely very cool to have at least some lead, I suspect before when it was hanging there it was the same issue but looks like it was probably an oops or something in the kernel while now it's being a little more civil about it.  This may help actually find the code quicker that we need to fixup for making a Jpac type setup work.  I guess it needs to be hardwired completely to say the first monitor is an arcade monitor and setup all this stuff manually, that might be the way to do it.  I just have to learn how all the setup works, looks like this goes into the radeon part of the DRM instead of just the generic layer.  That's where it goes to either force or detect the DVI/VGA device.  So the individual drivers deal with that part, the force code just simply sets it as connected but the detection code does a ton of stuff.  What's odd, and indicates it's even somewhere else than that force setting, is that with force on mine it still works so it must be some more stuff done outside of the force setting where if it doesn't see the monitor connected it won't setup the frame buffer id structure correctly.

I solved the hiscore patch issue I had seen, there's a bug in the newest version it turns out and wasn't the SDL changes I made at all.  So will be able to enable that again fortunately, took me hours to track it down.  It was simply the placement of the init for it changed because mame changes moved it up and from that the call back for it to exit and save the score happened after callbacks to unload the game/rom cpu memory. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 18, 2010, 07:59:58 am
I still can't get the network working on the 4350 cab, when I add the eth0 option and the setup ends the machine is completely hang. The gl_vbo option didn't help either.

Are you able to access the machine before setup is complete, in theory it should be running eth0 already at that point (although I'm wondering now if that might not be happening).  I think I'm going to remove the stuff I'm doing to try and auto setup eth0 on setup, since it seems not to work and might actually be causing the issue with it not working for you and possibly hanging too.  That was for when we were not getting any console anyways and that's not the case anymore, so seems like it's not necessary anyways.  I think it might be tearing down the eth0 connection right after setup and then running into a problem when trying to restart it a second time.  If not that, then it might be a in-progress thing with the network driver for your card that'll most likely be fine by 2.6.38, since this linux-next kernel is the really bleeding edge development version.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 18, 2010, 10:38:42 am
I've been testing on the AVGA cab, first of all using -video soft doesn't make any difference, so it seems opengl is working ok here and it's the mode switching the one failing as you thought. Here are some parts of Xorg.0.log that might be interesting to figure things out. I'm not seeing the drm error in /var/log/messages here however:

(http://img543.imageshack.us/img543/6597/18122010233.jpg) (http://img543.imageshack.us/i/18122010233.jpg/)

(http://img716.imageshack.us/img716/2135/18122010234.jpg) (http://img716.imageshack.us/i/18122010234.jpg/)

(http://img228.imageshack.us/img228/1755/18122010235.jpg) (http://img228.imageshack.us/i/18122010235.jpg/)

(http://img210.imageshack.us/img210/7167/18122010236.jpg) (http://img210.imageshack.us/i/18122010236.jpg/)

(http://img413.imageshack.us/img413/7668/18122010237.jpg) (http://img413.imageshack.us/i/18122010237.jpg/)

Now this is the console after the X Windows crash. Have a look at the "X Error of failed request" here, as that one isn't prompted in the Xorg.0.log.old and could be the issue:

(http://img816.imageshack.us/img816/7338/18122010239.jpg) (http://img816.imageshack.us/i/18122010239.jpg/)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 18, 2010, 12:24:28 pm
LiveCD32-MinimalNoMedia-1.159-a2cc863.iso will be uploaded in a few hours and should be interesting to test on both, I'm hoping to get the network interface working again (if it's what I think it is that broke it).  It's not going to probably change anything with the OpenGL issues on the 4350 but might allow you to send me the dmesg output with the whole of the information around that error your seeing, which should be interesting and help hardwire the monitor in the kernel by seeing all the stuff it touches on setup.

The dmesg output may show something interesting, the Xorg log seems like everything is ok actually for the most part.  The other message though on the console is interesting because it shows that xrandr isn't getting anywhere trying to set things for the VGA-1 interface.  I suspect running xrandr commands in X would be interesting, possibly either crash it or show some kind of clue.

Hopefully can use the network to get logs again after this new ISO is uploaded, if so I would check what the 'xrandr --current --verbose` output shows you.  Also the dmesg output of that startup, and the /var/log/dmesg file to possibly go along with that to get the startup information for that card.  I guess X isn't revealing any information about the crash and just exiting, but the console dmesg might show you more info or /var/log/messages even.  It sounds like either the DRM layer or the X driver is hitting a bug that the AVGA bios triggers and just bailing out and crashing. 

I also commented out the output.pl script for now to see and I suspect we don't really need that script anyways since it's only if a person is connecting multiple monitors to try to do what simply connected the extra monitor would do anyways.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 18, 2010, 01:23:17 pm
I'll keep an eye on that.

It makes sense that this problem is happening here because of the jpac issue, that's the difference probably as the 4350 must be the same. These are the results by now:

4350: console video OK, X Windows OK, mode switching OK, openGL ERROR
9250: console video ERROR, X Windows OK, mode switching ERROR, openGL OK

So the error I'm seeing from drm with the 4350 that seems to be preventing openGL from working, could be due to the need of forcing outputs also inside the radeon driver code, and might be related to the other one with 9250 not being able to show proper video on the console and failing with mode switching for xrandr not properly addressing the outputs, despite openGL is not affected in that case. That makes me think that both cards initializations follow different paths in the radeon driver, as I think I've been seeing different stuff being prompted in each case, although not completely sure. Of course it could be that AVGA special bios is kind of confusing radeon drivers, but I'd like to think it's not that.

Hopefully this new version will have the network on to provide you with the logs. After some tests I'm slowly getting some rudimentary skill moving around this system and I had my hands tied up not being able to copy the files to my laptop.

BTW when doing tests with the 9250 I noticed this line in one of the logs (I believe it was Xorg.0.log):

[ 133.573111] i2x i2c-1: unable to read EDID block

Ah, I forgot to say that running mame only instead of switchres also crashed just the same.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 18, 2010, 01:47:06 pm

BTW when doing tests with the 9250 I noticed this line in one of the logs (I believe it was Xorg.0.log):

[ 133.573111] i2x i2c-1: unable to read EDID block

Ah, I forgot to say that running mame only instead of switchres also crashed just the same.


Do you see this reference in the /var/log/dmesg file or /var/log/messages?

radeonfb

I think I might know what is going on, possibly your card is supported by the old radeon framebuffer driver.  If it is detecting the card, it may be getting in the way of things on the AVGA cab.  I probably need to totally disable that I'm guessing, but hopefully with the newer ISO you can confirm it's really the culprit.  Didn't realize that could happen, it may be the issue it seems.

Does running mame with the -noswitchres option and not letting it do mode switching also crash it?


Also what does the output of:


cat /proc/fb


Look like?  does it say radeonfb at all or radeondrmfb?


Also another thing to try if it's using radeonfb, is to edit the grub boot prompt when booting and add this...

video=radeonfb:off

I think that will turn it off and allow KMS to take over.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 18, 2010, 01:57:24 pm
Do you see this reference in the /var/log/dmesg file or /var/log/messages?

radeonfb

I think I might know what is going on, possibly your card is supported by the old radeon framebuffer driver.  If it is detecting the card, it may be getting in the way of things on the AVGA cab.  I probably need to totally disable that I'm guessing, but hopefully with the newer ISO you can confirm it's really the culprit.  Didn't realize that could happen, it may be the issue it seems.

Does running mame with the -noswitchres option and not letting it do mode switching also crash it?

I'm almost sure I've seen that radeonfb name on the AVGA cab. So it was the messages file from where I took that one. However I won't be sure until I check it there, maybe tomorrow, the fact is that machine is in another house and I'm just going there for testing during half an hour or so and then leave.

Didn't check with the -noswitchres option, but I think it's not mame fault as I believe sznesw also crashed (not fully sure though).

But I am almost positive that I've seen different messages from both cabs, something that made me curious at. BTW could it be that it's using that other drive for pre-ATOM bios?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 18, 2010, 02:13:09 pm
Do you see this reference in the /var/log/dmesg file or /var/log/messages?

radeonfb

I think I might know what is going on, possibly your card is supported by the old radeon framebuffer driver.  If it is detecting the card, it may be getting in the way of things on the AVGA cab.  I probably need to totally disable that I'm guessing, but hopefully with the newer ISO you can confirm it's really the culprit.  Didn't realize that could happen, it may be the issue it seems.

Does running mame with the -noswitchres option and not letting it do mode switching also crash it?

I'm almost sure I've seen that radeonfb name on the AVGA cab. So it was the messages file from where I took that one. However I won't be sure until I check it there, maybe tomorrow, the fact is that machine is in another house and I'm just going there for testing during half an hour or so and then leave.

Didn't check with the -noswitchres option, but I think it's not mame fault as I believe sznesw also crashed (not fully sure though).

But I am almost positive that I've seen different messages from both cabs, something that made me curious at. BTW could it be that it's using that other drive for pre-ATOM bios?


I'm pretty sure that's what's going on, radeonfb is getting in the way.  I'll fix that, figure out the right way to disable it either not compiling it into the kernel or with grub.conf.  Will hopefully get a new ISO with that change to test, so the one I uploaded may be good to get logs from the 4350 with hopefully and logs from the AVGA and  possibly try the testing, but I do think that radeonfb is the whole issue and without it we might just have the AVGA working if that older card does ok with KMS (Which from what I can tell it's worked longer than the r600-700 gpu cards have).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 18, 2010, 02:39:29 pm
The fact is the one motherboard I have here is dual AGP PCIe so I don't know if I could plug an AVGA I have around also and have both cards on for testing, I suppose I should tweak something in the bios to select the one to boot with or something, but don't know if that will mess the system even more. However the main issue with this I suspect will be forniture related, as the space is so narrow on the shelf that it might not even fit.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 18, 2010, 02:42:04 pm
The fact is the one motherboard I have here is dual AGP PCIe so I don't know if I could plug an AVGA I have around also and have both cards on for testing, I suppose I should tweak something in the bios to select the one to boot with or something, but don't know if that will mess the system even more.


I'm hoping that the change I am making to the kernel should make it act right, I think it's just disabling the radeonfb module from compiling will do it.  Also am doing something which may allow the sound to work, so will see how that goes too.  Also possibly if we are lucky, I think the changes I made will kick the DRM KMS mode for the framebuffer right after the grub menu too.  I'm trying to compile that part in instead of being modules, should be nicer on bootup I hope.

It'll probably be about 8-12 hours before I get back, the kernels are compiled, and can test it and upload an ISO. I'm hoping I don't have to do another compile after that and it works with the changes, kernel compiling takes quite a while since it has so many modules in that generic kernel config I'm using.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 19, 2010, 03:29:19 am
I'm uploading LiveCD32-MinimalNoMedia-1.165-cf69349.iso right now which has improved the radeon setup in the kernel.  I removed all the extra framebuffer modules which are older depreciated ones, moved the whole radeon and DRM into the kernel itself.  So right after the grub menu it goes straight into 15khz output now so really happens pretty fast, and you in theory now could do the needed maintenence and emergency repair stuff on an arcade monitor (since it does 15khz immediately without accessing the file system.  It would be nice to get grub to do the same, but I am guessing that'll not be possible since it seems aimed at VESA modes. 

So this version should in theory work better with the AVGA, and hopefully the network works so the 4350 can get logs, the sound might work on there too since I built in the older OSS support too besides just ALSA which might be what your sound card needs. 

I've been looking at the kernel stuff for the issue with the invalid fb id for the 4350, at least am getting more familiar with it but still can't see where it is not allocating that.  It'll probably help to have the complete log output of where that message is, maybe even the startup dmesg from the /var/log/dmesg too.  So I can trace through those and figure out each part of the code it uses on startup and the difference when it doesn't think the monitor is connected.

Thanks,
Chris
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 19, 2010, 02:20:01 pm
I've tested 1.159 on the 4350 cab and the network still doesn't work (the system hangs). But I've managed to get the logs from there by formatting an usb pendrive with ext4 and copying the files there, the logs are attached. Hopefully there's some stuff there to start with. I also found the last version that had the network working for me, it was 1.02 32bit 12-10-2010_1291963428, so I also got the logs from there, it's interesting to notice that the drm error was not there at that point (??), however I've checked that opengl was crashing the system the same as now.

I've downloaded the new one, will test it soon.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 19, 2010, 02:24:05 pm
I've tested 1.159 on the 4350 cab and the network still doesn't work (the system hangs). But I've managed to get the logs from there by formatting an usb pendrive with ext4 and copying the files there, the logs are attached. Hopefully there's some stuff there to start with. I also found the last version that had the network working for me, it was 1.02 32bit 12-10-2010_1291963428, so I also got the logs from there, it's interesting to notice that the drm error was not there at that point (??), however I've checked that opengl was crashing the system the same as now.

I've downloaded the new one, will test it soon.

Sounds good, thanks, will look at the logs.  Also have gotten most of the cabmame patches to port (except sound sync of course) and not gotten changeres yet, so have the patch (not in the ISO yet) now basically almost the whole cabmame patch for both Windows/Linux and mame 140u2 (separate thread about cabmame in software is where I posted it, since people were wanting the cabmame patches for 140u2).  Also have a question about cleanstretch in there, since I got it ported better this time, but I now see an interesting difference between how it works in Linux vs. Windows because of the hwstretch Windows only option vs. the unevenstretch Linux option.

I'm thinking the network issue will be resolved most likely by 2.6.38, probably something in the -next branch of Linux they are refactoring or something.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 20, 2010, 05:01:09 am
Good news, 1.165 is working flawlessly on my Avga cab!!!!, I mean all of it (console, x windows, mode switching, opengl), have to set to First Vga. On 4350 it has the same issue still, but this is promising. Writting from a mobile phone, more on this later.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 20, 2010, 03:54:32 pm
Good news, 1.165 is working flawlessly on my Avga cab!!!!, I mean all of it (console, x windows, mode switching, opengl), have to set to First Vga. On 4350 it has the same issue still, but this is promising. Writting from a mobile phone, more on this later.
Sounds great, I was  hoping for that, now know it seems we are down to either a Mesa bug or J-Pac/DRM detection issue for the 4350.  I have a patch they DRM developers applied to Mesa which they say will fix the Gallium bug and allow us to try Mesa with Gallium which possibly will bypass/fix the bug on the 4350.  It at least will hopefully let us use Gallium, which should be better, and also I have emailed Alex more info and the messages log of what's happening and explained the J-Pac issue to him to see what his thoughts are.  Also I think I have a more stable kernel which may fix audio/networking, just need to test it.  Seems the drm-next branch probably is better since it's just as up to date with the DRM changes but the rest of the kernel is the more stable 2.6.37-rcX series.  Since it seems 2.6.38 won't be seen out till probably March 2011 I figure it's better to use drm-next, probably stick with that branch since it's actually ahead of the linux-next for DRM video cards but the rest is pretty much stable (and DRM stuff looks to be good at keeping stable in that branch).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 20, 2010, 04:59:43 pm
It's very nice how this new version shows 15Khz nearly from the beginning, and when using the AVGA its 15Khz all the time. Something interesting is that you need to use FIRST VGA with this kernel, so that explains how before it was not consistent as the radeonfb used different names than drm. So now it's FIRST DVI for 4350 and FIRST VGA for 9250. I've been testing glxgears, wahcade, and mame games and all is working fine, mode switching is just a pleasure to the eye. On the less good side is that I have no sound either with this motherboard (older asus) but as you say this may eventually be solved with the new kernel.

So I'm eager to test the new Gallium stuff to see if the only remaining bug on the 4350 is finally bypassed. Something I really want to do know is to test more roms than the included ones, so will try to mount the harddrive next time. Btw I formatted an usb pendrive and installed the system in it, however I was unable to boot from it (it justs prompts to press any key or something, couldn't see it properly). I think I followed the steps, setup grub in it and marked the partition with the 'boot' flag but of course I could be missing something.

There's a chance that grub could also show 15 KHz, but it would be necessary to do some low level stuff with the bios modes (interrupt capturing and that). Is grub code available? Is it 16-bits? A folk from the Spanish forums made a program called Boot15Khz that resides on the partition or boot sector and does that, so it is possible indeed.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 20, 2010, 05:09:56 pm
It's very nice how this new version shows 15Khz nearly from the beginning, and when using the AVGA its 15Khz all the time. Something interesting is that you need to use FIRST VGA with this kernel, so that explains how before it was not consistent as the radeonfb used different names than drm. So now it's FIRST DVI for 4350 and FIRST VGA for 9250. I've been testing glxgears, wahcade, and mame games and all is working fine, mode switching is just a pleasure to the eye. On the less good side is that I have no sound either with this motherboard (older asus) but as you say this may eventually be solved with the new kernel.

So I'm eager to test the new Gallium stuff to see if the only remaining bug on the 4350 is finally bypassed. Something I really want to do know is to test more roms than the included ones, so will try to mount the harddrive next time. Btw I formatted an usb pendrive and installed the system in it, however I was unable to boot from it (it justs prompts to press any key or something, couldn't see it properly). I think I followed the steps, setup grub in it and marked the partition with the 'boot' flag but of course I could be missing something.

There's a chance that grub could also show 15 KHz, but it would be necessary to do some low level stuff with the bios modes (interrupt capturing and that). Is grub code available? Is it 16-bits? A folk from the Spanish forums made a program called Boot15Khz that resides on the partition or boot sector and does that, so it is possible indeed.

Yeah Grub is GNU project available here: http://www.gnu.org/software/grub/ (http://www.gnu.org/software/grub/)
There's a newer version, and older which is the one we are using since that is what Gentoo uses currently and newer one requires some system changes.  It would be nice to get grub to use 15khz itself, the newer version does the actual vesa mode stuff, I don't think the older version does but I might be wrong.   I've also with the newer build have reduced the size considerably of the ISO images, they had gotten a bit of bloat and I figured out how to clean the uneeded stuff from them to slim them down a lot more.  Will have new ISO's up later tonight if Gallium works and include the newer kernel in them too hopefully.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 20, 2010, 06:15:59 pm
I've downloaded grub-0.97 source (is that the one?) to have a look. I stage2 folder, there's a file asm.S. I think it could be done by editing the function set_vbe_mode, so that right after the mode is set with int 10h we should reprogram it using the methods in arcmon.asm, which source can be downloaded here:

http://www.mameworld.info/pc2jamma/downutil.html (http://www.mameworld.info/pc2jamma/downutil.html)

I could do that for sure if it was plain assembly, but that c stuff in the middle of grub project neutralizes my powers, apart from the hell of trying to build that thing. But it seems possible indeed.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 20, 2010, 06:19:56 pm
I've downloaded grub-0.97 source (is that the one?) to have a look. I stage2 folder, there's a file asm.S. I think it could be done by editing the function set_vbe_mode, so that right after the mode is set with int 10h we should reprogram it using the methods in arcmon.asm, which source can be downloaded here:

http://www.mameworld.info/pc2jamma/downutil.html (http://www.mameworld.info/pc2jamma/downutil.html)

I could do that for sure if it was plain assembly, but that c stuff in the middle of grub project neutralizes my powers, apart from the hell of trying to build that thing. But it seems possible indeed.
Oh cool, I can definitely handle the C side, assembly wise I'm probably useless :).  That's the version in Gentoo, that we are using.  I can will look at the source and the link you sent, sounds neat.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Gray_Area on December 20, 2010, 08:13:08 pm
Having followed this thread a bit, and gotten a bit lost in the details - again, what are you trying to attempt here?...and what is your overall progress?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 20, 2010, 09:03:43 pm
Having followed this thread a bit, and gotten a bit lost in the details - again, what are you trying to attempt here?...and what is your overall progress?

We are trying to utilize the full potential of an arcade monitor for refresh rate exactness (to drive the game by that if possible, so avoid tearing at least expense of the system by following the video cards vsync interrupts), and general resolution/modeline duplication (similar to what Advanced Mame did/does but in a way that uses the systems native methods like the registry and xrandr in Linux, so we are able to keep it up to date and have it be more transparent and separate from Mame).  We want to do this equally well in both Linux and Windows, basically no limited modeline counts. 

So far the progress is, in Linux things are pretty much perfect if you have most Radeon cards, although there's some issues in the OpenGL side stopping certain ones from working.  I have a d9800 and can run everything just about perfect vsync and hxw, no throttle and no tearing or sound slowness or fastness. 

So far in Windows we have gotten the ability on the Radeon/ATI driver/cards to do about the same within limits of 60 predefined hxw combinations but we can dynamically rewrite those modelines to change the refresh rates to what we need (so mostly all games will be able to do the same as in Linux, but there's really 100 or so hxw modelines needed to match Linux with a few exceptions, possibly 160 or so to do just about the exact same in Windows).

Also out of this there's a Linux cabmame version able to utilize arcade monitors, same patches, plus it works in 140u2 for Windows too, extra benefit to help our goal of running full potential of arcade monitors there.   

So basically the ATI radeon drivers in Windows can eventually be patched to hold the needed 160 custom modelines, Calamity is working on that.  Would be nice to dynamically load modelines in all drivers for Windows, I'm not sure if that'll happen unless people figure out how to patch them (The ATI one seems to just do it with certain API calls done with it). 

In Linux we need to expand into other cards besides ATI Radeon ones, although the other drivers in Linux not as matured as the ATI DRM one currently (Nvidia and Intel ones *might* work though, untested).  Also figure out these OpenGL issues, in Linux it's best to build a distribution to do all this because it requires patches to the system and very new code they are just releasing combined with just the right build options and setup.  So we've done that, and it's working quite well besides rough edges and the compatibility.  We seem to be now figuring out some things about J-Pac support, there's a few issues there with driving it correctly since the system can't really sense the monitor so the issues are probably due to that.

Also of course the modeline generation of SwitchRes is quite nice and probably the best out there of any modeline generator for Arcade monitors, which was at first the main goal but it turns out to get those modelines to work on systems you have to do all the other work too.  Fortunately we have Soft15khz to do the registry setup of modelines in Windows for us to dynamically modify, and in Linux the DRM KMS kernel work and xrandr to push the modelines into work there. 

It's quite a list of stuff we want to do because of the goal of the full potential (arcade monitors and radeon cards, and others, in theory should be able to really get perfect display on a d9800, and near perfect for a lot of games on other monitors, which that hasn't ever been exploited before this), but we've done a lot too at the same time so that if you have a radeon card and arcade monitor both Windows and Linux have increased capability at display on arcade monitors with exact vsync within the monitors physical limitations.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 20, 2010, 09:16:04 pm

So I'm eager to test the new Gallium stuff to see if the only remaining bug on the 4350 is finally bypassed. Something I really want to do know is to test more roms than the included ones, so will try to mount the harddrive next time. Btw I formatted an usb pendrive and installed the system in it, however I was unable to boot from it (it justs prompts to press any key or something, couldn't see it properly). I think I followed the steps, setup grub in it and marked the partition with the 'boot' flag but of course I could be missing something.

Got a response back from Alex about the 4350 and J-Pac, he says try it with the env variable vblank_mode=0 (run `export vblank_mode=0` in xterm and then run glxgears or switchres).  Of course this avoids using the vblank interval, but still uses OpenGL, and at least would point out I guess the possible issue.  He says it might not work well for the vblank because of it running through J-Pac it can't see the monitor I guess, here's his full response.  I'm guessing there would still be a way around this, hopefully...
Quote
                  The connector stuff doesn't have any bearing on the accel code per se.
                   If you see a console or X, then the display side is fine even if you
                   have to force the display.  I suspect the black screen and slow issues
                   are due to vblank interrupt issues.  Most GL apps enable vsync by
                   default which may be problematic on jpac or on interlaced displays.
                   Try setting the env var vblank_mode=0 before starting a 3D app and see
                   if it helps.



Update: Also I tested this and it seems that vblank_mode=0 still allows the waitvsync option to work with nothrottle for mame, so I guess this isn't a bad thing if it works.
New kernel with drm failed with some bugs in memory and cdrom access being buggy, so I'm going back to the old one but I might have found the eth0 network issue oddly tied to the xorg-server for some reason and it not restarting X after config.  I'm testing a previous version of the xserver, that might be what changed and started the issue, also audio might be actually me not setting the mixer to unmute for the right card number.  Test possibly with running `alsamixer` and see if you can toggle cards and check, I now am unmuting 0-3 to be extra safe and that might help I hope. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 21, 2010, 04:26:26 pm
It's very nice how this new version shows 15Khz nearly from the beginning, and when using the AVGA its 15Khz all the time. Something interesting is that you need to use FIRST VGA with this kernel, so that explains how before it was not consistent as the radeonfb used different names than drm. So now it's FIRST DVI for 4350 and FIRST VGA for 9250. I've been testing glxgears, wahcade, and mame games and all is working fine, mode switching is just a pleasure to the eye. On the less good side is that I have no sound either with this motherboard (older asus) but as you say this may eventually be solved with the new kernel.

So I'm eager to test the new Gallium stuff to see if the only remaining bug on the 4350 is finally bypassed. Something I really want to do know is to test more roms than the included ones, so will try to mount the harddrive next time. Btw I formatted an usb pendrive and installed the system in it, however I was unable to boot from it (it justs prompts to press any key or something, couldn't see it properly). I think I followed the steps, setup grub in it and marked the partition with the 'boot' flag but of course I could be missing something.

There's a chance that grub could also show 15 KHz, but it would be necessary to do some low level stuff with the bios modes (interrupt capturing and that). Is grub code available? Is it 16-bits? A folk from the Spanish forums made a program called Boot15Khz that resides on the partition or boot sector and does that, so it is possible indeed.


I'm uploading this version LiveCD32-MinimalNoMedia-1.191-9cdbada.iso which has hopefully fixed the network interface issue, maybe fixed audio, and now has a 'CD Acceleration' program under the Preferences menu.  The setting for vblank can be turned off there globally without setting the env variable, which when you test will be interesting to see if that fixes OpenGL on the 4350 with J-Pac.  You can also tune all the other settings for OpenGL in that program, which might be interesting to fiddle around with it and see if anything works.  The way the whole login and setup works has been improved, a large change which should avoid the weird network interface issue (seemed to be an interaction of the startup.pl script and X startup while setting up the network, all that doesn't happen anymore and startup.pl runs then exits and lets GDM take over after that to run X Windows).

I've been looking at the assembly in Grub and that program, definitely interesting and the assembly is quite crazy looking but at least it  shows it is possible.

The Gallium bugs are being worked on, they now have it run without a crash but it's a black screen for mame yet the game runs normal.  So I guess it's improving, although there's definitely something really weird going on and I wonder if it's possibly something Mame is doing, basically there's always a NULL buffer in the vertix buffers for the first one it seems.  Not sure why Gallium would suddenly find it, maybe it's Gallium, hopefully they figure more out.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 21, 2010, 04:35:16 pm
We hit the target now. With my HD4350, it works either with vblank_mode=1/0, fails with 2/3 (don't know what the default is, but could be 2 or 3?). gxlgears works, swithcres works. However there's indeed a problem with waitvsync when doing so. It's not vsynced actually, page flipping does work as there's no tearing and background flash lights in some games are solid, but the prompted fps doesn't match the target ones at all, it fluctuates around, so something is missed there when disabling vblank_mode. I believe that value must be on for things to work, but for some reason my video card + jpac combination is failing with it. I've found that the 3-4% fps I was getting before only happens when I press F11 to print the speed, and it also gets stuck when pressing tab for the osd, so it seems that the new page flipping is conflicting with Mame propting stuff on the screen for some reason, are you seeing this also?

I've run alsamixer and found that it's detecting two sound devices on my cab, the actual VIA integrated audiocard (1) and the hdmi audio part of the HD4350 (0). I can't toggle anything  but volume with this program I believe. In fact the VIA audiocard shows it's volume and everything is on ok, and the other one seems off. However in console 1 I'm getting this message:

ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 21, 2010, 05:23:31 pm
We hit the target now. With my HD4350, it works either with vblank_mode=1/0, fails with 2/3 (don't know what the default is, but could be 2 or 3?). gxlgears works, swithcres works. However there's indeed a problem with waitvsync when doing so. It's not vsynced actually, page flipping does work as there's no tearing and background flash lights in some games are solid, but the prompted fps doesn't match the target ones at all, it fluctuates around, so something is missed there when disabling vblank_mode. I believe that value must be on for things to work, but for some reason my video card + jpac combination is failing with it. I've found that the 3-4% fps I was getting before only happens when I press F11 to print the speed, and it also gets stuck when pressing tab for the osd, so it seems that the new page flipping is conflicting with Mame propting stuff on the screen for some reason, are you seeing this also?

I've run alsamixer and found that it's detecting two sound devices on my cab, the actual VIA integrated audiocard (1) and the hdmi audio part of the HD4350 (0). I can't toggle anything  but volume with this program I believe. In fact the VIA audiocard shows it's volume and everything is on ok, and the other one seems off. However in console 1 I'm getting this message:

ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave

It does fine here with the OSD, I'm guessing it is what Alex was talking about and  seems that it won't run without vblank/sync set differently or off (or fixed timing I think) and that doesn't allow it to perfectly match the game.  I do actually see that part here when turning off vblank, I thought it was not acting as smooth but it didn't tear and was able to run with nothrottle.  So at least we have some sort of insight into what is happening, seems that a J-Pac setup doesn't allow the radeon DRM stuff to activate using the cards interrupts to match the blanking of the monitor.  I think that makes sense too, it's just odd though and would think there's a way around this somehow.  I'll tell Alex what we've found, also the newer ISO will have that DRI utility which actually labels what each of those values are so you'll be able to know exactly what the meaning is of the ones that work and ones that don't. 

They basically have:
* Never synchronize with vertical refresh, ignore applications choice
* initial swap interval 0, obey applications choice
* initial swap interval 1, obey applications choice
* Always synchronize with vertical refresh, application chooses the minimum swap interval

I think those are in order from 0 - 3, and default is probably 3 I think.  I would think they could figure out a way to make this work on J-Pac, you might have more insight though than me on how the monitor/video card work together (or if they really actually need to) for knowing when a vblank occurs and how to implement this vblank stuff properly even if the monitor can't be seen (or is that even possible, can windows really do this, how does it get by if it does).

My laptop I am testing the basic interface on also has sound card issues, I think it's because it's trying to use the HDMI output.  Try this, make a .asoundrc file in the /home/arcade/ directory with this in it...

Code: [Select]
pcm.!default {
type hw
card 1
}

ctl.!default {
type hw
card 1
}

Here's a page talking about this more, can also try aplay -l to see all cards and know what number to use above.

http://www.linuxquestions.org/questions/slackware-14/no-sound-with-flash-player-in-firefox-after-adding-nvidia-gt-220-graphics-card-809773/ (http://www.linuxquestions.org/questions/slackware-14/no-sound-with-flash-player-in-firefox-after-adding-nvidia-gt-220-graphics-card-809773/)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 21, 2010, 06:00:41 pm
Vsync is working smoothly in Windows with this same card, so it's possible indeed. As for the jpac, I am almost sure it was vsynced yesterday with on AVGA card (jpac also there). So this sounds as one of those new EDID philosophy 'features' of newer cards related to not feeling monitors, as the one of turning off video, vsync support might be internally disabled. Technically vsync is something internal to the videocard, as it's the videocard the one driving the electron beam, not the opposite, so it's the card who knows when it's sending its vblank signal, so the jpac should not matter here unless the driver is designed to do so.

I'll keep testing with the new iso and all those options.

Btw I think it's highly possible that I can do the assembly patch for grub, provided it works as I think it does and you can build it later, so I won't be able to test it here. By now it will need to be fixed to plain text mode (mode 03h) but it will be enough for a menu. The opcode's parameter format of that assembler is opposite of what I'm used to, but I think it won't be difficult to convert arcmon.asm into that.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 21, 2010, 06:12:10 pm
Vsync is working smoothly in Windows with this same card, so it's possible indeed. As for the jpac, I am almost sure it was vsynced yesterday with on AVGA card (jpac also there). So this sounds as one of those new EDID philosophy 'features' of newer cards related to not feeling monitors, as the one of turning off video, vsync support might be internally disabled. Technically vsync is something internal to the videocard, as it's the videocard the one driving the electron beam, not the opposite, so it's the card who knows when it's sending its vblank signal, so the jpac should not matter here unless the driver is designed to do so.

I'll keep testing with the new iso and all those options.

Btw I think it's highly possible that I can do the assembly patch for grub, provided it works as I think it does and you can build it later, so I won't be able to test it here. By now it will need to be fixed to plain text mode (mode 03h) but it will be enough for a menu. The opcode's parameter format of that assembler is opposite of what I'm used to, but I think it won't be difficult to convert arcmon.asm into that.


Ah, interesting, so it's not really the J-Pac alone but the card is helping make it somehow trigger the DRM layer to decide not to support the vsync.

The newer iso is uploaded, I think it'll solve the network issue and here I was able to get sound to work with that .asoundrc file trick, I had to pick 2 on this laptop it seemed.  The output of aplay -l really helped, I suspect it's doing the same thing there and needs this.  I need to figure out how that normally is automated in sound setup, possibly a menu option I guess or script to check for it.  There's actually a program alsaconf that if you run it may actually do all that for you, I'll need to look at possibly running that on first startup and save the config or something.

That would be great, sounds amazing to get grub to output 15khz, we'd basically be close as possible to the AVGA card then in Linux without it needed to be AVGA or even Radeon/ATI cards possibly in the future.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 22, 2010, 08:49:16 am
I've ported the Arcmon.asm code into AT&T inline assembly syntax, bear in mind it's the first time I use this syntax so it's likely to contain errors, though I've tried to do it as well as possible. The attached file contains the proc named set_arcade_mode which needs to be copied into /stage2/asm.S grub's source file, possibly below set_vbe_mode function. Then this proc must be used in substitution of set_vbe_mode in builtins.c where it's used, and should be referenced also I think in files shared.h and asmstub.c. Let me know if you are able to compile it, or send me the errors in case it's not possible. If you are going to test this, please make sure you have a way to undo changes before updating the boot sectors and stuff as this could fail (probably) as it's untested, and the hd could become unbootable. Is there a way to test this virtually or something?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 22, 2010, 10:40:48 am
I've ported the Arcmon.asm code into AT&T inline assembly syntax, bear in mind it's the first time I use this syntax so it's likely to contain errors, though I've tried to do it as well as possible. The attached file contains the proc named set_arcade_mode which needs to be copied into /stage2/asm.S grub's source file, possibly below set_vbe_mode function. Then this proc must be used in substitution of set_vbe_mode in builtins.c where it's used, and should be referenced also I think in files shared.h and asmstub.c. Let me know if you are able to compile it, or send me the errors in case it's not possible. If you are going to test this, please make sure you have a way to undo changes before updating the boot sectors and stuff as this could fail (probably) as it's untested, and the hd could become unbootable. Is there a way to test this virtually or something?

I just have to use it I think on the liveCD and it should, or USB stick, and if it fails only will hurt the CD :).  It compiles, I just had to change the comments from ; to // and then it compiled fine, I'll be testing it and let you know how it works.  Sounds really awesome.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 22, 2010, 10:45:24 am
Great. Also make sure you are not passing any param to this proc as it does not use any, unlike the set_vbe_mode that needed the mode number to be passed to it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 22, 2010, 12:15:07 pm
Great. Also make sure you are not passing any param to this proc as it does not use any, unlike the set_vbe_mode that needed the mode number to be passed to it.


It's interesting, that part of grub's code basically is a command available if you drop to a command prompt at the grub menu with 'c'.  It's testvbe MODE, so I tried that and passed 768 to it, since I was guessing number wouldn't matter since this new function overrides the choice.  It just got something out of range though and the monitor went into standby mode like it wasn't connected though.  I'm thinking this is actually testing it, what mode number is this actually using?  This is a good way to test it, but looks like with grub we'll need to find another entry point to place it I guess.  I'll look more into how it fits.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 22, 2010, 12:28:41 pm
I see, I was doubting if it was the right point to place the function. But is the arcade monitor out of range when testing it? It's using mode number 03h, the standard BIOS text mode, by calling int 10h to set the mode, and after that it's tweaking the crtc stuff to modify it to 15KHz. So if the mode is working, it would be a matter of calling the proc right before the menu options are printed.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dmarcum99 on December 22, 2010, 01:34:20 pm
Hi guys!

Does switchres have the ability to generate all the modelines used by the games in mame at one time?  I recall LRMC has that ability by using the "mamelist.xml > xxxxx.txt" command....

Also, I read in the description that switchres can read a config file where you can specify your custom monitor setting..??  How would I go about this and what format does this monitor info need to be in?  In LRMC I can enter the monitor specs kinda like advame...." 3 - 40 / 15.5 - 50.5 / 40-120 " and list a couple of reference modes.  I just want to make sure I can use your program to the fullest with my monitor. (NEC XM-2950) if this is genererating better modelines.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 22, 2010, 01:46:26 pm
Hi guys!

Does switchres have the ability to generate all the modelines used by the games in mame at one time?  I recall LRMC has that ability by using the "mamelist.xml > xxxxx.txt" command....

Also, I read in the description that switchres can read a config file where you can specify your custom monitor setting..??  How would I go about this and what format does this monitor info need to be in?  In LRMC I can enter the monitor specs kinda like advame...." 3 - 40 / 15.5 - 50.5 / 40-120 " and list a couple of reference modes.  I just want to make sure I can use your program to the fullest with my monitor. (NEC XM-2950) if this is genererating better modelines.

There's a perl script called genres.pl here...

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob_plain;f=scripts/genres.pl;hb=HEAD (http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob_plain;f=scripts/genres.pl;hb=HEAD)

It does the generation for all the different modelines in mame games now, has some command line options which should explain the usage.  It's of course most of the time no longer needed since switchres can do this dynamically, but more useful in Windows to create a table of modelines for Soft15khz and we can work off of that to change them dynamically to what we need.

In the switchres.conf file, can be under /etc/ or in the home directory, you can either say mon=<TYPE> which is quite extensive actually but for your monitor since seems even more than a d9800, you could do something like this...

You can have as many of these as you need, can also use on the command line with --mrange "line"...

MonitorLimits 15500-50000,40-120,2.187,4.688,6.719,0.190,0.191,1.018,0,0,576,768

Although the values past the V refresh above are Horizontal front porch, sync pulse, back porch, and Vertical ones, then positive or negative Hsync,Vsync, and max active lines, and max size to interlace/virtualize at.  So they might be different, and breaking it up into ranges for each set of front porch/sync pulse/back porches might be the right thing to do (for a d9800 there's about 5 ranges). 

Here's an example config:
http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob_plain;f=src/SwitchResC/extra/switchres.conf;hb=HEAD (http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob_plain;f=src/SwitchResC/extra/switchres.conf;hb=HEAD)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 22, 2010, 04:05:18 pm
I see, I was doubting if it was the right point to place the function. But is the arcade monitor out of range when testing it? It's using mode number 03h, the standard BIOS text mode, by calling int 10h to set the mode, and after that it's tweaking the crtc stuff to modify it to 15KHz. So if the mode is working, it would be a matter of calling the proc right before the menu options are printed.


I found the right point to run it at, and it runs, but it seems to put the monitor into a state where it's claiming not detected and the background behind the OSD screen saying that has real fuzzy stuff scrolling vertically.  It then seems to not boot or anything from that point, so I'm guessing it's some crash happening.

Here's the patch I have built into an ebuild so far...

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=tree;f=overlays/sys-boot/grub/files;h=9f7906280c19b1fb22d421fea3c4bc4df5451ef7;hb=HEAD (http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=tree;f=overlays/sys-boot/grub/files;h=9f7906280c19b1fb22d421fea3c4bc4df5451ef7;hb=HEAD)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 22, 2010, 05:10:20 pm
Yes, I'm afraid that mode does not work for me either in a dos compile executable I've tested made from that. That code is old and could be newer cards bios modes use different timings as a base, I'm seeing that with jpac not dealing with them as well as with older ATIs. In addition there could be some errors due to syntax so it would be great to have the raw binary produced by the compiler to compare with the dos one to check if there's any bad address or wrong opcodes.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Gray_Area on December 23, 2010, 09:21:17 pm
@bitbytebit

I think dmarcum99's question was: are you eventually going to have an app similar to advancecfg, but with a more 'user-friendly' interface?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 23, 2010, 09:43:21 pm
@bitbytebit

1. by 'dynamically' you mean the 'generate at run-time' feature in AdvanceMAME, right?

2. I think dmarcum99's question was: are you eventually going to have an app similar to advancecfg, but with a more 'user-friendly' interface?

Yes, it uses the mame information for the resolution of the original game at runtime and generates the modeline according to the monitor specs and applies that modeline to the display monitor.  In theory a person could write an app to run instead of mame in switchres which did the same thing as advance mame had, alter the front/back porches to center the display.  The backend structure is probably all there to support using a tool to take the modeline from switchres, display it have you use the tool to adjust it somehow with a user-friendly interface, then have it write out a range config into switchres.conf for what you adjusted things to.  I've been working on the assumption of a monitor database of the needed settings, so you just have to say h9110 or d9800, ntsc, pal or cga etc.   There could be more monitors added with people looking up the specs and testing them, but understand it's not totally user-friendly although it'll probably take time to gather that information, which will eventually lead to being more user friendly for each monitor type.  For an h9110, d9800, generic CGA monitor it should just make the best decisions and be more user friendly than advance was because you just have to tell it your monitor type in those cases.  No need to fiddle with each game I think, at least I don't, and I think Calamity has a pretty good method of calculation which avoids that as much as possible.  I figure I might not know all cases of course so guessing there's places that need work, so always looking to get feedback and information to fill in those gaps.  I did think about writing some kind of tool to adjust the modelines live, like advance config does, although I'm not really a GUI programmer so it'd be a nice way to learn more about that yet might not be quick at doing it or feel it's going to match advance config anywhere close.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 24, 2010, 08:25:17 am

I found the right point to run it at, and it runs, but it seems to put the monitor into a state where it's claiming not detected and the background behind the OSD screen saying that has real fuzzy stuff scrolling vertically.  It then seems to not boot or anything from that point, so I'm guessing it's some crash happening.

Here's the patch I have built into an ebuild so far...

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=tree;f=overlays/sys-boot/grub/files;h=9f7906280c19b1fb22d421fea3c4bc4df5451ef7;hb=HEAD (http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=tree;f=overlays/sys-boot/grub/files;h=9f7906280c19b1fb22d421fea3c4bc4df5451ef7;hb=HEAD)

I could finally do some tests with the arcade mode asm routine in both HD4350 and 9250 and it fails with them. So it definitely doesn't work, either for some error of mine, or it could be that those ports aren't working that way with modern cards... or whatever. It was promising as here I tested it with a pc monitor and it was reporting Hfreq 16.0 KHz, so it's doing something, but it turns out to be completely out of sync. So I'm going to leave this grub thing by now until I have a proper way to test it, and if I eventually have a routine that I'm sure that works here, I'll post it so that you can try to patch grub with it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 24, 2010, 04:27:48 pm

I found the right point to run it at, and it runs, but it seems to put the monitor into a state where it's claiming not detected and the background behind the OSD screen saying that has real fuzzy stuff scrolling vertically.  It then seems to not boot or anything from that point, so I'm guessing it's some crash happening.

Here's the patch I have built into an ebuild so far...

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=tree;f=overlays/sys-boot/grub/files;h=9f7906280c19b1fb22d421fea3c4bc4df5451ef7;hb=HEAD (http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=tree;f=overlays/sys-boot/grub/files;h=9f7906280c19b1fb22d421fea3c4bc4df5451ef7;hb=HEAD)

I could finally do some tests with the arcade mode asm routine in both HD4350 and 9250 and it fails with them. So it definitely doesn't work, either for some error of mine, or it could be that those ports aren't working that way with modern cards... or whatever. It was promising as here I tested it with a pc monitor and it was reporting Hfreq 16.0 KHz, so it's doing something, but it turns out to be completely out of sync. So I'm going to leave this grub thing by now until I have a proper way to test it, and if I eventually have a routine that I'm sure that works here, I'll post it so that you can try to patch grub with it.


Well at least we have some path into doing this eventually, now that we know where to put something like this into grub.  You might want to look at the newer grub2 sources since I think it can do more vesa bios resolution stuff so might have something to modify off of, guessing that might help. 

Have you been able to test the audio and network with the newest ISO, possibly trying the alsaconf program, I've been looking that that some and hopefully the network issue is fixed.  I'm still looking into the audio but at least have quite a bit better support for setting the right output and unmuting, also have a graphical mixer control now.  My local ISO build is a bit further than the one I have uploaded though, I need to upload a new ISO of what I've got here since have a few more improvements on how it sets up the mixer/sound output.  I now have it writing a .asoundrc file and asks for the audio output to use, might be one fix.  I do have the odd laptop here though still that I can get music to play on but mame is silent on it, it's weird.  I have read that I guess some Alsa drivers in Linux are not so great and there's a bit of issues with Alsa in Linux so that could be part of the issue for your audio.  It seems the audio layer is quite complicated on setting up a Linux distro with it correctly done for all cases, I'm looking at this pulse audio although I don't like the idea because of overhead.  I actually am becoming more in favor of just running wahcade or fvwm with wahcade probably as preferred since the lxde desktop is nice but again there's overhead there and I suspect at least on older systems it's a big waste of memory and could cause some latency. 

Also Alex from AMD seems to be interested in the J-Pac issue we see with OpenGL, which he's guessing somehow it's still not setting up the output for page flip vsync/blank support even though we are forcing it enabled.  It's really a DRM issue most likely he says, makes sense, OpenGL is just trying to use it and it's not ready for that type of interface somehow.  I'll look deeper into that some, and he might just show up with a patch hopefully, I gave him details on J-Pac and how it works and what the issue seems to be.  Any more information that you think would help would be great, since it seems J-Pac is somewhat less than documented fully since it's sort of a specialized thing from Ultimarc and doesn't seem to be a total standard out there but guessing just used by most people.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 25, 2010, 09:37:55 am
These days I've been having problems with my cab so I couldn't do the last tests. Before that I tested the last iso for a while and I was having a problem, when switching resolutions it was exiting x windows, this happened either from switchres or wahcade, but I didn't test any further to have a proper report. So I still need to go back to it and test more. BTW the vblank environment variable should be already set to 0 in this iso, shouldn't it? I need to get a replacement for my keyboard that has stopped working, then will try it again.

Sounds good that Alex from AMD is having a look at that issue. I'm optimistic at having that eventually solved, as in fact there's no physical limitation for achieving it, it must be a software issue. There're a lot of little things here and there that need to be done to have this working for everybody, but will definitely be worth the effort. I think that solving this jpac issue is a must as it's a very spread interface and many people are using it.

I've been working also on my patched Catalyst drivers, the version based on Catalyst 9.3 is available to download here:

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

It admits up to 134 video modes, so we can also start testing it with a decent mode list and Switchres.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 25, 2010, 10:06:45 am
These days I've been having problems with my cab so I couldn't do the last tests. Before that I tested the last iso for a while and I was having a problem, when switching resolutions it was exiting x windows, this happened either from switchres or wahcade, but I didn't test any further to have a proper report. So I still need to go back to it and test more. BTW the vblank environment variable should be already set to 0 in this iso, shouldn't it? I need to get a replacement for my keyboard that has stopped working, then will try it again.

Sounds good that Alex from AMD is having a look at that issue. I'm optimistic at having that eventually solved, as in fact there's no physical limitation for achieving it, it must be a software issue. There're a lot of little things here and there that need to be done to have this working for everybody, but will definitely be worth the effort. I think that solving this jpac issue is a must as it's a very spread interface and many people are using it.

I've been working also on my patched Catalyst drivers, the version based on Catalyst 9.3 is available to download here:

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

It admits up to 134 video modes, so we can also start testing it with a decent mode list and Switchres.



Sounds great, sounds like with that driver we should be able to do about any resolution needed then. 

I'm uploading new ISO's, version 1.204-d0dc486, also have new switchres versions up too and mame builds of 140u3 also with the cabmame patches (finally figured that out).  The switchres version adjusts some for the changeres hack, because I discovered about it.  Seems that it forces a 1 to 1 scale ratio so basically prevents scaling from happening or stretching when enabled.  Which basically you don't want to use changres when you are virtualizing, cases where you aren't trying to get 1 to 1 pixel perfection.  So changeres is sort of dual purpose, it doesn't just do the resolution change stuff but also is doing the part to avoid altering the pixels or stretching them in any way.  I'm not totally sure why, or if it's a side effect or what, I just know from how the code is and seeing the effects that it's doing that.  It basically sets x/y scale to 1 in cleanstretch code, forces it that way, and so in switchres now I turn it off/on according to if we are virtualizing or not.  These new ISO images should hopefully help audio setup, and fix the network connection issues, get them all synced up with my current build here.

It seems more improvements, some maybe relating to the issue with the j-pac issue, are being adding to the newest Linux-Next kernel versions.  Not sure, but at least look like there's even more stuff/features being put in.  So that looks promising, and also I'm going to start digging in there and trying to find where it prevents the setup from happening even when we force the connector enabled. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 25, 2010, 02:00:08 pm
I've finally tested 1.191 and fortunately the network is working again, I've been able to get the logs normally so this will make things easier. I've noticed you've added a login step at startup now. I need to set vblank_mode=0 for things to work, so the error I had seen before was that I hadn't done that. On the audio part, it doesn't work yet, alsaconf program is not recognized (only alsamixer is) and I can see how both audio devices are found, being the hdmi the default one. Have look at the switchres.log I've attached, there's an SDL error there as it does not find an audio device. I'm going to download and test the new one now.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 25, 2010, 02:35:52 pm
I've finally tested 1.191 and fortunately the network is working again, I've been able to get the logs normally so this will make things easier. I've noticed you've added a login step at startup now. I need to set vblank_mode=0 for things to work, so the error I had seen before was that I hadn't done that. On the audio part, it doesn't work yet, alsaconf program is not recognized (only alsamixer is) and I can see how both audio devices are found, being the hdmi the default one. Have look at the switchres.log I've attached, there's an SDL error there as it does not find an audio device. I'm going to download and test the new one now.

The alsaconf program will need to run as root, running 'sudo -s' should be done first to be able to run it.  Yeah I'm using the gdm display manager now so it makes it easier to have X work right, hopefully the newer ISO will set the audio device order, or basically allow you to do that.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 27, 2010, 02:04:33 pm
I've been testing the 1.204 one and playing with alsaconf and the new gnome mixer. I still have not sound however. I can see both audio devices, hdmi and VIA integrated audio in the setup menu, I'm selecting card 1 (VIA) and everything is ok. Then I run sudo -s alsaconf and select again the VIA card, it proceeds with it's stuff and says the audio driver is configured ok, updates alsa.conf and exits. But when I run the gnome mixer, then it shows a fuzzy behaviour, I have two tabs there, one for the ATI HDMI and the other for the Realtek VIA, it's this second one where sometimes I have front + surround + back + ... playback/recording stuff with its volume slides, other times it only shows part of it, like the recording controls only, and yet other times its void. I've also seen that the setup menu sometimes only shows the HDMI device (I believe it's when I restart without switching off). So there seems to be a problem recognizing the devices (is it blindly polling some ports there to find things?). In one of my tests everything looked ok, volume was on for the front speakers, but I still couldn't hear anything inside Mame. I've attached the logs in case they can be of help.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 27, 2010, 02:17:57 pm
I've been testing the 1.204 one and playing with alsaconf and the new gnome mixer. I still have not sound however. I can see both audio devices, hdmi and VIA integrated audio in the setup menu, I'm selecting card 1 (VIA) and everything is ok. Then I run sudo -s alsaconf and select again the VIA card, it proceeds with it's stuff and says the audio driver is configured ok, updates alsa.conf and exits. But when I run the gnome mixer, then it shows a fuzzy behaviour, I have two tabs there, one for the ATI HDMI and the other for the Realtek VIA, it's this second one where sometimes I have front + surround + back + ... playback/recording stuff with its volume slides, other times it only shows part of it, like the recording controls only, and yet other times its void. I've also seen that the setup menu sometimes only shows the HDMI device (I believe it's when I restart without switching off). So there seems to be a problem recognizing the devices (is it blindly polling some ports there to find things?). In one of my tests everything looked ok, volume was on for the front speakers, but I still couldn't hear anything inside Mame. I've attached the logs in case they can be of help.


I have been able to get my laptop working with sound, but I have basically found a few things that possibly allowed this.  I have blacklisted a few sound modules, the pcspeaker and HDMI audio and an Intel Modem audio driver.  On my laptop it may have not been working from the pcspeaker and Intel modem driver being before the real sound card.  For your situation it seems the HDMI audio may be doing the same thing so now I blacklisted it too.  Also an interesting note is that the starfire game has no sound, it was confusing me partly during testing because of that.  I do know the gridlee game has sound, only when shooting the things and hitting them, so at least now know the best test cases on the demo games.  I suspect your either having the issue of HDMI Audio taking over, or it's an Alsa issue with your setup.  I'm not sure because I actually have the same intel-hda audio as I think yours does so seems Alsa should support it, so it points to the HDMI audio module taking over the first port (which I think possibly is where Mame is having issues only knowing about the first dsp device).  Also there's another thing I did, compiling in OSS support to libSDL which might have also helped since oddly seems libSDL needs both Alsa and OSS support enabled to work with Alsa correctly and mame.  If you are able, try playing a sound or movie file (if full version, just running mplayer <FILE> should do this), since that way can see if it's just Mame.  I did find that sometimes just Mame didn't output sound while I could play audio from mplayer, but that might be the OSS support thing again.  So I'll have a new ISO image with my current changes which may fix it.  I have another option too, which I probably am going to do anyways, putting in OSS4 sound support to use instead of Alsa.  It's supposed to be a lot better in handling things, I think have the build able to switch back and forth between the two.  Will get an ISO up later today probably with both available and the other changes which may fix Alsa too. 

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 27, 2010, 03:21:25 pm
Unfortunately the one I downloaded was the NoMedia, so next time I'll download the full one. Is there a way to test sounds there without the need of loading media files, having some system sounds activated or something?

I've also done some tests with Switchres in Windows and my hacked drivers. This time I didn't use Soft-15Khz, as I'm using a modified version of my VMMaker app to create the base mode list, as I'm investigating the best method for it. I'm having a problem now with Switchres not being able to modify the modes, just choosing the dummy ones. It's complaining it doesn't find the keys ("Failed getting resolution values from DALDTMCRTBCD184X192X0X60"). But the keys are there indeed. So I'm wondering if it's trying to find something else, like the DADTM... duplicated ones that Soft-15kz uses and are not necessary at all with this Catalyst version.

Code: [Select]
C:\Emuladores\Mame>switchres loht --soft15khz -v-v-v
Mame version 0.131 with [cleanstretch][][redraw][] hacks enabled
[] "loht" horizontal 384x256@55.018 (1.500) --> 384x256@55.018 (1.500)

# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vpad +2 lines | )
# loht [2] 384x256@55.02 15.2949Khz
     "384x256x55" 7.708626 384 400 440 504 256 258 261 278 -HSync -VSync

DefaultVideo 'System\CurrentControlSet\Control\Video\{4534B163-EB63-466E-90EA-76
F5C53BAD45}\0000'
DALDTMCRTBCD184X192X0X60:
  (63812/68) Modeline 3.890000 184 192 216 248 192 218 221 261
Failed getting resolution values from DALDTMCRTBCD184X192X0X60
Opening  modes file for mode 384x256@55
Target refresh = 55.017606
loht_i8751.mcu NOT FOUND (NO GOOD DUMP KNOWN)
WARNING: the game might not run correctly.

C:\Emuladores\Mame>switchres loht --soft15khz -v-v-v >switchres.log
Mame version 0.131 with [cleanstretch][][redraw][] hacks enabled
[] "loht" horizontal 384x256@55.018 (1.500) --> 384x256@55.018 (1.500)

# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vpad +2 lines | )
DefaultVideo 'System\CurrentControlSet\Control\Video\{4534B163-EB63-466E-90EA-76
F5C53BAD45}\0000'
DALDTMCRTBCD184X192X0X60:
  (63812/68) Modeline 3.890000 184 192 216 248 192 218 221 261
Failed getting resolution values from DALDTMCRTBCD184X192X0X60
Opening  modes file for mode 384x256@55
loht_i8751.mcu NOT FOUND (NO GOOD DUMP KNOWN)
WARNING: the game might not run correctly.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 27, 2010, 03:31:59 pm
Unfortunately the one I downloaded was the NoMedia, so next time I'll download the full one. Is there a way to test sounds there without the need of loading media files, having some system sounds activated or something?

I've also done some tests with Switchres in Windows and my hacked drivers. This time I didn't use Soft-15Khz, as I'm using a modified version of my VMMaker app to create the base mode list, as I'm investigating the best method for it. I'm having a problem now with Switchres not being able to modify the modes, just choosing the dummy ones. It's complaining it doesn't find the keys ("Failed getting resolution values from DALDTMCRTBCD184X192X0X60"). But the keys are there indeed. So I'm wondering if it's trying to find something else, like the DADTM... duplicated ones that Soft-15kz uses and are not necessary at all with this Catalyst version.

Code: [Select]
C:\Emuladores\Mame>switchres loht --soft15khz -v-v-v
Mame version 0.131 with [cleanstretch][][redraw][] hacks enabled
[] "loht" horizontal 384x256@55.018 (1.500) --> 384x256@55.018 (1.500)

# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vpad +2 lines | )
# loht [2] 384x256@55.02 15.2949Khz
     "384x256x55" 7.708626 384 400 440 504 256 258 261 278 -HSync -VSync

DefaultVideo 'System\CurrentControlSet\Control\Video\{4534B163-EB63-466E-90EA-76
F5C53BAD45}\0000'
DALDTMCRTBCD184X192X0X60:
  (63812/68) Modeline 3.890000 184 192 216 248 192 218 221 261
Failed getting resolution values from DALDTMCRTBCD184X192X0X60
Opening  modes file for mode 384x256@55
Target refresh = 55.017606
loht_i8751.mcu NOT FOUND (NO GOOD DUMP KNOWN)
WARNING: the game might not run correctly.

C:\Emuladores\Mame>switchres loht --soft15khz -v-v-v >switchres.log
Mame version 0.131 with [cleanstretch][][redraw][] hacks enabled
[] "loht" horizontal 384x256@55.018 (1.500) --> 384x256@55.018 (1.500)

# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vpad +2 lines | )
DefaultVideo 'System\CurrentControlSet\Control\Video\{4534B163-EB63-466E-90EA-76
F5C53BAD45}\0000'
DALDTMCRTBCD184X192X0X60:
  (63812/68) Modeline 3.890000 184 192 216 248 192 218 221 261
Failed getting resolution values from DALDTMCRTBCD184X192X0X60
Opening  modes file for mode 384x256@55
loht_i8751.mcu NOT FOUND (NO GOOD DUMP KNOWN)
WARNING: the game might not run correctly.


I think it's confused about the X being capitol instead of lower case, DALDTMCRTBCD184X192X0X60, which with Soft15khz they were always DALDTMCRTBCD184x192x0x60 syntax (which the case sensitivity is built into the C Posix stuff  I guess).  That's most likely the issue, not sure why Soft15khz uses lower case, I guess both work for the driver?  I can always add a check for both, is it otherwise pretty much standard though otherwise besides that of what will work for those?

I'll hopefully have a new ISO set up with OSS4 support (which will allow to switch between the two Alsa and it I think) and the newer linux-next tree which might have some chance of fixing the 4350, at least seems there are some interesting changes that might hit that bug.


Update:  uploaded new windows build with the ability to use either X or x in the resolution name
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 27, 2010, 04:59:53 pm
It's working ok now, so it was the x/X issue. I'm testing it more deeply now:

- The stretching is not properly set when we are virtualizing, so the game shows in a little box in the middle of the screen (hwstretch should be set to 1, only that option)
- Some games are chopped, for instance Contra is choosing a 344x272 resolution I have there, being 280 lines high, so it's missing some lines up and down. I always assume the original resolution should fit in the target one. In same cases it could be better to loose some lines when the next one is way too big, but I won't allow that to happen by building a good mode table, anyway it could be good to have an option to control that behaviour.
- We always get a little bit below the target vfreq, I believe there's some extra accuracy available there by using some kind of dotclock table as I was doing, however it's rather accurate most of the time (99% or so of the speed) so that can be pretty good for now.

I think we should stablish a standard method for calculating rotated resolutions for vertical games, and allow different variants. I've seen that in your switchres code you're doing game->width = (4.0/3.0) * game->height; That gives good results most of the time though it's not the way it should be done imho. I'm not doing it any better either in my code, I'm using a different approach that produces a highly stretched picture more or less square-shaped. But the really right way should be available at least as an option. This came to my mind now as it's the time to define a good standard mode table, and in case we wanted to include resolutions for rotated vertical games, we should agree the way to create that resolutions or at least be able to tell switchres how we like them so it can choose the right ones.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 27, 2010, 05:20:23 pm
It's working ok now, so it was the x/X issue. I'm testing it more deeply now:

- The stretching is not properly set when we are virtualizing, so the game shows in a little box in the middle of the screen (hwstretch should be set to 1, only that option)
- Some games are chopped, for instance Contra is choosing a 344x272 resolution I have there, being 280 lines high, so it's missing some lines up and down. I always assume the original resolution should fit in the target one. In same cases it could be better to loose some lines when the next one is way too big, but I won't allow that to happen by building a good mode table, anyway it could be good to have an option to control that behaviour.
- We always get a little bit below the target vfreq, I believe there's some extra accuracy available there by using some kind of dotclock table as I was doing, however it's rather accurate most of the time (99% or so of the speed) so that can be pretty good for now.

I think we should stablish a standard method for calculating rotated resolutions for vertical games, and allow different variants. I've seen that in your switchres code you're doing game->width = (4.0/3.0) * game->height; That gives good results most of the time though it's not the way it should be done imho. I'm not doing it any better either in my code, I'm using a different approach that produces a highly stretched picture more or less square-shaped. But the really right way should be available at least as an option. This came to my mind now as it's the time to define a good standard mode table, and in case we wanted to include resolutions for rotated vertical games, we should agree the way to create that resolutions or at least be able to tell switchres how we like them so it can choose the right ones.


I need to look at the hwstretch, do you know what the exact command line is and what needs to be removed from what it's currently doing?  I know the cabmame hacks bring into play the changeres which I have to check for and turn off else that prevents all stretching (for some reason that patch forces cleanres and inside of that forces scaling to 1x1 instead of what it would have been set to for stretching, at least from what I can tell and have seen testing it).  Which option is it possibly that keeps hwstretch from working?

So there's no 344x280 resolution and it picks that one?  I can see that as being an issue, the horizontal I'm allowing up to 16 pixels extra but for vertical the logic just stops at the total height.  Will need to think of doing that better, it gets tricky to let both go past the original but haven't spent too much time looking into that either.

Yeah the dotclock being slightly inaccurate might just be more of the 1000 alignment in Linux or 10000 in Windows and using your method, since I was thinking if that's the granularity of both systems then it'll be cutoff anyways so might as well see if there's a better value for the dotclock to get closer.  I need to port that code into it for the dotclock like I had in the perl version, will look at that.  Should hopefully be easier actually since Perl was really not easy to do that precise of value checking in while in C it should be quite natural.

Yeah I wondered about the aspect ratio calculation for vertical games and how to do that better, did basically what lrmc and your calculations do (well lrmc did use something slightly different using this calculation...


    if (mode->aspect3x4 == 1)
    {
      mode->hres = mode->hres / 0.5625;
    }


Which was always too wide looking, and I think certain games look too wide with the current one too but others look pretty good compared to the lrmc calculation.  Definitely interested in a better way to calculate it, but everything I've tried seems to not be as good and actually usually make more games look odd, how would we get the right amount to calculate that every time correctly?


Update:

Also seems that the cleanstretch option definitely prevents hwstretch from extending fully, I tried this...

mame <rom> -nochangeres -nocleanstretch -hwstretch -keepaspect

And it works right, while without -nocleanstretch I get bars at the top/bottom still, need keepaspect it seems with hwstretch or else it's too wide on vertical games.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 27, 2010, 06:18:16 pm
Yes, with SDL you need the keepaspect option for vertical games + stretch, with ddraw/d3d you don't. So:

- SDL + vertical games + stretch: unevenstretch 1, keepaspect 1
- DDraw + vertical games + stretch: hwstretch 1 (-[no]hwstretch / -[no]hws)

The cleanstretch is for D3D where hwstretch does not apply as D3D always stretches everything by default, that's why I don't like using it, until DDraw disappears I'll stick with it.

I understand the changeres does not make sense when virtualizing as we are somewhat ignoring resolutions that way, so we are just stretching to the existing one.

On the Contra issue, yes, it's taking that one cause the next one is way wider as I'm precalculating vertical resolutions in a different way. It should only allow a resolution if both xres and yres are >= the ones we need, at least this could be an option so you'll never get chopped pictures.

The key to get consistent results with vertical games is to base xres calculations on original height instead of width. It would be good to have some drawings to explain this but a sample will do I think. Say you have 2 different vertical games, with original resolutions of 256x224 and 256x240. Now we want to display them rotated on our horizontal monitor. So we start by swapping xres and yres values, and we get:

1.- 224x256
2.- 240x256

Both resolutions are 256 lines tall. Now we need to get a wider resolution in order to get side bars and a proper aspect, ok? If you use 4/3 x 256 = 341,33 ->344 ... then you'll be using the same 344x256 for both of the above resolutions, which is not good, as one game will look wider than the other, and what we want is that they both have 3:4 aspect.

So to be consistent we should use the first value as a base for our calculations. We need a resolution so wide that 224 or 240 in each case looks 3/4 as wide as our physical screen height. I think it should be done like this:

height = 4/3 yres
width  = 4/3 height

so width = 4/3 x 4/3 yres = 16/9 yres

So for each of the cases it would be:

1.- 400x256
2.- 432x256

However I've tested this and it looks too narrow, used to the other way, so I would keep the other method as a option (if you look at my code, I was already using original yres as the base for calculations but using 4/3 factor instead of 16/9, which was producing a 3:3 aspect). Anyway the explosions look circles so I think it must be ok. I still have to actually measure on the screen to see if this is working or not.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 27, 2010, 06:59:13 pm
Yes, with SDL you need the keepaspect option for vertical games + stretch, with ddraw/d3d you don't. So:

- SDL + vertical games + stretch: unevenstretch 1, keepaspect 1
- DDraw + vertical games + stretch: hwstretch 1 (-[no]hwstretch / -[no]hws)

The cleanstretch is for D3D where hwstretch does not apply as D3D always stretches everything by default, that's why I don't like using it, until DDraw disappears I'll stick with it.

I understand the changeres does not make sense when virtualizing as we are somewhat ignoring resolutions that way, so we are just stretching to the existing one.

Ah, ok, so in d3d mode though it seems you still need keepaspect, since I think my quick tests were using that.  Guess it would be best then to force ddraw mode, since else seems we won't know what to do and that actually would be best anyways for arcade monitors (and maybe force opengl in SDL mode too).

On the Contra issue, yes, it's taking that one cause the next one is way wider as I'm precalculating vertical resolutions in a different way. It should only allow a resolution if both xres and yres are >= the ones we need, at least this could be an option so you'll never get chopped pictures.

Yeah, that's I guess where we need the large mode table since I am guessing in both cases the picture won't look right being either squished from side to side (or stretched possibly) and the other it'd be missing some top/bottom.  Would it be possibly work to just treat it as virtualized in these cases where it won't fit vertically without too much horizontal size, since I'm guessing that the other 2 possibilities are not going to look good anyways when trying to not do any stretching/shrinking of it.


The key to get consistent results with vertical games is to base xres calculations on original height instead of width. It would be good to have some drawings to explain this but a sample will do I think. Say you have 2 different vertical games, with original resolutions of 256x224 and 256x240. Now we want to display them rotated on our horizontal monitor. So we start by swapping xres and yres values, and we get:

1.- 224x256
2.- 240x256

Both resolutions are 256 lines tall. Now we need to get a wider resolution in order to get side bars and a proper aspect, ok? If you use 4/3 x 256 = 341,33 ->344 ... then you'll be using the same 344x256 for both of the above resolutions, which is not good, as one game will look wider than the other, and what we want is that they both have 3:4 aspect.

So to be consistent we should use the first value as a base for our calculations. We need a resolution so wide that 224 or 240 in each case looks 3/4 as wide as our physical screen height. I think it should be done like this:

height = 4/3 yres
width  = 4/3 height

so width = 4/3 x 4/3 yres = 16/9 yres

So for each of the cases it would be:

1.- 400x256
2.- 432x256

However I've tested this and it looks too narrow, used to the other way, so I would keep the other method as a option (if you look at my code, I was already using original yres as the base for calculations but using 4/3 factor instead of 16/9, which was producing a 3:3 aspect). Anyway the explosions look circles so I think it must be ok. I still have to actually measure on the screen to see if this is working or not.



Interesting, I hadn't realized that but now makes sense, I'll have to play around with that too.  Sounds like there should be some way to get it working off of that pretty consistent although seems like this issue is a bit more tricky than that from my past experiments.

I'll have a new windows version up in a bit with at least the changes to try and do hwstretch better.  Have one up now but it's still not doing it like your explaining here, am forcing the video now so I can just go with the ddraw method.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 27, 2010, 07:20:34 pm
Doing some tests, I seem to have found that the original method of lrmc somehow magically gets this where the games do look best, when applied like below to the original "height"  (which in the calculation by this time is transformed into the new width).  I don't know why that .5625 figure works, but suddenly now galaxian and frogger look better and even pacman, it was closer than those were but for some reason this seems to just work?  If I use .75 there or 3/4 it is too skinny like you said, so this game->width = (float)game->width / 0.5625; line is the one that seems to look best to me so far, odd though, I thought the lrmc calculation was always wrong but with your modeline generation logic it now looks quite right.

Code: [Select]
--- a/src/SwitchResC/xml.c
+++ b/src/SwitchResC/xml.c
@@ -209,8 +209,10 @@ int ParseXML(xmlDocPtr xmlbuffer, GameInfo *game, ConfigSettings *cs) {
                                                        game->width = h;
                                                        game->height = w;
                                                        game->orientation = 1;
-                                                       game->width = (4.0/3.0) * game->height;
+                                                       //game->width = (4.0/3.0) * game->height;
+                                                       game->width = (float)game->width / 0.5625;
                                                        //game->width = game->o_aspect * game->height;
+                                                       //game->width = game->width / (game->o_aspect);
                                                        } else {// orientation = horizontal
                                                        game->orientation = 0;
                                                        }

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 27, 2010, 07:46:28 pm
 Ok, in 1.220 which I just uploaded I'm trying to fix those three things, which I am not fully sure how it'll act so let me know :) I basically used the fix above for the vertical games width calculation, virtualize the cases where we can't find a resolution to fit into without being extra wide (at least for now), and think I have the stretching better for Windows now.

Also you logs for the 4350 had a thing about DMA not being able to get enabled, I am suspicious of that line since I don't get it so sent that to Alex to look into.  The kernel I just tried unfortunately seems to have gained a latency bug of some sort where pressing the button doesn't always react and seems off.  I'm not sure where this has been introduced but they are doing some changes with the kernel scheduler right now so I probably will revert back or even possibly drop all the way back to the older one I'm using on my main installation.  I'm trying to figure out for sure though about that right now, hopefully can fix the audio though with the Alsa changes (if not OSS4 is the next step to try, but it doesn't enable on the CD and I'll have to probably build either/or versions, can't seem to have both), I think the linux-next kernel has been slightly getting worse about the latency thing and now it's bad enough to notice plus my network connection now has a rythmic time out pause to it so that's also annoying.  I'm hoping the latency thing doesn't have to do with the drm stuff, I'm thinking it isn't but also this linux-next branch is a moving target. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 27, 2010, 10:31:16 pm
Weird, now I realize your calculation is the same as lrmc was doing and it's basically 9/16 and going about it by dividing instead of multiplying.  So maybe this is right, although I'm not sure why it's all based on 16:9 yet results seem nice for the most part.  I agree it seems a slight bit squished but then again might just be used to the other way I guess. I understand using the original actual monitor height, but odd to use HD tv aspect ratios in the calculation with that.  So I must be missing something, because it does look alright that way (well more like I expect, admit the 3/4 calculation seems nice for some games still or might just be what I'm used to).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 28, 2010, 04:29:56 am
Uploading LiveCD32-MinimalNoMedia-1.227-7be72c3.iso which should have the newer sound fixes, also I downgraded the kernel to the stable one for now to see how that goes.  I also have new switchres versions up (this iso has them) which have command line options to align to certain HZ values for the dotclock, so ported part of the code just not the predefined table yet.   It's interesting, I've seen some oddities with how the earlier Linux kernel seems a slight bet faster than it should be works better, the newer linux-next versions are slightly behind but have more latency issues it seems.  I think it's in between right now, newer development kernels are showing more accuracy but still slightly unstable, older stable one generally works nice no tearing but may be a little off in the speedy side.  Also have the option to use either the older method of vertical game calculations or newer one, so can play around with those options in Windows and Linux now and see how it works.  Hopefully this one can solve the audio issues, I at least suspect, one oddity was the older kernel named the radeon HDMI audio part a different name so had to add that in to blacklist it too.  Upload should be up in an hour or so.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 28, 2010, 04:45:54 am
I'll test those when I get home.

Yes, the 16/9 is misleading because we're used to seeing it in the HD context, but it makes sense as it's the product of 4/3 x 4/3 (see the above equations), and the fact that lrmc was using the same factor reinforces this idea.

It's true that I had also got used to the other method (however, notice that I was using 4/3 of the original height, not the original width that is the method you were using), as it somewhat fills the screen more and can be nicer to the eye once you're used to it.

(http://img256.imageshack.us/img256/7643/verticalq.png) (http://img256.imageshack.us/i/verticalq.png/)

a = 4/3 b
b = 4/3 c

--> a = 16/9 c
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 28, 2010, 11:28:11 am
In the new version I have these options...

  --vcalc [0|1|2]         Method of calculating width on vertical games (1 is wider than 0)
  --dcalign <HZ>          Align dotclock to Hz (Windows 10000 Linux 1000)

So basically --vcalc 0 (default) is the new correct way, 1 is the old 4/3 way which some people may like even though it's not as accurate.  It's interesting because looking through resolution modelines in the past I've seen both methods and now explains it that there's two methods like this or two types of people I guess (I like the new way best, but can see how the old way has appeal too for me).

In Linux the dotclock align is interesting, I haven't played with it in the 2.6.36.2 kernel (stable one currently) only the in between one I've got running at 2.6.37-rc3.  It doesn't seem to do much there aligning at 1000 to change refresh rate exactness yet 10000 for some reason kind of hits it close but a little over (and pacman gets that extra 313 line from that and breaks 80% of the time again, but runs when it runs almost exactly 100%).  So I'm guessing it's one of those close as you can get things and can't divide up the extra line and fiddle with it any closer, especially when forced down to 1000 granularity. 

In Windows how can it utilize those ones you calculated, since it stores them in alignment to 10000?  Something this has made me start wondering about, or is it the extra lines doing the work to in theory get to that value?  Also I see basically it goes max 5 lines more, mostly think I ported the code right, for at least the align to a value case, but was some difference I think again in C which made it in somewhat different...
Code: [Select]
        if (cs->dcalign) {
                int i;
                int newPclock = 0;
                int vIncr = 0;
                double newDiff = 0, Diff = 0;
                ModeLine newMode;
                memcpy(&newMode, mode, sizeof(struct ModeLine));
                if (cs->verbose > 3)
                        fprintf(stderr, "Vfreq = %f Game Refresh = %f\n", mode->vfreq, game->refresh);
                for (i = 0; i < 5; i++) {
                        /* calculate new horizontal frequency */
                        mode->hfreq = mode->vfreq * (mode->vtotal + i);
                        if (mode->hfreq <= monitor->HfreqMax) {
                                /* Fill horizontal part of modeline */
                                newMode.hfreq = mode->hfreq;
                                newMode.hactive = mode->hactive;
                                ModelineGetLineParams(&newMode, monitor);
                                newMode.pclock = mode->hfreq * newMode.htotal;
                                if (fabs(Normalize(newMode.pclock-cs->dcalign, cs->dcalign)-newMode.pclock) < fabs(Normalize(newMode.pclock, cs->dcalign)-newMode.pclock))
                                        newMode.pclock = Normalize(newMode.pclock, cs->dcalign) - cs->dcalign;
                                else   
                                        newMode.pclock = Normalize(newMode.pclock, cs->dcalign);
                                newMode.vfreq = newMode.pclock / ((mode->vtotal + i) * newMode.htotal);
                                newDiff = fabs(newMode.vfreq - mode->vfreq);
                                if (newDiff < Diff || Diff == 0) {
                                        if (cs->verbose > 3)
                                                fprintf(stderr, "[%d] Pclock: %d newVfreq: %f - Vfreq: %f newDiff = %f < Diff = %f\n",
                                                        i, newMode.pclock, newMode.vfreq, mode->vfreq, newDiff, Diff);
                                        Diff = newDiff;
                                        vIncr = i;
                                        newPclock = newMode.pclock;     
                                        mode->hactive = newMode.hactive;
                                        mode->hbegin = newMode.hbegin;
                                        mode->hend = newMode.hend;
                                        mode->htotal = newMode.htotal;
                                        if (newDiff < 0.01)
                                                break;
                                }
                        }
                }
                if (newPclock) {
                        mode->vtotal += vIncr;
                        mode->pclock = newPclock;
                } else {
                        mode->hfreq = mode->vfreq * mode->vtotal;
                        ModelineGetLineParams(mode, monitor);
                        mode->pclock = mode->htotal * mode->hfreq;
                }
        }

There were some oddities that might need working out, like in some cases had to revert to the default method of calculation and I should probably still align it in that case to retain the extra value the OS would chop off.  Also abs had to be fabs or else it only works with integers in C, and I break out early when newDiff is what seems like small enough else it didn't seem worth possibly 4 more lines to get .0001 precision which it did in the pacman case (and then broke it going above 312 lines).  Also testing that pacman case is interesting, I can also break it by raising the dotclock another 10000 too, without more lines.  So it's not just the lines that triggers the random wideness, but also or maybe more importantly the dotclock bandwidth or perhaps the Hfreq above 18900 that does it (like 18920 can trigger the issue from what I can tell, but 18900 perfect every time).  I'm wondering if I need to make the cutoff that 1100 Hz lower for that range, currently it's 20000. 
   
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 28, 2010, 01:43:38 pm
Today I won't probably get home till late night so I won't be able to test that yet. I've downloaded and burnt the stuff just in case.

In Windows how can it utilize those ones you calculated, since it stores them in alignment to 10000?  Something this has made me start wondering about, or is it the extra lines doing the work to in theory get to that value?  Also I see basically it goes max 5 lines more, mostly think I ported the code right, for at least the align to a value case, but was some difference I think again in C which made it in somewhat different...

That iterative routine does two things at the same time:

- It uses the dotclock precalcutated values, by picking the aligned to 10000 value that the driver admits, and entering the table to see what will be actually used by the card, to see if we are closer with either that value or the ones right above and below, and...

- Iterates the same calculations with some extra lines, for instance sometimes you can get closer to 60Hz with 263 lines than 262, or say 265, and I wanted to get the best possible combination. However that introduces an incremented hfreq, that has also side effects, that's why I can disable the loop by setting the iterations variable to 0, so the loop is just run once, it still get the right values for the dotclock, but does not iterate.

So you can just forget about iterating but using the right values once. However that (reading the dotclock table, not iterating) could only be interesting in Windows, were we have less accuracy by design, it seems.

It's interesting what you're seeing with pacman, it could turn out to be hfreq the critical factor for your monitor's decisions after all, it would be nice to know that for sure. If just increasing the dotclock is causing that, it really seems it's hfreq the value your monitor is measuring (and that can explain the fuzzy behaviour, as it's not easy to measure that with accuracy in real time).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 28, 2010, 04:51:06 pm
I'm wondering about tuning the PLL clocks better, possibly that is why I'm seeing the slight lower refresh rate happen past 2.6.36.2, seems to have started right after that when they started doing more calculations for the PLL stuff.  There is a min and max, for both out and in, are there optimal values that you know for each of those.  Alex mentioned that basically your tuning the performance for a range, so wouldn't we even benefit from a lower max.  Also what out the input ones, do those need alternate settings possibly?   Besides that there's memory and a few other PLL clocks, curious if you have ideas of values for these and any information on setting up a PLL for ATI video cards.

These seem to be the basic defaults (currently, lowered the min from 12500) for a card greater than an r400...

Code: [Select]
               p1pll->pll_in_min = 100;
                p1pll->pll_in_max = 1350;
                p1pll->pll_out_min = 3000;
                p1pll->pll_out_max = 50000;

The other defaults normally (this is done if card doesn't have preferences)
                p1pll->min_post_div = 2;
                p1pll->max_post_div = 0x7f;
                p1pll->min_frac_feedback_div = 0;
                p1pll->max_frac_feedback_div = 9;


                                p1pll->reference_freq = 2700;
                                p2pll->reference_freq = 2700;
                                spll->reference_freq = 2700;
                                mpll->reference_freq = 2700;

        /* dcpll is DCE4 only */
        dcpll->min_post_div = 2;
        dcpll->max_post_div = 0x7f;
        dcpll->min_frac_feedback_div = 0;
        dcpll->max_frac_feedback_div = 9;
        dcpll->min_ref_div = 2;
        dcpll->max_ref_div = 0x3ff;
        dcpll->min_feedback_div = 4;
        dcpll->max_feedback_div = 0xfff;
        dcpll->best_vco = 0;

        p1pll->min_ref_div = 2;
        p1pll->max_ref_div = 0x3ff;
        p1pll->min_feedback_div = 4;
        p1pll->max_feedback_div = 0x7ff;
        p1pll->best_vco = 0;

        p2pll->min_ref_div = 2;
        p2pll->max_ref_div = 0x3ff;
        p2pll->min_feedback_div = 4;
        p2pll->max_feedback_div = 0x7ff;
        p2pll->best_vco = 0;

        /* system clock */
        spll->min_post_div = 1;
        spll->max_post_div = 1;
        spll->min_ref_div = 2;
        spll->max_ref_div = 0xff;
        spll->min_feedback_div = 4;
        spll->max_feedback_div = 0xff;
        spll->best_vco = 0;

        /* memory clock */
        mpll->min_post_div = 1;
        mpll->max_post_div = 1;
        mpll->min_ref_div = 2;
        mpll->max_ref_div = 0xff;
        mpll->min_feedback_div = 4;
        mpll->max_feedback_div = 0xff;
        mpll->best_vco = 0;

And this part seems like if it's less than 15 it does one thing, but what about lower since they are expecting only down to 12 usually...

Code: [Select]
       if (req_clock < 15000) {
                *post_div = 8;
                req_clock *= 8;
        } else if (req_clock < 30000) {
                *post_div = 4;
                req_clock *= 4;
        } else if (req_clock < 60000) {
                *post_div = 2;
                req_clock *= 2;
        } else
                *post_div = 1;

        req_clock *= ref_div;
        req_clock += spll->reference_freq;
        req_clock /= (2 * spll->reference_freq);

        *fb_div = req_clock & 0xff;

        req_clock = (req_clock & 0xffff) << 1;
        req_clock *= spll->reference_freq;
        req_clock /= ref_div;
        req_clock /= *post_div;



What I've been seeing is basically games run at 100.13% speed in 2.6.36.2 while after that they are around 97-99 depending on the game, so one overshoots slightly then after that they are undershooting quite a bit more sometimes.  They might run smoother though on the later kernel but slower, although that's where if I use 10000 increment alignments of the pixel clock suddenly they run at exactly 100% but then that kills pacman almost always.  I don't know why 10000 is working, when in the kernel code everything is at 1000 granularity, seems strange and suspicious like they are loosing that much more now somewhere.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 29, 2010, 07:55:01 am
That part where the clocks are calculated looks interesting and must have the clue for the granularity we're seeing, if we could understand what's being done I believe I could even guess which values are being used in Windows that are behind the results I have in that table, and would be great to be able to calculate those instead of having a table. However that C syntax is sticky and a pain for me, that way of writting stuff like += *= /= can be handy but is hiding the actual equations logic, I'll have a look anyway. Where's the 'ref_div' value defined?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 29, 2010, 10:59:07 am
That part where the clocks are calculated looks interesting and must have the clue for the granularity we're seeing, if we could understand what's being done I believe I could even guess which values are being used in Windows that are behind the results I have in that table, and would be great to be able to calculate those instead of having a table. However that C syntax is sticky and a pain for me, that way of writting stuff like += *= /= can be handy but is hiding the actual equations logic, I'll have a look anyway. Where's the 'ref_div' value defined?

It looks like it most of the time comes from the bios itself, this value of reference_div below is what gets set to ref_div or else it also again checks the bios for it.   Here you can see though if they can't get it from the bios, or it's below 2, then it set to 12.  So 12 seems like the default for it.

Code: [Select]
               if (p1pll->reference_div < 2) {
                        if (!ASIC_IS_AVIVO(rdev)) {
                                u32 tmp = RREG32_PLL(RADEON_PPLL_REF_DIV);
                                if (ASIC_IS_R300(rdev))
                                        p1pll->reference_div =
                                                (tmp & R300_PPLL_REF_DIV_ACC_MASK) >> R300_PPLL_REF_DIV_ACC_SHIFT;
                                else
                                        p1pll->reference_div = tmp & RADEON_PPLL_REF_DIV_MASK;
                                if (p1pll->reference_div < 2)
                                        p1pll->reference_div = 12;
                        } else
                                p1pll->reference_div = 12;
                }
                if (p2pll->reference_div < 2)
                        p2pll->reference_div = 12;
                if (rdev->family < CHIP_RS600) {
                        if (spll->reference_div < 2)
                                spll->reference_div =
                                        RREG32_PLL(RADEON_M_SPLL_REF_FB_DIV) &
                                        RADEON_M_SPLL_REF_DIV_MASK;
                }
                if (mpll->reference_div < 2)
                        mpll->reference_div = spll->reference_div;



Also interesting that I've found the newest linux-next drm code seems to actually be getting exactly the right refresh rate and game speed, but there's a problem.  For some reason it takes up just a bit more CPU than before, although I'm hoping it's the rest of the kernel doing that part.  Basically it runs fine for most games, but for virtua racer it hits the CPU top (for me) of one of my dual cores and really wants 120% CPU where before it used about 90% max.  So there's a bit more CPU usage, not out of control, but everything looks to be a little heavier load.  I'm going to test the newer DRM put into the stable kernel (just figured out I could pull the DRM code out and replace it into older kernels), since if that CPU issue goes away it looks really good.  Also the latency of button pushing I saw, was my switch in my button, cheap zippy switch in there seems to have already gotten slow and a new one fixed the issue.  Ordered some of those micro leaf ones, just glad that really wasn't the issue I thought since that was really starting to become a vague problem I had no idea how to go about fixing :/.

The main file all that code is in is the radeon_clocks.c file:
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=radeon/radeon_clocks.c;h=5249af8931e60549e01362102f9c8ca941ba0d24;hb=HEAD (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=radeon/radeon_clocks.c;h=5249af8931e60549e01362102f9c8ca941ba0d24;hb=HEAD)

Also it references the radeon_atombios.c file for getting values from the bios (about line 1079 this is where it starts getting interesting):
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=radeon/radeon_atombios.c;h=bc5a2c3382d92fbd10efca3f29f69a927e381fc0;hb=HEAD (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=radeon/radeon_atombios.c;h=bc5a2c3382d92fbd10efca3f29f69a927e381fc0;hb=HEAD)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 29, 2010, 11:34:13 am
Thanks a lot for the references, I'll have a look. Also today I'll hopefully test the other stuff, new iso and switchres, I'm eager to see it dealing with vertical games.

That CPU usage increase... could it be due to the way it's performing vsync now? In that case it would come from the new drm part...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 29, 2010, 12:02:34 pm
Thanks a lot for the references, I'll have a look. Also today I'll hopefully test the other stuff, new iso and switchres, I'm eager to see it dealing with vertical games.

That CPU usage increase... could it be due to the way it's performing vsync now? In that case it would come from the new drm part...

Yeah that's what I kinda thought too could be a possibility.  They just put in a bunch of stuff that can do exact timestamping of each vblank, fully know what line it's on at all times I guess.  Could be now that things are really pushing out every single frame/line in time that games like virtua racer just need more CPU to do that.  Everything looks great and virtua racer plays great, just a choppy audio running at 90% or so (if I had a bigger CPU, it's 1.8Ghz each core, or if vsyncwait worked with multithreading in mame, things would be fine).  That's one thing I'm wondering too, why must multi threading be turned off for vsyncwait, is it a hard limitation or is it just being lazy and could be coded to handle more processors in mame.  That would really improve the vsync stuff, but can see too where it might just go against the whole way that works too for multiple threads to be used unless there was a way to time them together.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 29, 2010, 12:28:20 pm
Yeah that's what I kinda thought too could be a possibility.  They just put in a bunch of stuff that can do exact timestamping of each vblank, fully know what line it's on at all times I guess.  Could be now that things are really pushing out every single frame/line in time that games like virtua racer just need more CPU to do that.  Everything looks great and virtua racer plays great, just a choppy audio running at 90% or so (if I had a bigger CPU, it's 1.8Ghz each core, or if vsyncwait worked with multithreading in mame, things would be fine).  That's one thing I'm wondering too, why must multi threading be turned off for vsyncwait, is it a hard limitation or is it just being lazy and could be coded to handle more processors in mame.  That would really improve the vsync stuff, but can see too where it might just go against the whole way that works too for multiple threads to be used unless there was a way to time them together.

That's interesting, I didn't know that multithreading had to be turned off for vsyncwait. I was thinking that when you request the system for vsync, it must start a thread somewhere to keep an eye on the hardware ports that return the retrace state. Depending on how that's done, that loop could eat all the cpu cycles in the worst case (it's not that simple). For instance, in my experience, triplebuffer is much lighter for cpu that a normal waitvsync, as the cpu can start working with the next frame right after it dispatches the previous one.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 29, 2010, 05:41:52 pm
I wanted to test the latest iso but the damned machine does not read the cd (I'm using a cd-rw as I run out of cds, so I'll try again with a normal one).

So I've been testing Switchres for Windows, with the new stuff for vertical games and 120 modes. This thing is really impressive now. Even in the good old times of AdvanceMame this was never achieved. This is the mode table I'm using now, it still needs some optimization however, some of them could be redundant:

Code: [Select]
Modeline "184x192_60 15.70KHz 60.16Hz" 3.890 184 192 216 248 192 218 221 261 -hsync -vsync
Modeline "184x208_60 15.70KHz 60.16Hz" 3.890 184 192 216 248 208 226 229 261 -hsync -vsync
Modeline "192x208_60 15.69KHz 60.13Hz" 4.010 192 200 224 256 208 226 229 261 -hsync -vsync
Modeline "192x224_60 15.69KHz 60.13Hz" 4.010 192 200 224 256 224 234 237 261 -hsync -vsync
Modeline "208x208_60 15.67KHz 60.04Hz" 4.380 208 216 240 280 208 226 229 261 -hsync -vsync
Modeline "216x224_60 15.68KHz 60.07Hz" 4.640 216 232 256 296 224 234 237 261 -hsync -vsync
Modeline "224x240_60 15.67KHz 60.05Hz" 4.760 224 240 264 304 240 242 245 261 -hsync -vsync
Modeline "232x224_60 15.68KHz 60.09Hz" 4.890 232 248 272 312 224 234 237 261 -hsync -vsync
Modeline "240x192_60 15.66KHz 60.00Hz" 5.010 240 256 280 320 192 218 221 261 -hsync -vsync
Modeline "240x224_60 15.66KHz 60.00Hz" 5.010 240 256 280 320 224 234 237 261 -hsync -vsync
Modeline "240x240_60 15.66KHz 60.00Hz" 5.010 240 256 280 320 240 242 245 261 -hsync -vsync
Modeline "240x256_60 16.65KHz 60.12Hz" 5.590 240 256 288 336 256 257 260 277 -hsync -vsync
Modeline "248x224_60 15.69KHz 60.13Hz" 5.270 248 264 288 336 224 234 237 261 -hsync -vsync
Modeline "248x240_60 15.69KHz 60.13Hz" 5.270 248 264 288 336 240 242 245 261 -hsync -vsync
Modeline "248x256_60 16.64KHz 60.06Hz" 5.720 248 264 296 344 256 257 260 277 -hsync -vsync
Modeline "256x192_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 192 218 221 261 -hsync -vsync
Modeline "256x208_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 208 226 229 261 -hsync -vsync
Modeline "256x224_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 224 234 237 261 -hsync -vsync
Modeline "256x240_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 240 242 245 261 -hsync -vsync
Modeline "256x256_60 16.65KHz 60.12Hz" 5.860 256 272 304 352 256 257 260 277 -hsync -vsync
Modeline "256x288_54 16.68KHz 53.99Hz" 5.870 256 272 304 352 288 289 292 309 -hsync -vsync
Modeline "256x512_60 16.65KHz 60.01Hz" 5.860 256 272 304 352 512 514 519 555 interlace -hsync -vsync
Modeline "264x224_60 15.67KHz 60.02Hz" 5.630 264 280 312 360 224 234 237 261 -hsync -vsync
Modeline "264x240_60 15.67KHz 60.02Hz" 5.630 264 280 312 360 240 242 245 261 -hsync -vsync
Modeline "272x224_60 15.67KHz 60.03Hz" 5.760 272 288 320 368 224 234 237 261 -hsync -vsync
Modeline "272x240_60 15.67KHz 60.03Hz" 5.760 272 288 320 368 240 242 245 261 -hsync -vsync
Modeline "280x224_60 15.71KHz 60.18Hz" 5.890 280 296 328 376 224 234 237 261 -hsync -vsync
Modeline "280x240_60 15.71KHz 60.18Hz" 5.890 280 296 328 376 240 242 245 261 -hsync -vsync
Modeline "288x208_60 15.69KHz 60.13Hz" 6.020 288 304 336 384 208 226 229 261 -hsync -vsync
Modeline "288x224_60 15.69KHz 60.13Hz" 6.020 288 304 336 384 224 234 237 261 -hsync -vsync
Modeline "288x240_60 15.69KHz 60.13Hz" 6.020 288 304 336 384 240 242 245 261 -hsync -vsync
Modeline "296x224_60 15.68KHz 60.08Hz" 6.140 296 312 344 392 224 234 237 261 -hsync -vsync
Modeline "296x240_60 15.68KHz 60.08Hz" 6.140 296 312 344 392 240 242 245 261 -hsync -vsync
Modeline "304x224_60 15.67KHz 60.05Hz" 6.390 304 320 352 408 224 234 237 261 -hsync -vsync
Modeline "304x240_60 15.67KHz 60.05Hz" 6.390 304 320 352 408 240 242 245 261 -hsync -vsync
Modeline "320x192_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 192 218 221 261 -hsync -vsync
Modeline "320x208_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 208 226 229 261 -hsync -vsync
Modeline "320x224_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 224 234 237 261 -hsync -vsync
Modeline "320x240_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 240 242 245 261 -hsync -vsync
Modeline "320x256_60 16.62KHz 60.01Hz" 7.040 320 336 368 424 256 257 260 277 -hsync -vsync
Modeline "328x224_60 15.72KHz 60.21Hz" 6.780 328 344 376 432 224 234 237 261 -hsync -vsync
Modeline "328x256_60 16.64KHz 60.06Hz" 7.450 328 344 384 448 256 257 260 277 -hsync -vsync
Modeline "336x240_60 15.66KHz 60.00Hz" 6.890 336 352 384 440 240 242 245 261 -hsync -vsync
Modeline "336x256_60 16.65KHz 60.12Hz" 7.580 336 352 392 456 256 257 260 277 -hsync -vsync
Modeline "344x240_60 15.66KHz 60.01Hz" 7.010 344 360 392 448 240 242 245 261 -hsync -vsync
Modeline "344x256_60 16.63KHz 60.02Hz" 7.710 344 360 400 464 256 257 260 277 -hsync -vsync
Modeline "352x224_60 15.68KHz 60.06Hz" 7.390 352 368 408 472 224 234 237 261 -hsync -vsync
Modeline "352x240_60 15.68KHz 60.06Hz" 7.390 352 368 408 472 240 242 245 261 -hsync -vsync
Modeline "352x256_60 16.63KHz 60.04Hz" 7.850 352 368 408 472 256 257 260 277 -hsync -vsync
Modeline "360x224_60 15.66KHz 60.00Hz" 7.510 360 376 416 480 224 234 237 261 -hsync -vsync
Modeline "360x240_60 15.66KHz 60.00Hz" 7.510 360 376 416 480 240 242 245 261 -hsync -vsync
Modeline "368x240_60 15.66KHz 60.01Hz" 7.640 368 384 424 488 240 242 245 261 -hsync -vsync
Modeline "368x256_60 16.66KHz 60.15Hz" 8.130 368 384 424 488 256 257 260 277 -hsync -vsync
Modeline "368x448_60 15.65KHz 60.08Hz" 7.630 368 384 424 488 448 466 471 521 interlace -hsync -vsync
Modeline "376x240_60 15.68KHz 60.07Hz" 7.770 376 392 432 496 240 242 245 261 -hsync -vsync
Modeline "376x256_60 16.63KHz 60.03Hz" 8.390 376 392 432 504 256 257 260 277 -hsync -vsync
Modeline "376x272_57 16.74KHz 57.14Hz" 8.430 376 392 432 504 272 273 276 293 -hsync -vsync
Modeline "384x224_60 15.67KHz 60.04Hz" 7.890 384 400 440 504 224 234 237 261 -hsync -vsync
Modeline "384x240_60 15.67KHz 60.04Hz" 7.890 384 400 440 504 240 242 245 261 -hsync -vsync
Modeline "384x256_60 16.64KHz 60.06Hz" 8.500 384 400 440 512 256 257 260 277 -hsync -vsync
Modeline "384x288_54 16.67KHz 53.96Hz" 8.520 384 400 440 512 288 289 292 309 -hsync -vsync
Modeline "400x224_60 15.68KHz 60.09Hz" 8.150 400 416 456 520 224 234 237 261 -hsync -vsync
Modeline "400x240_60 15.68KHz 60.09Hz" 8.150 400 416 456 520 240 242 245 261 -hsync -vsync
Modeline "400x248_60 16.15KHz 60.03Hz" 8.510 400 416 456 528 248 250 253 269 -hsync -vsync
Modeline "400x256_60 16.66KHz 60.16Hz" 8.790 400 416 456 528 256 257 260 277 -hsync -vsync
Modeline "400x264_59 16.69KHz 58.56Hz" 8.810 400 416 456 528 264 265 268 285 -hsync -vsync
Modeline "400x272_57 16.69KHz 56.96Hz" 8.810 400 416 456 528 272 273 276 293 -hsync -vsync
Modeline "400x280_55 16.69KHz 55.45Hz" 8.810 400 416 456 528 280 281 284 301 -hsync -vsync
Modeline "400x288_54 16.69KHz 54.01Hz" 8.810 400 416 456 528 288 289 292 309 -hsync -vsync
Modeline "416x208_60 15.67KHz 60.05Hz" 8.510 416 432 472 544 208 226 229 261 -hsync -vsync
Modeline "416x224_60 15.67KHz 60.05Hz" 8.510 416 432 472 544 224 234 237 261 -hsync -vsync
Modeline "416x256_60 16.64KHz 60.06Hz" 9.450 416 440 488 568 256 257 260 277 -hsync -vsync
Modeline "432x224_60 15.67KHz 60.04Hz" 8.760 432 448 488 560 224 234 237 261 -hsync -vsync
Modeline "432x240_60 15.67KHz 60.04Hz" 8.760 432 448 488 560 240 242 245 261 -hsync -vsync
Modeline "432x248_60 16.18KHz 60.15Hz" 9.450 432 456 504 584 248 250 253 269 -hsync -vsync
Modeline "432x256_60 16.67KHz 60.18Hz" 9.720 432 456 504 584 256 257 260 277 -hsync -vsync
Modeline "432x264_58 16.67KHz 58.49Hz" 9.720 432 456 504 584 264 265 268 285 -hsync -vsync
Modeline "432x272_57 16.67KHz 56.89Hz" 9.720 432 456 504 584 272 273 276 293 -hsync -vsync
Modeline "432x280_55 16.67KHz 55.38Hz" 9.720 432 456 504 584 280 281 284 301 -hsync -vsync
Modeline "448x224_60 15.67KHz 60.04Hz" 9.400 448 472 520 600 224 234 237 261 -hsync -vsync
Modeline "448x240_60 15.67KHz 60.04Hz" 9.400 448 472 520 600 240 242 245 261 -hsync -vsync
Modeline "456x240_60 15.66KHz 60.01Hz" 9.530 456 480 528 608 240 242 245 261 -hsync -vsync
Modeline "456x256_60 16.65KHz 60.12Hz" 10.110 456 480 528 608 256 257 260 277 -hsync -vsync
Modeline "464x224_60 15.69KHz 60.11Hz" 9.660 464 488 536 616 224 234 237 261 -hsync -vsync
Modeline "464x256_60 16.63KHz 60.04Hz" 10.230 464 488 536 616 256 257 260 277 -hsync -vsync
Modeline "480x224_60 15.69KHz 60.10Hz" 9.910 480 504 552 632 224 234 237 261 -hsync -vsync
Modeline "480x240_60 15.69KHz 60.10Hz" 9.910 480 504 552 632 240 242 245 261 -hsync -vsync
Modeline "480x464_60 15.64KHz 60.03Hz" 9.880 480 504 552 632 464 474 479 521 interlace -hsync -vsync
Modeline "480x480_60 15.64KHz 60.03Hz" 9.880 480 504 552 632 480 482 487 521 interlace -hsync -vsync
Modeline "496x224_60 15.69KHz 60.13Hz" 10.150 496 520 568 648 224 234 237 261 -hsync -vsync
Modeline "496x240_60 15.69KHz 60.13Hz" 10.150 496 520 568 648 240 242 245 261 -hsync -vsync
Modeline "496x480_60 15.69KHz 60.24Hz" 10.150 496 520 568 648 480 482 487 521 interlace -hsync -vsync
Modeline "512x224_60 15.69KHz 60.13Hz" 10.530 512 536 584 672 224 234 237 261 -hsync -vsync
Modeline "512x240_60 15.69KHz 60.13Hz" 10.530 512 536 584 672 240 242 245 261 -hsync -vsync
Modeline "512x256_60 16.62KHz 60.01Hz" 11.420 512 536 592 688 256 257 260 277 -hsync -vsync
Modeline "512x288_54 16.68KHz 53.98Hz" 11.470 512 536 592 688 288 289 292 309 -hsync -vsync
Modeline "512x448_60 15.65KHz 60.06Hz" 10.520 512 536 584 672 448 466 471 521 interlace -hsync -vsync
Modeline "512x480_60 15.65KHz 60.06Hz" 10.520 512 536 584 672 480 482 487 521 interlace -hsync -vsync
Modeline "512x512_60 16.68KHz 60.10Hz" 11.470 512 536 592 688 512 514 519 555 interlace -hsync -vsync
Modeline "544x256_60 16.64KHz 60.07Hz" 11.980 544 568 624 720 256 257 260 277 -hsync -vsync
Modeline "544x480_60 15.64KHz 60.05Hz" 11.130 544 568 624 712 480 482 487 521 interlace -hsync -vsync
Modeline "640x208_60 15.67KHz 60.05Hz" 13.040 640 664 728 832 208 226 229 261 -hsync -vsync
Modeline "640x240_60 15.67KHz 60.05Hz" 13.040 640 664 728 832 240 242 245 261 -hsync -vsync
Modeline "640x256_60 16.64KHz 60.08Hz" 14.100 640 672 736 848 256 257 260 277 -hsync -vsync
Modeline "640x480_60 15.65KHz 60.06Hz" 12.990 640 664 728 832 480 482 487 521 interlace -hsync -vsync
Modeline "672x224_60 15.66KHz 60.00Hz" 13.770 672 704 768 880 224 234 237 261 -hsync -vsync
Modeline "672x240_60 15.66KHz 60.00Hz" 13.770 672 704 768 880 240 242 245 261 -hsync -vsync
Modeline "672x272_57 16.68KHz 56.93Hz" 14.940 672 704 776 896 272 273 276 293 -hsync -vsync
Modeline "688x512_60 16.65KHz 60.01Hz" 15.160 688 720 792 912 512 514 519 555 interlace -hsync -vsync
Modeline "704x240_60 15.68KHz 60.09Hz" 14.540 704 736 808 928 240 242 245 261 -hsync -vsync
Modeline "704x480_60 15.64KHz 60.03Hz" 14.500 704 736 808 928 480 482 487 521 interlace -hsync -vsync
Modeline "704x512_60 16.68KHz 60.09Hz" 15.590 704 736 808 936 512 514 519 555 interlace -hsync -vsync
Modeline "712x512_60 16.68KHz 60.12Hz" 15.730 712 744 816 944 512 514 519 555 interlace -hsync -vsync
Modeline "720x512_60 16.66KHz 60.04Hz" 15.850 720 752 824 952 512 514 519 555 interlace -hsync -vsync
Modeline "768x224_60 15.67KHz 60.04Hz" 15.640 768 800 872 1000 224 234 237 261 -hsync -vsync
Modeline "768x480_60 15.65KHz 60.07Hz" 15.630 768 800 872 1000 480 482 487 521 interlace -hsync -vsync
Modeline "800x512_60 16.66KHz 60.05Hz" 17.600 800 832 912 1056 512 514 519 555 interlace -hsync -vsync
Modeline "856x512_60 16.67KHz 60.07Hz" 18.940 856 896 984 1136 512 514 519 555 interlace -hsync -vsync
Modeline "912x512_60 16.66KHz 60.02Hz" 20.160 912 952 1048 1208 512 514 519 555 interlace -hsync -vsync
Modeline "1024x480_60 15.67KHz 60.16Hz" 20.770 1024 1064 1160 1328 480 482 487 521 interlace -hsync -vsync
Modeline "1024x512_60 16.66KHz 60.04Hz" 22.660 1024 1072 1176 1360 512 514 519 555 interlace -hsync -vsync

I'm using --vcalc 0, anyway I can't see any difference among 0 and 2 (1 is wider). Virtualized resolutions look ok now, filling the screen when needed. I'd like to figure out a way to precalculate some virtualized modes for Swichres to use, maybe it could be good to reserve 10 modes to cover 50-60Hz, by 0.1Hz steps, so that they could be tweaked later to fine tune them just a bit. That way I could fully benefit from the higher resolution available for lower vfreqs.

I've managed to config AdvanceMenu to launch Switchres instead of Mame, using this lines:

Code: [Select]
emulator "mame_switchres" generic "c:\Emuladores\Mame\switchres.exe" "%s  --soft15khz --monitor h9110"
emulator_roms "mame_switchres" "c:\Roms\Mame\"
emulator_roms_filter "mame_switchres" "*.zip
emulator_flyers "mame_switchres" "c:\Snaps\Mame\"

(the only disadvantage is that I get the zip names instead of full names in the menu)

Some games which video mode was dropped for being rare when using a static mode table are running now at their native resolution and vfreq, this is very cool.

Something we should add at some point is an option for playing vertical games on full screen, not in a rotated frame. I know people that physically rotate their crts when playing vertical games, they look and feel so much better that way. We should have a way to make that possible (using 'ror 1' and the native resolution).

It would be helpful also to have with the -v option which parameters are being passed to Mame.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 29, 2010, 06:41:45 pm
I wanted to test the latest iso but the damned machine does not read the cd (I'm using a cd-rw as I run out of cds, so I'll try again with a normal one).

So I've been testing Switchres for Windows, with the new stuff for vertical games and 120 modes. This thing is really impressive now. Even in the good old times of AdvanceMame this was never achieved. This is the mode table I'm using now, it still needs some optimization however, some of them could be redundant:

Code: [Select]
Modeline "184x192_60 15.70KHz 60.16Hz" 3.890 184 192 216 248 192 218 221 261 -hsync -vsync
Modeline "184x208_60 15.70KHz 60.16Hz" 3.890 184 192 216 248 208 226 229 261 -hsync -vsync
Modeline "192x208_60 15.69KHz 60.13Hz" 4.010 192 200 224 256 208 226 229 261 -hsync -vsync
Modeline "192x224_60 15.69KHz 60.13Hz" 4.010 192 200 224 256 224 234 237 261 -hsync -vsync
Modeline "208x208_60 15.67KHz 60.04Hz" 4.380 208 216 240 280 208 226 229 261 -hsync -vsync
Modeline "216x224_60 15.68KHz 60.07Hz" 4.640 216 232 256 296 224 234 237 261 -hsync -vsync
Modeline "224x240_60 15.67KHz 60.05Hz" 4.760 224 240 264 304 240 242 245 261 -hsync -vsync
Modeline "232x224_60 15.68KHz 60.09Hz" 4.890 232 248 272 312 224 234 237 261 -hsync -vsync
Modeline "240x192_60 15.66KHz 60.00Hz" 5.010 240 256 280 320 192 218 221 261 -hsync -vsync
Modeline "240x224_60 15.66KHz 60.00Hz" 5.010 240 256 280 320 224 234 237 261 -hsync -vsync
Modeline "240x240_60 15.66KHz 60.00Hz" 5.010 240 256 280 320 240 242 245 261 -hsync -vsync
Modeline "240x256_60 16.65KHz 60.12Hz" 5.590 240 256 288 336 256 257 260 277 -hsync -vsync
Modeline "248x224_60 15.69KHz 60.13Hz" 5.270 248 264 288 336 224 234 237 261 -hsync -vsync
Modeline "248x240_60 15.69KHz 60.13Hz" 5.270 248 264 288 336 240 242 245 261 -hsync -vsync
Modeline "248x256_60 16.64KHz 60.06Hz" 5.720 248 264 296 344 256 257 260 277 -hsync -vsync
Modeline "256x192_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 192 218 221 261 -hsync -vsync
Modeline "256x208_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 208 226 229 261 -hsync -vsync
Modeline "256x224_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 224 234 237 261 -hsync -vsync
Modeline "256x240_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 240 242 245 261 -hsync -vsync
Modeline "256x256_60 16.65KHz 60.12Hz" 5.860 256 272 304 352 256 257 260 277 -hsync -vsync
Modeline "256x288_54 16.68KHz 53.99Hz" 5.870 256 272 304 352 288 289 292 309 -hsync -vsync
Modeline "256x512_60 16.65KHz 60.01Hz" 5.860 256 272 304 352 512 514 519 555 interlace -hsync -vsync
Modeline "264x224_60 15.67KHz 60.02Hz" 5.630 264 280 312 360 224 234 237 261 -hsync -vsync
Modeline "264x240_60 15.67KHz 60.02Hz" 5.630 264 280 312 360 240 242 245 261 -hsync -vsync
Modeline "272x224_60 15.67KHz 60.03Hz" 5.760 272 288 320 368 224 234 237 261 -hsync -vsync
Modeline "272x240_60 15.67KHz 60.03Hz" 5.760 272 288 320 368 240 242 245 261 -hsync -vsync
Modeline "280x224_60 15.71KHz 60.18Hz" 5.890 280 296 328 376 224 234 237 261 -hsync -vsync
Modeline "280x240_60 15.71KHz 60.18Hz" 5.890 280 296 328 376 240 242 245 261 -hsync -vsync
Modeline "288x208_60 15.69KHz 60.13Hz" 6.020 288 304 336 384 208 226 229 261 -hsync -vsync
Modeline "288x224_60 15.69KHz 60.13Hz" 6.020 288 304 336 384 224 234 237 261 -hsync -vsync
Modeline "288x240_60 15.69KHz 60.13Hz" 6.020 288 304 336 384 240 242 245 261 -hsync -vsync
Modeline "296x224_60 15.68KHz 60.08Hz" 6.140 296 312 344 392 224 234 237 261 -hsync -vsync
Modeline "296x240_60 15.68KHz 60.08Hz" 6.140 296 312 344 392 240 242 245 261 -hsync -vsync
Modeline "304x224_60 15.67KHz 60.05Hz" 6.390 304 320 352 408 224 234 237 261 -hsync -vsync
Modeline "304x240_60 15.67KHz 60.05Hz" 6.390 304 320 352 408 240 242 245 261 -hsync -vsync
Modeline "320x192_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 192 218 221 261 -hsync -vsync
Modeline "320x208_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 208 226 229 261 -hsync -vsync
Modeline "320x224_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 224 234 237 261 -hsync -vsync
Modeline "320x240_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 240 242 245 261 -hsync -vsync
Modeline "320x256_60 16.62KHz 60.01Hz" 7.040 320 336 368 424 256 257 260 277 -hsync -vsync
Modeline "328x224_60 15.72KHz 60.21Hz" 6.780 328 344 376 432 224 234 237 261 -hsync -vsync
Modeline "328x256_60 16.64KHz 60.06Hz" 7.450 328 344 384 448 256 257 260 277 -hsync -vsync
Modeline "336x240_60 15.66KHz 60.00Hz" 6.890 336 352 384 440 240 242 245 261 -hsync -vsync
Modeline "336x256_60 16.65KHz 60.12Hz" 7.580 336 352 392 456 256 257 260 277 -hsync -vsync
Modeline "344x240_60 15.66KHz 60.01Hz" 7.010 344 360 392 448 240 242 245 261 -hsync -vsync
Modeline "344x256_60 16.63KHz 60.02Hz" 7.710 344 360 400 464 256 257 260 277 -hsync -vsync
Modeline "352x224_60 15.68KHz 60.06Hz" 7.390 352 368 408 472 224 234 237 261 -hsync -vsync
Modeline "352x240_60 15.68KHz 60.06Hz" 7.390 352 368 408 472 240 242 245 261 -hsync -vsync
Modeline "352x256_60 16.63KHz 60.04Hz" 7.850 352 368 408 472 256 257 260 277 -hsync -vsync
Modeline "360x224_60 15.66KHz 60.00Hz" 7.510 360 376 416 480 224 234 237 261 -hsync -vsync
Modeline "360x240_60 15.66KHz 60.00Hz" 7.510 360 376 416 480 240 242 245 261 -hsync -vsync
Modeline "368x240_60 15.66KHz 60.01Hz" 7.640 368 384 424 488 240 242 245 261 -hsync -vsync
Modeline "368x256_60 16.66KHz 60.15Hz" 8.130 368 384 424 488 256 257 260 277 -hsync -vsync
Modeline "368x448_60 15.65KHz 60.08Hz" 7.630 368 384 424 488 448 466 471 521 interlace -hsync -vsync
Modeline "376x240_60 15.68KHz 60.07Hz" 7.770 376 392 432 496 240 242 245 261 -hsync -vsync
Modeline "376x256_60 16.63KHz 60.03Hz" 8.390 376 392 432 504 256 257 260 277 -hsync -vsync
Modeline "376x272_57 16.74KHz 57.14Hz" 8.430 376 392 432 504 272 273 276 293 -hsync -vsync
Modeline "384x224_60 15.67KHz 60.04Hz" 7.890 384 400 440 504 224 234 237 261 -hsync -vsync
Modeline "384x240_60 15.67KHz 60.04Hz" 7.890 384 400 440 504 240 242 245 261 -hsync -vsync
Modeline "384x256_60 16.64KHz 60.06Hz" 8.500 384 400 440 512 256 257 260 277 -hsync -vsync
Modeline "384x288_54 16.67KHz 53.96Hz" 8.520 384 400 440 512 288 289 292 309 -hsync -vsync
Modeline "400x224_60 15.68KHz 60.09Hz" 8.150 400 416 456 520 224 234 237 261 -hsync -vsync
Modeline "400x240_60 15.68KHz 60.09Hz" 8.150 400 416 456 520 240 242 245 261 -hsync -vsync
Modeline "400x248_60 16.15KHz 60.03Hz" 8.510 400 416 456 528 248 250 253 269 -hsync -vsync
Modeline "400x256_60 16.66KHz 60.16Hz" 8.790 400 416 456 528 256 257 260 277 -hsync -vsync
Modeline "400x264_59 16.69KHz 58.56Hz" 8.810 400 416 456 528 264 265 268 285 -hsync -vsync
Modeline "400x272_57 16.69KHz 56.96Hz" 8.810 400 416 456 528 272 273 276 293 -hsync -vsync
Modeline "400x280_55 16.69KHz 55.45Hz" 8.810 400 416 456 528 280 281 284 301 -hsync -vsync
Modeline "400x288_54 16.69KHz 54.01Hz" 8.810 400 416 456 528 288 289 292 309 -hsync -vsync
Modeline "416x208_60 15.67KHz 60.05Hz" 8.510 416 432 472 544 208 226 229 261 -hsync -vsync
Modeline "416x224_60 15.67KHz 60.05Hz" 8.510 416 432 472 544 224 234 237 261 -hsync -vsync
Modeline "416x256_60 16.64KHz 60.06Hz" 9.450 416 440 488 568 256 257 260 277 -hsync -vsync
Modeline "432x224_60 15.67KHz 60.04Hz" 8.760 432 448 488 560 224 234 237 261 -hsync -vsync
Modeline "432x240_60 15.67KHz 60.04Hz" 8.760 432 448 488 560 240 242 245 261 -hsync -vsync
Modeline "432x248_60 16.18KHz 60.15Hz" 9.450 432 456 504 584 248 250 253 269 -hsync -vsync
Modeline "432x256_60 16.67KHz 60.18Hz" 9.720 432 456 504 584 256 257 260 277 -hsync -vsync
Modeline "432x264_58 16.67KHz 58.49Hz" 9.720 432 456 504 584 264 265 268 285 -hsync -vsync
Modeline "432x272_57 16.67KHz 56.89Hz" 9.720 432 456 504 584 272 273 276 293 -hsync -vsync
Modeline "432x280_55 16.67KHz 55.38Hz" 9.720 432 456 504 584 280 281 284 301 -hsync -vsync
Modeline "448x224_60 15.67KHz 60.04Hz" 9.400 448 472 520 600 224 234 237 261 -hsync -vsync
Modeline "448x240_60 15.67KHz 60.04Hz" 9.400 448 472 520 600 240 242 245 261 -hsync -vsync
Modeline "456x240_60 15.66KHz 60.01Hz" 9.530 456 480 528 608 240 242 245 261 -hsync -vsync
Modeline "456x256_60 16.65KHz 60.12Hz" 10.110 456 480 528 608 256 257 260 277 -hsync -vsync
Modeline "464x224_60 15.69KHz 60.11Hz" 9.660 464 488 536 616 224 234 237 261 -hsync -vsync
Modeline "464x256_60 16.63KHz 60.04Hz" 10.230 464 488 536 616 256 257 260 277 -hsync -vsync
Modeline "480x224_60 15.69KHz 60.10Hz" 9.910 480 504 552 632 224 234 237 261 -hsync -vsync
Modeline "480x240_60 15.69KHz 60.10Hz" 9.910 480 504 552 632 240 242 245 261 -hsync -vsync
Modeline "480x464_60 15.64KHz 60.03Hz" 9.880 480 504 552 632 464 474 479 521 interlace -hsync -vsync
Modeline "480x480_60 15.64KHz 60.03Hz" 9.880 480 504 552 632 480 482 487 521 interlace -hsync -vsync
Modeline "496x224_60 15.69KHz 60.13Hz" 10.150 496 520 568 648 224 234 237 261 -hsync -vsync
Modeline "496x240_60 15.69KHz 60.13Hz" 10.150 496 520 568 648 240 242 245 261 -hsync -vsync
Modeline "496x480_60 15.69KHz 60.24Hz" 10.150 496 520 568 648 480 482 487 521 interlace -hsync -vsync
Modeline "512x224_60 15.69KHz 60.13Hz" 10.530 512 536 584 672 224 234 237 261 -hsync -vsync
Modeline "512x240_60 15.69KHz 60.13Hz" 10.530 512 536 584 672 240 242 245 261 -hsync -vsync
Modeline "512x256_60 16.62KHz 60.01Hz" 11.420 512 536 592 688 256 257 260 277 -hsync -vsync
Modeline "512x288_54 16.68KHz 53.98Hz" 11.470 512 536 592 688 288 289 292 309 -hsync -vsync
Modeline "512x448_60 15.65KHz 60.06Hz" 10.520 512 536 584 672 448 466 471 521 interlace -hsync -vsync
Modeline "512x480_60 15.65KHz 60.06Hz" 10.520 512 536 584 672 480 482 487 521 interlace -hsync -vsync
Modeline "512x512_60 16.68KHz 60.10Hz" 11.470 512 536 592 688 512 514 519 555 interlace -hsync -vsync
Modeline "544x256_60 16.64KHz 60.07Hz" 11.980 544 568 624 720 256 257 260 277 -hsync -vsync
Modeline "544x480_60 15.64KHz 60.05Hz" 11.130 544 568 624 712 480 482 487 521 interlace -hsync -vsync
Modeline "640x208_60 15.67KHz 60.05Hz" 13.040 640 664 728 832 208 226 229 261 -hsync -vsync
Modeline "640x240_60 15.67KHz 60.05Hz" 13.040 640 664 728 832 240 242 245 261 -hsync -vsync
Modeline "640x256_60 16.64KHz 60.08Hz" 14.100 640 672 736 848 256 257 260 277 -hsync -vsync
Modeline "640x480_60 15.65KHz 60.06Hz" 12.990 640 664 728 832 480 482 487 521 interlace -hsync -vsync
Modeline "672x224_60 15.66KHz 60.00Hz" 13.770 672 704 768 880 224 234 237 261 -hsync -vsync
Modeline "672x240_60 15.66KHz 60.00Hz" 13.770 672 704 768 880 240 242 245 261 -hsync -vsync
Modeline "672x272_57 16.68KHz 56.93Hz" 14.940 672 704 776 896 272 273 276 293 -hsync -vsync
Modeline "688x512_60 16.65KHz 60.01Hz" 15.160 688 720 792 912 512 514 519 555 interlace -hsync -vsync
Modeline "704x240_60 15.68KHz 60.09Hz" 14.540 704 736 808 928 240 242 245 261 -hsync -vsync
Modeline "704x480_60 15.64KHz 60.03Hz" 14.500 704 736 808 928 480 482 487 521 interlace -hsync -vsync
Modeline "704x512_60 16.68KHz 60.09Hz" 15.590 704 736 808 936 512 514 519 555 interlace -hsync -vsync
Modeline "712x512_60 16.68KHz 60.12Hz" 15.730 712 744 816 944 512 514 519 555 interlace -hsync -vsync
Modeline "720x512_60 16.66KHz 60.04Hz" 15.850 720 752 824 952 512 514 519 555 interlace -hsync -vsync
Modeline "768x224_60 15.67KHz 60.04Hz" 15.640 768 800 872 1000 224 234 237 261 -hsync -vsync
Modeline "768x480_60 15.65KHz 60.07Hz" 15.630 768 800 872 1000 480 482 487 521 interlace -hsync -vsync
Modeline "800x512_60 16.66KHz 60.05Hz" 17.600 800 832 912 1056 512 514 519 555 interlace -hsync -vsync
Modeline "856x512_60 16.67KHz 60.07Hz" 18.940 856 896 984 1136 512 514 519 555 interlace -hsync -vsync
Modeline "912x512_60 16.66KHz 60.02Hz" 20.160 912 952 1048 1208 512 514 519 555 interlace -hsync -vsync
Modeline "1024x480_60 15.67KHz 60.16Hz" 20.770 1024 1064 1160 1328 480 482 487 521 interlace -hsync -vsync
Modeline "1024x512_60 16.66KHz 60.04Hz" 22.660 1024 1072 1176 1360 512 514 519 555 interlace -hsync -vsync

I'm using --vcalc 0, anyway I can't see any difference among 0 and 2 (1 is wider). Virtualized resolutions look ok now, filling the screen when needed. I'd like to figure out a way to precalculate some virtualized modes for Swichres to use, maybe it could be good to reserve 10 modes to cover 50-60Hz, by 0.1Hz steps, so that they could be tweaked later to fine tune them just a bit. That way I could fully benefit from the higher resolution available for lower vfreqs.

I've managed to config AdvanceMenu to launch Switchres instead of Mame, using this lines:

Code: [Select]
emulator "mame_switchres" generic "c:\Emuladores\Mame\switchres.exe" "%s  --soft15khz --monitor h9110"
emulator_roms "mame_switchres" "c:\Roms\Mame\"
emulator_roms_filter "mame_switchres" "*.zip
emulator_flyers "mame_switchres" "c:\Snaps\Mame\"

(the only disadvantage is that I get the zip names instead of full names in the menu)

Some games which video mode was dropped for being rare when using a static mode table are running now at their native resolution and vfreq, this is very cool.

Something we should add at some point is an option for playing vertical games on full screen, not in a rotated frame. I know people that physically rotate their crts when playing vertical games, they look and feel so much better that way. We should have a way to make that possible (using 'ror 1' and the native resolution).

It would be helpful also to have with the -v option which parameters are being passed to Mame.


The 2 option for vcalc is really just hardcoded like lrmc did it, 0 is doing it the way you did instead so it's more dynamic but most likely always the same.  If you use 3, well then it won't actually change the width at all, I'm not sure but that might somewhat help the vertical monitor case?  I figure there's more checks involved, had thought about getting that eventually figured out.

If you use the -v option 2-3 times (-v -v -v) or more, it should show the exact mame command line it's using. 

Sounds like the issue your seeing on the 4350 has something to do with this...
https://bugs.freedesktop.org/show_bug.cgi?id=28410
Alex sent that to me, and said he hasn't had time to look closer but needs to find where it's most likely getting outputs confused listening to the vblank interrupts on the wrong output and so never gets them in your case where the monitor isn't detected.

Also I have proven the CPU usage speed up is in the DRM code, put the newest DRM into the stable kernel and it runs the same with the extra CPU, so I mentioned that to Alex to see what he says.  Would be nice to figure out how to do the multithreading in mame better, if possible, so it still could do vsync waiting and  use multi threading.  I looked at that code some, will probably take awhile for me to figure out how it exactly works, seems confusing.  It'll be interesting to see if this really is just overhead for how exact it seems to be working now, definitely hitting it at 100% exactly or if anything 100.1% but it's quite small compared to the .13 or close to 3% in the stable vs. the other kernels before the newest -next version.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on December 30, 2010, 05:45:05 am
Feature request/Bugfix!

I've been tinkering with this on my cab. So far it's worked great.... from the command line. It's almost a direct drop in to use in my front end, Hyperspin with one caveat: Hyperspin wants to pass the romname as ROM.zip and there appears to be no way to have it not send the .zip part. Specifiying no extension still passes the . at the end. Switchres fails to identify the game (eg: "puckman.") and passes it straight on to mame in this format, but mame seems to figure it out and load anyway, however at that point switchres has passed on a bogus resolution (in my case, 640x480@60).

So if you can just have it ignore anything after a . in the rom argument I think works. I don't think there are any characters in official rom names that are outside of a-z.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 30, 2010, 11:37:00 am
Feature request/Bugfix!

I've been tinkering with this on my cab. So far it's worked great.... from the command line. It's almost a direct drop in to use in my front end, Hyperspin with one caveat: Hyperspin wants to pass the romname as ROM.zip and there appears to be no way to have it not send the .zip part. Specifiying no extension still passes the . at the end. Switchres fails to identify the game (eg: "puckman.") and passes it straight on to mame in this format, but mame seems to figure it out and load anyway, however at that point switchres has passed on a bogus resolution (in my case, 640x480@60).

So if you can just have it ignore anything after a . in the rom argument I think works. I don't think there are any characters in official rom names that are outside of a-z.

I just uploaded new binary versions, SwitchResWin-1.240-014952b.7z, which fixes this and removes anything after the main rom name.

Also note that this version no longer needs any extra .dll files besides the cygwin1.dll, it's now statically compiled with the others in the switchres.exe (should slightly improve run time speed in theory too, very small though probably in microseconds increase).

Thanks for the bug report and glad it's working good for you so far.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on December 30, 2010, 11:47:31 am
Feature request/Bugfix!

I've been tinkering with this on my cab. So far it's worked great.... from the command line. It's almost a direct drop in to use in my front end, Hyperspin with one caveat: Hyperspin wants to pass the romname as ROM.zip and there appears to be no way to have it not send the .zip part. Specifiying no extension still passes the . at the end. Switchres fails to identify the game (eg: "puckman.") and passes it straight on to mame in this format, but mame seems to figure it out and load anyway, however at that point switchres has passed on a bogus resolution (in my case, 640x480@60).

So if you can just have it ignore anything after a . in the rom argument I think works. I don't think there are any characters in official rom names that are outside of a-z.

I just uploaded new binary versions, SwitchResWin-1.240-014952b.7z, which fixes this and removes anything after the main rom name.

Also note that this version no longer needs any extra .dll files besides the cygwin1.dll, it's now statically compiled with the others in the switchres.exe (should slightly improve run time speed in theory too, very small though probably in microseconds increase).

Thanks for the bug report and glad it's working good for you so far.

Thanks for the quick fix. I'll be giving it a try at my earliest convenience.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 30, 2010, 12:48:26 pm
The 2 option for vcalc is really just hardcoded like lrmc did it, 0 is doing it the way you did instead so it's more dynamic but most likely always the same.  If you use 3, well then it won't actually change the width at all, I'm not sure but that might somewhat help the vertical monitor case?  I figure there's more checks involved, had thought about getting that eventually figured out.

If you use the -v option 2-3 times (-v -v -v) or more, it should show the exact mame command line it's using.  

Sounds like the issue your seeing on the 4350 has something to do with this...
https://bugs.freedesktop.org/show_bug.cgi?id=28410
Alex sent that to me, and said he hasn't had time to look closer but needs to find where it's most likely getting outputs confused listening to the vblank interrupts on the wrong output and so never gets them in your case where the monitor isn't detected.

Also I have proven the CPU usage speed up is in the DRM code, put the newest DRM into the stable kernel and it runs the same with the extra CPU, so I mentioned that to Alex to see what he says.  Would be nice to figure out how to do the multithreading in mame better, if possible, so it still could do vsync waiting and  use multi threading.  I looked at that code some, will probably take awhile for me to figure out how it exactly works, seems confusing.  It'll be interesting to see if this really is just overhead for how exact it seems to be working now, definitely hitting it at 100% exactly or if anything 100.1% but it's quite small compared to the .13 or close to 3% in the stable vs. the other kernels before the newest -next version.

I'll try adding -v but I was already using 3 of them for sure, and remember to have seen those Mame params in earlier versions, that's why I thought you had removed it.

I'll have a look at the vertical options. The rotating monitor option should have two special cases, one is when you rotate the monitor but not the desktop, then you have to use the resolution values as if it was a horizontal game (not swapping them) but add the -ror 1 param to instruct Mame to render the frame portrait oriented. Second case is for people who rotate the monitor and the desktop at the same time, so you have to keep the original h/w values as before but now you don't have to pass the -ror 1 param as Mame already takes the portrait orientation from the desktop when it's run.

If we want to respect the user's preference for vertical games both for the normal or virtualized case, we need to explicitly pass Mame the aspect ratio we want for the virtualized case. For the -vcalc 0 case, it would be -aspect 3:4 (it's the default, so it's not necessary; with SDL keepaspect has the same effect). But for 'wider' ratios then you need to pass, i.e. -aspect 3:3 (square), etc.

That OpenGL bug definitely has something to do with what I'm seeing, and seems to be out there for some months already. Hopefully someone can figure out how to solve it.

I've done some multithreading programming in the past, but only targeted on a single processor. This is just a thought, haven't seen the code at all, but the problem I see with multithreading on multiple processors in an emulator like Mame, is that you really don't want to have two frames rendered in paralell or something like that. What is important when doing vsync, is to be able to render the frame as quick as you can because to have to do it all between two vblanks, if you want to keep your input synced with the action. However, in the real hardware there are chips and processors actually working in paralell, i.e the audio chips, so performance could be improved having different hardware parts being emulated by different processors while mantaining the 1 frame at a time way. I don't know what the actual approach they are using in Mame.

Good news that we only have a dll there now! It was damned fast already before that, but dependencies are always ugly.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on December 30, 2010, 02:03:22 pm
I had a moment to play with it while at lunch and it initially did not launch properly from Hyperspin. I'll have to look more closely at my configuration to see what's going wrong. I'm thinking that there must be some other mame INI being read also when launched from the front end, as it also did not throttle the game.


I attempted to run Crystal Castles (ccastles.zip) from the command line and it threw a Direct Draw error. I didn't have time to catch the resolution it was attempting to run it at; but maws has it listed at 319x255. I'll look into that later.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 30, 2010, 04:04:52 pm
I finally could test the 1.127 iso, I can see there's just an audio card available in the setup menu (VIA audio), I select that one, but I don't have sound yet in Mame. I've run alsaconf, and the gnome alsa mixer, and it's interesting that I can only see the capture tab of this card:

(http://img227.imageshack.us/img227/1861/30122010259.jpg) (http://img227.imageshack.us/i/30122010259.jpg/)

There's still an ATI tab but it's empty.

I've attached the logs. Mame log is saying there's no audio device available.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 30, 2010, 05:06:02 pm
I finally could test the 1.127 iso, I can see there's just an audio card available in the setup menu (VIA audio), I select that one, but I don't have sound yet in Mame. I've run alsaconf, and the gnome alsa mixer, and it's interesting that I can only see the capture tab of this card:
...

There's still an ATI tab but it's empty.

I've attached the logs. Mame log is saying there's no audio device available.

Seems others have an issue with that card, looks like either it interacts badly with the ATI HDMI audio and/or just has issues with Alsa drivers.

I have some drivers I'm looking at from the manufacturer Realtek that seem interesting, possibly could be better to use them.  Also of course OSS4 might do better too, although I need to figure out how to run it right on the liveCD since it tries some odd things writing to /usr/lib/oss/etc/ which we can't on the liveCD (I think I fixed it but haven't tested, then also I have to blacklist all alsa modules to enable it correctly, probably will only be able to boot either OSS or Alsa I think, so not able to switch back and forth).

Here's something to try on the 4350 to get some good debug information, best to do this command, run glxgears, then use 0x00 to turn off debugging.  That way while glxgears is stuck you will get only the log information up to the issue...

echo 0xffff > /sys/module/drm/parameters/debug

<run glxgears here>

echo 0      > /sys/module/drm/parameters/debug


It should produce a ton of messages, so don't run it for too long or the logs will be very large :)



Good news though, besides the increased CPU usage with the newest DRM code, it does run at exactly 100% or 99.9% at worst case.  So seems like the exactness is there with the refresh rate and running mame, and it plays very nice and smooth. It seems to me like this possibly could be the side effect of page flipping perfectly, but waiting for Alex to confirm that since still seems odd to close to double CPU usage from that (even glxgears does so it's outside of mame).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 30, 2010, 05:26:08 pm
echo 0xffff > /sys/module/drm/parameters/debug

bash:  /sys/module/drm/parameters/debug: Permission denied

-------

BTW, Switchres does prompt Mame options, it was my fault I was typing -v-v-v instead of -v -v -v
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 30, 2010, 05:30:07 pm
echo 0xffff > /sys/module/drm/parameters/debug

bash:  /sys/module/drm/parameters/debug: Permission denied

-------

BTW, Switchres does prompt Mame options, it was my fault I was typing -v-v-v instead of -v -v -v

Ah, yeah you have to use 'sudo -s' first before doing that so your the root user.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 30, 2010, 05:41:57 pm
It's working now, but it only produces a file named 'debug' with a '0' inside.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 30, 2010, 05:47:58 pm
It's working now, but it only produces a file named 'debug' with a '0' inside.
 

Oh, does the debug file exist already?, should be able to run 'cat  /sys/module/drm/parameters/debug' and see 65565 as the contents.  It may be the 2.6.36.2 version of the DRM code doesn't allow that to work, but in theory should after doing that see /var/log/messages fill up with information, I'm not sure why it's not taking the value echo'd into it though. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 30, 2010, 05:53:12 pm
Yes, the 65535 is there before I run the second echo, so the messages should be in the messages file, ok, I'll get it now...

Here you have it, I've run glxgears maybe 2 or 3 times, tested both vblank_mode=2 / 3, the ones that fail, so there must be messages from several glxgears sessions there.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on December 31, 2010, 05:47:27 am
Here's the bottom half of a -v -v -v trying to run Crystal Castles. Notice the cannot initialize direct draw at the end.
Where do you think the problem is?
Code: [Select]
Got Soft15khz registry modeline 320x256@60 - DALDTMCRTBCD320x256x0x60:
             "320x256@60" 6.680000 320 336 368 416 256 257 260 268 -HSync -VSync

Setup monitor limits min=184x108 max=0x608
Starting with Horizontal freq of 16.949 and Vertical refresh of 61.04
Horizontal frequency too high 16.949 vfreq 61.035
Lowered horizontal frequency to  15700.000 from 16.949
Vertical frequency changed to 56.884 from 61.035
Original Vref 61.035156 != 56.884058
# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vref Change | )
Setting registery video mode DALDTMCRTBCD320x256x0x60 with:
(62954/62967/62954) Modeline 6.650000 320 336 368 424 256 257 260 276
Opening  modes file for mode 320x256@57
Running Emulator: mame ccastles -resolution 320x256@60 -resolution0 320x256@60 -
video ddraw -cleanstretch -redraw auto -throttle -mt
Target refresh = 61.035156
Target refresh = 61.035156
Unable to initialize DirectDraw.
Setting registery video mode DALDTMCRTBCD320x256x0x60 with:
(62967/62967/62967) Modeline 6.680000 320 336 368 416 256 257 260 268
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 31, 2010, 05:58:30 am
Here's the bottom half of a -v -v -v trying to run Crystal Castles. Notice the cannot initialize direct draw at the end.
Where do you think the problem is?
Code: [Select]
Got Soft15khz registry modeline 320x256@60 - DALDTMCRTBCD320x256x0x60:
             "320x256@60" 6.680000 320 336 368 416 256 257 260 268 -HSync -VSync

Setup monitor limits min=184x108 max=0x608
Starting with Horizontal freq of 16.949 and Vertical refresh of 61.04
Horizontal frequency too high 16.949 vfreq 61.035
Lowered horizontal frequency to  15700.000 from 16.949
Vertical frequency changed to 56.884 from 61.035
Original Vref 61.035156 != 56.884058
# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vref Change | )
Setting registery video mode DALDTMCRTBCD320x256x0x60 with:
(62954/62967/62954) Modeline 6.650000 320 336 368 424 256 257 260 276
Opening  modes file for mode 320x256@57
Running Emulator: mame ccastles -resolution 320x256@60 -resolution0 320x256@60 -
video ddraw -cleanstretch -redraw auto -throttle -mt
Target refresh = 61.035156
Target refresh = 61.035156
Unable to initialize DirectDraw.
Setting registery video mode DALDTMCRTBCD320x256x0x60 with:
(62967/62967/62967) Modeline 6.680000 320 336 368 416 256 257 260 268

Are you able to run mame normally using -video ddraw, or does Direct Draw always fail?

Try this command line and see if mame runs...

mame ccastles -resolution 320x256@60 -resolution0 320x256@60 -
video d3d -cleanstretch -redraw auto -throttle -mt

Possibly try ddraw, and use -verbose, fiddle around with the command line of just mame and see if you can figure out what works and what doesn't.  Guessing possibly your system doesn't do Direct Draw?  Also try to add '--args -video d3d' to switchres, which will force an override and use direct 3d instead.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 31, 2010, 06:02:11 am
Hi cotmm68030,

First of all try to make sure that 320x256@60 video mode is actually available on your system. You can do it using Quickres (at the risk of having to restart in VGA mode in case the screen gets unreadable) or better use my Arcade_OSD little program for testing modes. Then you can also test Mame from the command line with the same params to see if it works:

mame ccastles -resolution 320x256@60 -resolution0 320x256@60 -video ddraw -cleanstretch -redraw auto -throttle -mt

ATI Catalyst drivers are hardcoded to doublescan 320x and 400x videomodes. That's why normally people are renaming them with 321x and 401x labels. If that's the case, you can try with my hacked drivers that remove that problem.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on December 31, 2010, 06:21:41 am
Well I came back to edit my post and ya'll had already jumped on it. I'm not sure what's going on because it worked running the same command line shortly thereafter.

DirectDraw has always worked on this system.

Calamity; I had planned on trying your drivers soon anyway.

However I'm still having issues launching switchres from Hyperspin. I'm thinking it's a file path issue. I'll post more when I've had more time to play with it and have a better understanding of whats going wrong.


Any plans of integrating switchres straight into a mame executable?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 31, 2010, 06:35:44 am


Any plans of integrating switchres straight into a mame executable?

I've thought about it but also since mame is such a moving target and always changing it might make it hard to upkeep like advance mame was.  It is something that would be interesting but I've not explored it too far because I figure a wrapper like this essentially steers clear of worrying what the mame internals do.  It's pretty tricky from what I can tell to just keep the hiscore/cabmame patches up to date themselves, so something like this might be a total nightmare to keep updated.  I'm still hoping to figure out more internally how mame does the whole vertical refresh calculation and driving the game, maybe then I would be able to do something interesting enough to make it worth it.  The Advance mame code is interesting but everytime I look and try to understand it there's a big difference it seems between it and mame (maybe version or maybe it just altered mame quite a bit), and it's really difficult to understand because it seems to totally have different code paths per video card which makes it even more complicated.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on December 31, 2010, 06:54:37 am
I've thought about it but also since mame is such a moving target and always changing it might make it hard to upkeep like advance mame was.  It is something that would be interesting but I've not explored it too far because I figure a wrapper like this essentially steers clear of worrying what the mame internals do.  It's pretty tricky from what I can tell to just keep the hiscore/cabmame patches up to date themselves, so something like this might be a total nightmare to keep updated.  I'm still hoping to figure out more internally how mame does the whole vertical refresh calculation and driving the game, maybe then I would be able to do something interesting enough to make it worth it.  The Advance mame code is interesting but everytime I look and try to understand it there's a big difference it seems between it and mame (maybe version or maybe it just altered mame quite a bit), and it's really difficult to understand because it seems to totally have different code paths per video card which makes it even more complicated.

I agree bitbytebit here, a wrapper is cleaner and allows extending this features to other emulators apart from Mame. There's just one case I think it would be better to have this integrated with Mame itself: many people are using GUI Mame builds, so games are launched there without the possibility of doing our stuff in the middle. So by now, Switchres is great for launching games from a frontend, provided it can be properly setup. Old AdvanceMenu is easy to setup for this, just using %s instead of %f to remove the .zip extension. AdvanceMame was updated until v0.106, after that they completely modified Mame video system, so the autor said it would require a complete rewrite of AdvanceMame to keep updated and left it there.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on December 31, 2010, 08:17:06 am
Yeah, I suppose just getting the front end to play nicely is a more robust solution than a series of one-off mame builds.

Another oddity I've noticed, when I exit from bitbytebit's mame compile, as launched by Hyperspin, Hyperspin does not seem to register that the program has terminated, and does not begin reading controls until you've tabbed away from and back into it.

I wonder what is happening differently here than any other mame build? Cabmame64 and MameUI64 both return to hyperspin correctly (even when launched via switchres).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on December 31, 2010, 08:39:50 am
Yeah, I suppose just getting the front end to play nicely is a more robust solution than a series of one-off mame builds.

Another oddity I've noticed, when I exit from bitbytebit's mame compile, as launched by Hyperspin, Hyperspin does not seem to register that the program has terminated, and does not begin reading controls until you've tabbed away from and back into it.

I wonder what is happening differently here than any other mame build? Cabmame64 and MameUI64 both return to hyperspin correctly (even when launched via switchres).
I don't know if this might be part of the return issue, but the build I have is 32bit, so more like cabmame32.  Might be something, not sure why though it's not signaling a return to Hyperspin, and if that would be a cause of it. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 01, 2011, 12:26:26 am
Have version 1.254-5bc5179 ISO Images uploaded/uploading, the 32bit minimal is done uploading and rest will be there soon.  This uses OSS4 for the audio support, which may fix the sound issues since OSS4 is supposed to be a little better about things than Alsa (I already think it sounds better offhand, others claim that, old alsamixer doesn't work but doesn't matter because oss seems to unmute things by default but there's an ossxmixer and ossmixer if needed).  Also This has the 2.6.36 stable kernel but with the newest DRM code using the page flip support which now seems to get exact refresh rates and run the game speed at exactly 100% almost always except in rare cases it goes to 100.1%.  So it's pretty nice, there might be some more CPU usage from that it seems, but hopefully doesn't matter too much since most games are fine and if you have a 2.5Ghz core duo processor or better it should be even able to play the most heavy games (mine is 2.0 and it wants 2.4 or so Ghz it seems). 

Also another thing I'm wondering, from what I can tell if I run this with our vsync settings, but then add -throttle -mt I get things still without tearing.  If the game speed is already correct so we aren't actually utilizing throttle from what I can tell, it's just there to help us I'm guessing which probably will never happen from what I can tell.  So that also allows multi threading to work, I'm guessing because throttle does some thread safety stuff too by keeping things in sync probably.  So testing with '--args -throttle -mt' to switchres for games and comparing would be interesting, to see if there really is anything bad about throttle.  I'm still trying to explore the way mame multithreads, throttles, but from what I can tell with kernel page flipping and vblank/vsync support we are pretty good, I am wondering if throttle has some code that could be used to make multi threading work without throttle an waitvsync on still.  Somehow it's unifying the display output in multithreading mode, so maybe there's a way to do that and cut out anything bad that throttle might induce (which I don't see).  Also waiting for Alex to hopefully give an answer on why the CPU usage has went up and if this is just an outcome of being so exact on the scan line output to the monitor (which seems like in the code they have now timed it to the exact pixel to pefect refresh timing and timestamps for them to always know exactly what is being written from the OpenGL and X windows ati driver.   
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 01, 2011, 07:29:42 am
Quote
Also another thing I'm wondering, from what I can tell if I run this with our vsync settings, but then add -throttle -mt I get things still without tearing.  If the game speed is already correct so we aren't actually utilizing throttle from what I can tell, it's just there to help us I'm guessing which probably will never happen from what I can tell.  So that also allows multi threading to work, I'm guessing because throttle does some thread safety stuff too by keeping things in sync probably.

In my experience -throttle does not produce tearing but scroll hiccups. As our real screen vfreq and the one calculated by Mame internal clock will never match exactly, at some point one would not be able to catch the other. It's the classical problem of dealing with two clocks. Of course if we are very very close to the target it will be nearly perfect, but will still be there. For testing this, I always use sfa3, and look at the texts scrolling on the character selection screen. I noticed that even getting a nearly perfect vfreq I was seeing hiccups. That's why I figured out that syncrefresh patch I posted at the beginning of this thread, that didn't throttle in case sycrefresh was enabled (because at that time I had prejudices against triplebuffer, not anymore). Now we are getting the exact same visual result without patches just disabling throttle and enabling triplebuffering.

I didn't know the throttle option had anything to do with multithreading, but reading a bit more now, I'm seeing that sleep option there that points to that direction. As I understand it, throttling, vsyncing or whatever that involves doing loops to wait for stuff, need to have some 'sleep' mechanism implemented when working in a multitasking system, to allow the system share the cpu with other apps running, otherwise all cpu cycles would be wasted waiting there. This was not a problem in DOS realmode. By the way this one of the reasons why realtime apps in multitasking systems suck. If you 'sleep' your app for some time, it will be more friendly to the system, but I believe that you have to loose some accuracy with synchronization, as it's up to the system to give the control back to you when intended. This is my theory on what you're seeing with new drm, it could be trying to be so accurate it's leaving little time to the cpu for anything else. On the other hand, that per line accuracy is something we don't have in Windows at all, and seems it could make possible emulation of some original raster effects existing on real pcbs impossible to emulate otherwise.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 01, 2011, 09:47:19 pm
Switchres version 1.263-3d2f450 for Windows and Linux are up, they add...

* Vertical monitor support
* Rotatable monitor support
* custom aspect ratio calculation for vertical games on a horizontal monitor
* Finally got D9800 range correct, from what I can tell, to show pacman on it horizontally and keep original refresh rate
  (black hole area, I guess from 19Khz - ~20Khz, although it's possibly up to 22Khz and really not sure if it's even more complex and
   combo of line height of 288 in that range possibly or line total between 312-3?? can't be in that range)

Basically added a --mo arg for monitor aspect which takes 0 (default for horizontal monitor), 1 for vertical, 2 for rotatable monitor.   So it'll play a horizontal game correctly now on a vertical monitor, looks quite nice actually, was better than I thought it'd be on my 27" d9800.

The --vcalc arg now uses as before 0 for 16/9 true aspect calculation, 1 for 3/4 slightly wider calculation, and anything else is the value used (so 1.333 equals the 16/9 basically, since it does it slightly different in that 0 calculation and anything other than 1 which is done by height * (4/3), may be more ways to do this too I'm suspecting, the 0 though is probably what always should be used or 1 for people that like wider stretching to the games width on vertical games for a horizontal monitor).


Also with the ISO's, the newer DRM layer that is fully 100% accurate on game speed using the vsync, seems to not have any CPU usage increase in the 64bit kernel version?  So that's weird. only on 32bit does the increase occur, wondering if the accuracy of the vsync timestamping/page flipping is something which 64 bit seems to handle without problems while 32 bit seems to have to work a lot harder, but both are still nice as long as you have extra CPU for 32 bit.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 01, 2011, 11:59:12 pm
Quote
Also another thing I'm wondering, from what I can tell if I run this with our vsync settings, but then add -throttle -mt I get things still without tearing.  If the game speed is already correct so we aren't actually utilizing throttle from what I can tell, it's just there to help us I'm guessing which probably will never happen from what I can tell.  So that also allows multi threading to work, I'm guessing because throttle does some thread safety stuff too by keeping things in sync probably.

In my experience -throttle does not produce tearing but scroll hiccups. As our real screen vfreq and the one calculated by Mame internal clock will never match exactly, at some point one would not be able to catch the other. It's the classical problem of dealing with two clocks. Of course if we are very very close to the target it will be nearly perfect, but will still be there. For testing this, I always use sfa3, and look at the texts scrolling on the character selection screen. I noticed that even getting a nearly perfect vfreq I was seeing hiccups. That's why I figured out that syncrefresh patch I posted at the beginning of this thread, that didn't throttle in case sycrefresh was enabled (because at that time I had prejudices against triplebuffer, not anymore). Now we are getting the exact same visual result without patches just disabling throttle and enabling triplebuffering.

I didn't know the throttle option had anything to do with multithreading, but reading a bit more now, I'm seeing that sleep option there that points to that direction. As I understand it, throttling, vsyncing or whatever that involves doing loops to wait for stuff, need to have some 'sleep' mechanism implemented when working in a multitasking system, to allow the system share the cpu with other apps running, otherwise all cpu cycles would be wasted waiting there. This was not a problem in DOS realmode. By the way this one of the reasons why realtime apps in multitasking systems suck. If you 'sleep' your app for some time, it will be more friendly to the system, but I believe that you have to loose some accuracy with synchronization, as it's up to the system to give the control back to you when intended. This is my theory on what you're seeing with new drm, it could be trying to be so accurate it's leaving little time to the cpu for anything else. On the other hand, that per line accuracy is something we don't have in Windows at all, and seems it could make possible emulation of some original raster effects existing on real pcbs impossible to emulate otherwise.



Interesting, running sfa3 either way, throttle mt or nothrottle nomt, I see it as running perfectly either way.  So it seems possibly the page flipping and vblank support in the kernel is really running at exactly 100% and matching mame I guess enough or exactly.  At 64 bit on this d9800 the game is nice, amazing one to test with, thanks for letting me know about that as being a good test.  So many scrolling things all around, very interesting, and definitely seems like in that the Linux DRM layer is really doing some amazing things and even allowing the throttle option to still be used.  I'm guessing since the guy and others doing the work now are actually the employees of AMD and other companies for video cards/hardware they must be doing something possibly even better than they have done in the Windows for at least 2D for now and of course are with Gallium aiming to match that success with the 3D side of things.  From looking at the kernel code changes, they seem to be totally accounting for each exact scanline and pixel timestamp drawing to match the timing correctly with the vblank timestamps.  So from that it seems like it makes sense what I'm seeing, the jump all the sudden from near perfect running speed without throttle to perfect running speed, and possibly exact enough to even use throttle and it doesn't really matter (and then seems to allow multithreading too).  I also would think this means we should in theory be able to get multithreading working without throttle and just find the part that it needs to allow that to work with vsync support, at least remove most of what throttle does I would think and keep the part that allows the threads to be timed still and not just run free (It might be because they are depending on SDL->OpenGL to do the pageflip/vblank stuff, and need to do something to keep track of it so mame knows what is going  on, and not keep track of it through throttle and guess even though it seems to be guessing near perfectly now).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 02, 2011, 02:16:23 pm
I've been testing 1.254 iso (full). Now during the setup's "choose an audio device" part, it's saying "aplay: device_list:235: no soundcards found...", so can't choose anything as "Card number". After that, Gnome mixer is empty, no devices. However I tried with alsaconf and it's finding the same devices it did with the other iso, but there's no way I can make them work.

As you said, there must be a conflict with ATI HDMI and onboard audiocard, as it's strange both audio drivers are failing with this machine. However it's working ok in Windows. In the logs attached, notice these lines in messages file:

Jan  2 13:50:16 GroovyArcade kernel: [    1.618993] [drm] Enabling audio support

Jan  2 13:50:21 GroovyArcade kernel: [   99.606597] oss_hdaudio 0000:80:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Jan  2 13:50:21 GroovyArcade kernel: [   99.615479] oss_hdaudio: Too many connections
Jan  2 13:50:21 GroovyArcade kernel: [   99.615540] oss_hdaudio: HDA codec 0x00000000 not known yet

Why should drm be messing with audio? (I guess that's because it's the videocard's HDMI)
(these logs are without running alsaconf, just with the out of the box setup).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 02, 2011, 02:55:48 pm
I've been testing 1.254 iso (full). Now during the setup's "choose an audio device" part, it's saying "aplay: device_list:235: no soundcards found...", so can't choose anything as "Card number". After that, Gnome mixer is empty, no devices. However I tried with alsaconf and it's finding the same devices it did with the other iso, but there's no way I can make them work.

As you said, there must be a conflict with ATI HDMI and onboard audiocard, as it's strange both audio drivers are failing with this machine. However it's working ok in Windows. In the logs attached, notice these lines in messages file:

Jan  2 13:50:16 GroovyArcade kernel: [    1.618993] [drm] Enabling audio support

Jan  2 13:50:21 GroovyArcade kernel: [   99.606597] oss_hdaudio 0000:80:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Jan  2 13:50:21 GroovyArcade kernel: [   99.615479] oss_hdaudio: Too many connections
Jan  2 13:50:21 GroovyArcade kernel: [   99.615540] oss_hdaudio: HDA codec 0x00000000 not known yet

Why should drm be messing with audio? (I guess that's because it's the videocard's HDMI)
(these logs are without running alsaconf, just with the out of the box setup).

Yeah the setup error is just it trying to check for Alsa and it not existing, in the next ISO it'll give an option to use either Alsa or OSS at that point instead of trying to immediately mess with the mixer.  It seems it is more of an issue in Linux possibly and both Alsa and OSS are having trouble with that soundcard, strange.  I have a system that required Alsa instead of OSS, so seems it's variable for each system, although I suspect Alsa might be more compatible to more cards but the ones OSS works for work better than Alsa.  

Send me the output of these commands (after sudo -s)
lspci -v -v -v > lspci_output.txt
ossinfo > ossinfo_output.txt

Also running ossdetect might be interesting to see what it does.  I am wondering if oss just isn't loading the right module, could also try 'modprobe oss_ich' to see if that finds it.  I'll look through the logs and try to find more info on those errors, I do see people have issues with those sounds cards sometimes and seems like it's possibly just certain ones with certain setups.



Update:

Also get the /var/log/soundon.log file, seems that really shows a lot of information.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 02, 2011, 03:30:34 pm
Here are the outputs of lspci and ossinfo. I'm running ossdetect and modprobe oss_ich but they just end silently without prompting anything.
I've been trying some youtube videos on the browser and there's no sound there either.

UPDATE: soundon.log attached.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 02, 2011, 03:41:37 pm
Here are the outputs of lspci and ossinfo. I'm running ossdetect and modprobe oss_ich but they just end silently without prompting anything.
I've been trying some youtube videos on the browser and there's no sound there either.

UPDATE: soundon.log attached.

Does ossxmixer have anything in it that can be unmuted?  Or volume turned up, that mixer should work (although it is really larger than the 640x480 screen I admit :/).  Also ossmix is a command line version of it.

Update:

Interesting, the one thing that might be happening is perhaps it's using the HD mode of the card instead of the Analog one?  I see your card actually is similar to mine but yet has the whole right/left outputs...

Mine:
Code: [Select]
Audio devices:
0: HD Audio play speaker (OUTPUT)
1: HD Audio play headphone (OUTPUT)
2: HD Audio rec mix (INPUT)
3: HD Audio rec mix (INPUT)
4: HD Audio rec mix (INPUT)

Yours:
Code: [Select]
Audio devices:
0: HD Audio play front (OUTPUT)
1: HD Audio play rear (OUTPUT)
2: HD Audio play center/LFE (OUTPUT)
3: HD Audio play c/lfe (OUTPUT)
4: HD Audio play pcm (OUTPUT)
5: HD Audio play pcm (OUTPUT)
6: HD Audio rec  (INPUT)
7: HD Audio rec  (INPUT)
8: HD Audio rec  (INPUT)
9: HD Audio rec  (INPUT)

It does see it so getting more than Alsa does, and actually looks like it's setup and just that one error we see, like it's trying to do both HD and Analog audio at the same time or something like that.


Update:

Also ossmix -c output is interesting, may show some things possible to change and it outputs the actual command you need to run (removing the first ! part) to alter it, 25 is max volume, see if anthing interesting is muted, although if you can see ossxmix output that might be better.  If you want, send me the output of ossmix -c too, that at least will show exactly the current mixer settings.

Update:

Also does the computer have an audio jack output on the front too, does it output sound?  Definitely weird, your sound card has a lot of outputs according to oss, can see why something odd might be going on and confusing things in Linux. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 02, 2011, 03:50:26 pm
ossmixer command is not recognized.
ossmix is prompting this:
Code: [Select]
Selected mixer 0/High Definition Audio ALC662
Known controls are:
vmix0-enable ON|OFF (currently ON)
vmix0-rate <decimal value> (currently 48000) (Read-only)
vmix0-channels <Stereo|Multich> (currently Stereo)
vmix0-src <Fast|High|OFF> (currently Fast)
vmix0-outvol <monovol> (currently 25.0 dB)
vmix0-invol <monovol> (currently 25.0 dB)
vmix0.pcm10 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm11 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm12 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm13 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)

UPDATE: ossmix -c

Code: [Select]
!ossmix -d0 vmix0-enable ON
!ossmix -d0 vmix0-channels Stereo
!ossmix -d0 vmix0-src Fast
!ossmix -d0 vmix0-outvol 25.0
!ossmix -d0 vmix0-invol 25.0
!ossmix -d0 vmix0.pcm10 25.0:25.0
!ossmix -d0 vmix0.pcm11 25.0:25.0
!ossmix -d0 vmix0.pcm12 25.0:25.0
!ossmix -d0 vmix0.pcm13 25.0:25.0
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 02, 2011, 03:59:14 pm
ossmixer command is not recognized.
ossmix is prompting this:
Code: [Select]
Selected mixer 0/High Definition Audio ALC662
Known controls are:
vmix0-enable ON|OFF (currently ON)
vmix0-rate <decimal value> (currently 48000) (Read-only)
vmix0-channels <Stereo|Multich> (currently Stereo)
vmix0-src <Fast|High|OFF> (currently Fast)
vmix0-outvol <monovol> (currently 25.0 dB)
vmix0-invol <monovol> (currently 25.0 dB)
vmix0.pcm10 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm11 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm12 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm13 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)

UPDATE: ossmix -c

Code: [Select]
!ossmix -d0 vmix0-enable ON
!ossmix -d0 vmix0-channels Stereo
!ossmix -d0 vmix0-src Fast
!ossmix -d0 vmix0-outvol 25.0
!ossmix -d0 vmix0-invol 25.0
!ossmix -d0 vmix0.pcm10 25.0:25.0
!ossmix -d0 vmix0.pcm11 25.0:25.0
!ossmix -d0 vmix0.pcm12 25.0:25.0
!ossmix -d0 vmix0.pcm13 25.0:25.0

Just odd, it seems to all be setup ready to play, I expected some errors from oss but the only one is that log one.  Odd thing is I can't find that error for anyone else when searching for it in Google, so not a common error or it's maybe harmless and there's something else that's the issue.  


Update:

In the source I see that MAX_CONN value seems to be 24 and that's the amount of audio devices + audio engines + mixer devices you have so far.  I suspect it's hitting that limit, I am raising that limit and will see what it does, hopefully get an ISO in a few hours up that has that raised if I have luck with it here not causing things to break.  At least good that my soundcard is the same type so can test to make sure it still allows it to work, actually uses the same module but yours I guess is a much higher revision than mine (ALC262).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 02, 2011, 04:15:26 pm
Just odd, it seems to all be setup ready to play, I expected some errors from oss but the only one is that log one.  Odd thing is I can't find that error for anyone else when searching for it in Google, so not a common error or it's maybe harmless and there's something else that's the issue. 

I've plugged the speakers to each of the five jack connectors I have while playing a video. No sound. I always have them connected to the green one (front) and get sound normally. This is definitely weird.

I must have a curse with Linux and sound, I've been trying different live-cds for years, in three different computers at least, different distributions (Suse...), different hardware (creative, realtek) and have never been able to hear a single beep out of it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 02, 2011, 06:16:32 pm
Just odd, it seems to all be setup ready to play, I expected some errors from oss but the only one is that log one.  Odd thing is I can't find that error for anyone else when searching for it in Google, so not a common error or it's maybe harmless and there's something else that's the issue. 

I've plugged the speakers to each of the five jack connectors I have while playing a video. No sound. I always have them connected to the green one (front) and get sound normally. This is definitely weird.

I must have a curse with Linux and sound, I've been trying different live-cds for years, in three different computers at least, different distributions (Suse...), different hardware (creative, realtek) and have never been able to hear a single beep out of it.


I'm uploading a new ISO LiveCD32-Mini-NMO-1.269-accf1fe.iso which has increased that limit which it's complaining about.  Well all the Linux distributions have used Alsa, hopefully this OSS4 can figure things out.  Definitely sounds like a bit of bad luck of what sound cards are on those systems.  If you research it turns out many are unhappy with how Linux audio has been done.  Unfortunately a lot of it is the proprietary nature of sound cards chips, so hard to fight that.  OSS and Alsa have interesting histories which both make people unhappy with how they've been done.  Hopefully sooner or later OSS4 is either advanced to the point of fixing the issue completely or Alsa figures out the issues there.  Seems like a lot of things need to be done though before either could happen.  At least it sees the card and we have that error to work off of and curious what this ISO says about that, hopefully doubling the 24 to 48 is enough audio connections.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 03, 2011, 04:17:27 am
Just odd, it seems to all be setup ready to play, I expected some errors from oss but the only one is that log one.  Odd thing is I can't find that error for anyone else when searching for it in Google, so not a common error or it's maybe harmless and there's something else that's the issue.  

I've plugged the speakers to each of the five jack connectors I have while playing a video. No sound. I always have them connected to the green one (front) and get sound normally. This is definitely weird.

I must have a curse with Linux and sound, I've been trying different live-cds for years, in three different computers at least, different distributions (Suse...), different hardware (creative, realtek) and have never been able to hear a single beep out of it.


Also if OSS in the new ISO doesn't work, here's an interesting thing to try from this bug report (seems others see problems too with this exact card/chip)...

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/664785

Quote
Strangely this is related to bug#536699. Changing, in the BIOS, the graphics aperture size from 128MB to 256MB as suggested in that bug's comments solves both that issue and this.

I'd try OSS, then OSS with this change, and if that doesn't work then try Alsa with the change.  I can kind of see that it could make sense with the video card having essentially the same type of audio chip in it and maybe the BIOS has some issue when it's not large enough aperture.  Of course one person said they don't even have that option in the BIOS, a long shot but definitely interesting to see others with the issue lately (seems older Ubuntu versions didn't but 10.10 does have this bug).

Oddly at the end of this bug report that one references, multiple people found this as the solution...
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/536699


Update:
Also here's something interesting to try...

sudo -s
ossdetect -v
soundoff
rmmod oss_hdaudio
rmmod oss_usbaudio
rmmod osscore
rm -f /etc/oss/installed_drivers
soundon

Then check ossmix -c and see if it's different, and try some audio then.

Which might setup things better, now have figured out that is what is necessary for each system setup, it was really just setting up OSS4 for my setup.  The OSS4 stuff lacks a bit of smoothness in how it installs, seems to not be aimed at generic detection on load unless you do the above each time.


Update: Also to test, run osstest :) this command is great, best way to see if audio is working.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 03, 2011, 12:33:25 pm
Thanks a lot for the info and links. I'll test those today. The bios aperture option however will be more difficult to test as I can't see the bios through the jpac anymore since I installed this 4350 card. It's so distorted I can barely see anything on the upper part of the screen. I'd need to get a pc monitor to do that. I also want to have a look at the new options in Switchres and how they work. I've been studying your code a little bit, to see if I can help with the video mode selection algorithm, will take me some time. I want to test some ideas of how to precalculate a mode table, it would be interesting to try to get the best possible out of driver limited to 60 modes also. I was also having a look at the PLL code in radeon drivers, can't figure out much of it yet but definitely interesting, and good to know it's coming directly from AMD.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 03, 2011, 03:43:50 pm
Audio is finally working!  ;D

It seems your patch increasing the number of devices was the key, so that should be reported or something as there must be more people having the same problem.

So the osstest command is working, btw this is just what I was needing, a simple command to test sound.

However sound does not work yet in Mame. By default it's trying to setup an ALSA device (fails). Then I've tried to force it to select oss on the audiodriver sdl option, I've tried oss_hdaudio0, then the ALSA errors stop, but it says it's finding no audio device :(

I'll post some logs later.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 03, 2011, 03:46:35 pm
Audio is finally working!  ;D

It seems your patch increasing the number of devices was the key, so that should be reported or something as there must be more people having the same problem.

So the osstest command is working, btw this is just what I was needing, a simple command to test sound.

However sound does not work yet in Mame. By default it's trying to setup an ALSA device (fails). Then I've tried to force it to select oss on the audiodriver sdl option, I've tried oss_hdaudio0, then the ALSA errors stop, but it says it's finding no audio device :(

I'll post some logs later.

Try to have it use 'dsp' for the -audiodriver, that's what it uses here when it works with oss.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 03, 2011, 05:24:34 pm
It's working! It was not necessary to set the audiodrive to dsp, it was already working but very low for some reason, now I have set the ossmix jack.green.front 64:64 (it was 51 or something) and set the speakers' volume to the top and it's sounding normal. So it may be sounding lower that in Windows it seems, not sure however as some Mame games sound louder than others, need to do more tests.

Some logs attached: mame.log (only is first part of it) shows no alsa errors any more (were they prompted by switchres or mame itself?), everything looks ok. In messages file there's not that  "too many devices error" any more.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 03, 2011, 06:13:33 pm
It's working! It was not necessary to set the audiodrive to dsp, it was already working but very low for some reason, now I have set the ossmix jack.green.front 64:64 (it was 51 or something) and set the speakers' volume to the top and it's sounding normal. So it may be sounding lower that in Windows it seems, not sure however as some Mame games sound louder than others, need to do more tests.

Some logs attached: mame.log (only is first part of it) shows no alsa errors any more (were they prompted by switchres or mame itself?), everything looks ok. In messages file there's not that  "too many devices error" any more.


Sounds great, I'll have to send the fix to the OSS people, definitely starting to like the way OSS4 is now that I realized the way to initialize the card detection after the first install.  It may actually partly be my setup turning the volume output down from 25 to 18, on my cab I do that to keep it from blaring but I also have a pga golf tour that for some reason came with huge car speakers that need a 150Watt audio amp and are very loud at full volume :D.  So guessing that's something I probably shouldn't turn down for every setup, although I'm turning down the audio output and seems your sound card has other settings there which I've never touched here yet (or know if they exist on mine).  I have been pretty impressed with OSS4 after I hacked it quite a bit to the current state so it behaves on the liveCD properly and can be setup in my chroot, and that fix and a few others. 

I'll have new ISO images up soon that do all the initialization stuff internally instead of you having to run those commands each boot.  I think even alsa behaves better now with they way I have it when enabled, possibly could even get alsa working there because it now works easily on my laptop which I think was very similar to your situation (of course OSS4 sounds better I think and probably better, but would be interesting to test that on the next ISO). 

Also it might be interesting to see if the debug we did for the DRM layer is any different on these new ISO images since they are now using the newer DRM and page flipping, might show more information.  Hopefully Alex eventually figures that out, I'm pretty much lost because from the log I just see there's no interrupts occurring even though it's trying to set the registers to trigger them.  Possibly the newer DRM has better debug messages, they've improved them quite a bit over the last month since that stable kernel that the others messages came from.


I'm looking into this http://www.glfw.org/ (http://www.glfw.org/) right now, it's interesting because it seems like a very easy to use simple yet powerful SDL/Mesa replacement to use OpenGL through an interface that simplifies the programming and doesn't require the whole SDL->OpenGL stuff.  Which I'm suspecting would allow multithreading and vsync to work together and the video mode and vsync setup in general to work better.  I don't really like SDL the more I see how they basically froze 1.2 and 1.3 is the never ending development version that is really breaking things faster than improving them.  Also if broken off into a separate osd then I can put the switchres program into it possibly, if it really seems feasible to rewrite the osd using this glfw interface.  It'll at least teach me more about how mame does the OSD, by trying to build a new one, right now I'm starting just having it be a separate -video option for SDL but can see how it really needs to be a whole separate OSD since it can do all the stuff SDL does and looks way simpler to implement with glfw.  I discovered it a little while ago while looking up the OpenGL functions and finding people that were trying to do Vsync and having issues with SDL and were recommended  to try glfw and everyone seemed to have all their problems fixed by it and see perfect vsync (which we do have currently somewhat but I'm guessing we can multithread and reduce overhead/CPU usage, possibly improve the whole OSD feel having it really multithread everything and just keep the main frame vsync write in OpenGL/glfw as a single thread). 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 04, 2011, 03:07:28 pm
I've got version 1.274-edcf26b ISO images up, should be all built in to use OSS4 correctly now and generally work really well besides the J-Pac issue with the 4350 and the odd 32 bit CPU usage from the page flipping. 

Both issues hopefully sooner or later will be addressed by Alex.  I'm going to start digging into the kernel more and see if I can at all figure out why it'd not run interrupts for vblanking when the interface doesn't detect a monitor but is forced on.  I think that GLFW library is somewhat a dead end for now from lack of extra stuff that SDL provides, input layer doesn't look great and besides full screen mode not working as expected it doesn't have sound or font/text OSD writing.  Figures, I also am thinking the mame multithreading probably isn't going to work with vsync, from taking it apart quite a bit on the OSD side the last day I just see that it seems to be most likely impossible or a very big job to multithread it without throttling and using the vsync.  I still am poking at it, but definitely not any leads really on how to do it yet.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 04, 2011, 05:33:22 pm
Just out of curiosity, do you mean that multithreading only works when enabling throttle, or is the vsync itself what prevents it from working? By reading mame's windows.txt, it seems multithreading just creates a second thread for the window + d3d/ddraw management. So both threads should be synchronized in order to work. Could it be that the synchronization code is inside the throttle part?. Honestly I have no idea of how they are doing it.

Hopefully tomorrow I'll send you the drm debug logs so they can help you or Alex figure out what's going on, must be something silly about not really using the forced connections. Definitely eager to see that solved as it seems the last remaining wall to pull down in order to have this working for everyone, once there's a fully working version I'd like to install it to the hardrive so I don't have to run the setup all the time ;)

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 04, 2011, 06:01:38 pm
Just out of curiosity, do you mean that multithreading only works when enabling throttle, or is the vsync itself what prevents it from working? By reading mame's windows.txt, it seems multithreading just creates a second thread for the window + d3d/ddraw management. So both threads should be synchronized in order to work. Could it be that the synchronization code is inside the throttle part?. Honestly I have no idea of how they are doing it.

Hopefully tomorrow I'll send you the drm debug logs so they can help you or Alex figure out what's going on, must be something silly about not really using the forced connections. Definitely eager to see that solved as it seems the last remaining wall to pull down in order to have this working for everyone, once there's a fully working version I'd like to install it to the hardrive so I don't have to run the setup all the time ;)



Without throttle there seems to be no way to run the threads in the work queue timed with the vsync, so without multithread it follows the vsync fine but when executing the window drawing event.  When it puts the window drawing event into that work queue though it seems to just go as fast as it can without throttle.  Without vsync or with it is the same, when throttle is taken out for SDL Linux, things just run full speed unless you have the vsync set, and multithreading off.  So somehow vsync and no multithreading allow nothrottle to run at the correct speed and not run out of control.  It's odd because I don't see it explicitly stated anywhere about that, not sure if it's a newer bug and used to not be that way in older mame versions, possibly since in Linux few have had the ability to use vsync properly without throttle they've never addressed the issue or might not even know it exists.   

Yeah I just installed the current system to my hard drive and now that will be my development system, so the system is now going to be developed within the system :).  Which is nice and actually will get to use it with the page flip stuff now all the time, my old setup was the original system I built before the liveCD one and so ran at the ~2% off of actual refresh rate and setup as more of a proof of concept.  There are a few little parts of setup that aren't 100% smoothed up on installing, which I just saw today, so still have those to take care of.

I'm actually amazed the last few days, every way I cut it seems the newest DRM is running exactly 100% or sometimes 100.01% or 99.99%, it's never more than .01% off on game speed.  So whatever they did, probably the vblank timestamping I would guess, they made it really work perfectly now (at the expense of a bit of CPU on 32 bit kernels unfortunately for now).  So if the connector interrupt issue and the CPU usage issue is figured out, should be quite a useful system.  I also still need to go through all the emulators and setup each to allow switchres to work with them and go into full screen properly etc.  I had that working in the past, be it was before with different switchres command line syntax and also the nes emulators and gens are weird about full screen and getting it right at the original resolution.  Basically have run them all like that, but boxing it all up into a simple wahcade instant config is a pain, plus wahcade setup itself is not the greatest of ease unfortunately.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 05, 2011, 06:54:59 am
I'm seeing the same issue with nothrottle + multithreading in the Windows version, crazy CPU usage when nothrottle included, so it definitely seems a problem with Mame design. I've been looking through the code and have some idea of how to solve it rather easily, however I'm not sure if that will break something else. On the other side patching Mame is discouraging as it may turn out to be useless with next version, etc.

So for what I'm seeing now with multithreading they're doing two threads:

- Window thread: that deals with window managment and ddraw/direct3d (where vsync happens)
- Main thread: the emulator itself, that creates a frame at a time

By the way, this is the desing that should be the default for Mame, as single threaded emulators are crap as the sound gets stuck in a loop when they are minimized.

So the main thread creates a frame, and if throttle is enabled, then runs update_throttle(current_time) in \emu\video.c, which calls throttle_until_ticks, which at the end calls osd_sleep(delta) where the 'sleep' is actually done. So if you disable throttle, the sleep of the thread is not performed, that's why it's eating all cpu cycles.

Code: [Select]
// if we're throttling, synchronize before rendering
attotime current_time = timer_get_time(&m_machine);
if (!debug && !skipped_it && effective_throttle())
update_throttle(current_time);

// ask the OSD to update
g_profiler.start(PROFILER_BLIT);
m_machine.osd().update(!debug && skipped_it);
g_profiler.stop();

The waiting for vsync, however, is performed in the d3d/ddraw part. So if we have a single thread, the processor will wait there and Mame will be synchronized despite disabling throttle, although wasting all cpu time.

But when we start both threads, then the main thread is not aware of the window thread waiting! (as they run in paralell) and keeps sending frames to it all the time regardless vsync, unless we enable throttle.

So what should be done is to create an event object in order to synchronize both threads. This is done (in Windows) with the CreateEvent api. So, after creating a frame the main thread would do a WaitForSingleObject to release the cpu until we order it to go on with the next one. In the window thread, we would wait for vsync, and when done, we would use SetEvent, to instruct the other thread to go on. In theory this would make a better use of cpu.

So the throttle logic should be replaced when doing vsync, from the current sleep for some ticks (that is causing scroll hiccups for me), to the event ruled method above.


Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 05, 2011, 10:18:04 am
I'm seeing the same issue with nothrottle + multithreading in the Windows version, crazy CPU usage when nothrottle included, so it definitely seems a problem with Mame design. I've been looking through the code and have some idea of how to solve it rather easily, however I'm not sure if that will break something else. On the other side patching Mame is discouraging as it may turn out to be useless with next version, etc.

So for what I'm seeing now with multithreading they're doing two threads:

- Window thread: that deals with window managment and ddraw/direct3d (where vsync happens)
- Main thread: the emulator itself, that creates a frame at a time

By the way, this is the desing that should be the default for Mame, as single threaded emulators are crap as the sound gets stuck in a loop when they are minimized.

So the main thread creates a frame, and if throttle is enabled, then runs update_throttle(current_time) in \emu\video.c, which calls throttle_until_ticks, which at the end calls osd_sleep(delta) where the 'sleep' is actually done. So if you disable throttle, the sleep of the thread is not performed, that's why it's eating all cpu cycles.

Code: [Select]
// if we're throttling, synchronize before rendering
attotime current_time = timer_get_time(&m_machine);
if (!debug && !skipped_it && effective_throttle())
update_throttle(current_time);

// ask the OSD to update
g_profiler.start(PROFILER_BLIT);
m_machine.osd().update(!debug && skipped_it);
g_profiler.stop();

The waiting for vsync, however, is performed in the d3d/ddraw part. So if we have a single thread, the processor will wait there and Mame will be synchronized despite disabling throttle, although wasting all cpu time.

But when we start both threads, then the main thread is not aware of the window thread waiting! (as they run in paralell) and keeps sending frames to it all the time regardless vsync, unless we enable throttle.

So what should be done is to create an event object in order to synchronize both threads. This is done (in Windows) with the CreateEvent api. So, after creating a frame the main thread would do a WaitForSingleObject to release the cpu until we order it to go on with the next one. In the window thread, we would wait for vsync, and when done, we would use SetEvent, to instruct the other thread to go on. In theory this would make a better use of cpu.

So the throttle logic should be replaced when doing vsync, from the current sleep for some ticks (that is causing scroll hiccups for me), to the event ruled method above.




Patching it shouldn't be a problem, I should be able to keep up with it, just might take a few days when they change things enough.  I've been studying the code and see exactly what your saying.

I just did a test as a proof of concept and it works with a very rudementry lock it seems for the test, of course need something better than this which is pretty crude...
Code: [Select]
diff --git a/src/osd/glfw/drawogl.c b/src/osd/glfw/drawogl.c
index 1844dcc..adc2cfc 100644
--- a/src/osd/glfw/drawogl.c
+++ b/src/osd/glfw/drawogl.c
@@ -1551,6 +1552,9 @@ static int drawogl_window_draw(sdl_window_info *window, UINT32 dc, int update)
 #else
        SDL_GL_SwapWindow(window->sdl_window);
 #endif
+
+       window->update_ok = 0;
+
        return 0;
 }

diff --git a/src/osd/glfw/video.c b/src/osd/glfw/video.c
index 12e77db..c6d3060 100644
--- a/src/osd/glfw/video.c
+++ b/src/osd/glfw/video.c
@@ -329,6 +329,7 @@ sdl_monitor_info *sdlvideo_monitor_from_handle(UINT32 hmonitor)
 //  update
 //============================================================
 
+#include <unistd.h>
 void sdl_osd_interface::update(bool skip_redraw)
 {
        sdl_window_info *window;
@@ -343,6 +344,11 @@ void sdl_osd_interface::update(bool skip_redraw)
        {
 //      profiler_mark(PROFILER_BLIT);
                 for (window = sdl_window_list; window != NULL; window = window->next) {
+                       if (window->update_ok == 1)
+                               while(window->update_ok == 1)
+                                       usleep(10000);
+                       window->update_ok = 1;
+
                         sdlwindow_video_window_update(&machine(), window);
                         if (machine().redraw != 0)
                         {

--- a/src/osd/glfw/window.c
+++ b/src/osd/glfw/window.c
@@ -1012,8 +1018,10 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                        wp.machine = machine;
 
                        execute_async(&draw_video_contents_wt, &wp);
-               }
-       }
+               } else
+                       window->update_ok = 0;
+       } else
+               window->update_ok = 0;
 }
 
 
diff --git a/src/osd/glfw/window.h b/src/osd/glfw/window.h
index f488652..075959e 100644
--- a/src/osd/glfw/window.h
+++ b/src/osd/glfw/window.h
@@ -93,6 +93,8 @@ struct _sdl_window_info
        // GL specific
        int                                     prescale;
 
+       int                                     update_ok;
+
 #if (SDL_VERSION_ATLEAST(1,3,0))
        // Needs to be here as well so we can identify window
        SDL_Window                      *sdl_window;





Crude but it does keep it 100% that way with multithreading and need to test more but should in theory allow the threading to go above 100% cpu usage and use both CPU's?  I'm not sure though, but does this look like the right way places to lock like this?  Seems to be pretty good at running now like that right off, so at least doesn't hurt anything and still can use the multithread work queue.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 05, 2011, 11:00:36 am
Yeah that's the idea. I'm not familiar with the SDL code in Mame. However I would try to place the sleeping in the update_throttle function itself, doing two branches inside it in case we're vsyncing or not, so that part would be common for both Windows/Linux, and then have the SDL/DDraw on the other part triggering the event.

Do you mean the CPU usage is still 100%? At least in theory, each of those threads could be run in one of the two processors, but it could be up to the system to do that. Anyway I have no experience with that, I've just done multithreading for single processors.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 05, 2011, 11:26:29 am
Yeah that's the idea. I'm not familiar with the SDL code in Mame. However I would try to place the sleeping in the update_throttle function itself, doing two branches inside it in case we're vsyncing or not, so that part would be common for both Windows/Linux, and then have the SDL/DDraw on the other part triggering the event.

Do you mean the CPU usage is still 100%? At least in theory, each of those threads could be run in one of the two processors, but it could be up to the system to do that. Anyway I have no experience with that, I've just done multithreading for single processors.

Oh no just running at 100% speed, cpu usage is a little more that way but I just figured out how to use the built in pthread locking they already have for the rendering queue.  With that it's exactly the same as before in CPU usage and running speed percent but multithreading enabled too.
Code: [Select]
diff --git a/src/osd/glfw/drawogl.c b/src/osd/glfw/drawogl.c
index 1844dcc..7c60225 100644
--- a/src/osd/glfw/drawogl.c
+++ b/src/osd/glfw/drawogl.c
@@ -1551,6 +1552,10 @@ static int drawogl_window_draw(sdl_window_info *window, UINT32 dc, int update)
 #else
        SDL_GL_SwapWindow(window->sdl_window);
 #endif
+
+       // Vsync multithreading lock release
+       osd_event_set(window->vsync_flip);
+
        return 0;
 }

diff --git a/src/osd/glfw/video.c b/src/osd/glfw/video.c
index 12e77db..e1d8313 100644
--- a/src/osd/glfw/video.c
+++ b/src/osd/glfw/video.c
@@ -329,6 +329,7 @@ sdl_monitor_info *sdlvideo_monitor_from_handle(UINT32 hmonitor)
 //  update
 //============================================================
 
+#include <unistd.h>
 void sdl_osd_interface::update(bool skip_redraw)
 {
        sdl_window_info *window;
@@ -343,6 +344,8 @@ void sdl_osd_interface::update(bool skip_redraw)
        {
 //      profiler_mark(PROFILER_BLIT);
                 for (window = sdl_window_list; window != NULL; window = window->next) {
+                       osd_event_wait(window->vsync_flip, 20000);
+
                         sdlwindow_video_window_update(&machine(), window);
                         if (machine().redraw != 0)
                         {

diff --git a/src/osd/glfw/window.c b/src/osd/glfw/window.c
index 7d21423..967d3b4 100644
--- a/src/osd/glfw/window.c
+++ b/src/osd/glfw/window.c
@@ -698,6 +704,7 @@ int sdlwindow_video_window_create(running_machine *machine, int index, sdl_monit
 
        // create an event that we can use to skip blitting
        window->rendered_event = osd_event_alloc(FALSE, TRUE);
+       window->vsync_flip = osd_event_alloc(FALSE, TRUE);
 
        // load the layout
        window->target = machine->render().target_alloc();
@@ -793,6 +800,7 @@ static void sdlwindow_video_window_destroy(running_machine *machine, sdl_window_
 
        // free the event
        osd_event_free(window->rendered_event);
+       osd_event_free(window->vsync_flip);
 
        // free the window itself
        global_free(window);
@@ -1012,8 +1020,10 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                        wp.machine = machine;
 
                        execute_async(&draw_video_contents_wt, &wp);
-               }
-       }
+               } else
+                       osd_event_set(window->vsync_flip);
+       } else
+               osd_event_set(window->vsync_flip);
 }
 
 diff --git a/src/osd/glfw/window.h b/src/osd/glfw/window.h
index f488652..23a27fc 100644
--- a/src/osd/glfw/window.h
+++ b/src/osd/glfw/window.h
@@ -93,6 +93,8 @@ struct _sdl_window_info
        // GL specific
        int                                     prescale;
 
+       osd_event *                             vsync_flip;
+
 #if (SDL_VERSION_ATLEAST(1,3,0))
        // Needs to be here as well so we can identify window
        SDL_Window                      *sdl_window;




As you can see, this is exactly the same type of wait they use for the render event in the osd update function, except in that they just signal it and never really wait since the timeout is set to 0 for it for some reason.  I'm not sure if there's a better function to use for the osd_event * vsync_flip, but I'm pretty sure it's close (maybe the locking functions instead of the waiting ones?).

It sounds good to put that into the throttle part, I need to see how to allow that access to the osd_event, think I can make an update type function which calls the wait possibly.

The windows part seems to be able to lock a similar way, of course can make a different vsync_flip type function for both OSD types if it needs to be different.  It's actually interesting seeing the difference between the windows way and sdl linux way of doing this for the osd...


Windows:
Code: [Select]
        // if we're visible and running and not in the middle of a resize, draw
        if (window->hwnd != NULL && window->target != NULL && window->drawdata != NULL)
        {
                int got_lock = TRUE;

                mtlog_add("winwindow_video_window_update: try lock");

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

                // only render if we were able to get the lock
                if (got_lock)
                {
                        render_primitive_list *primlist;

                        mtlog_add("winwindow_video_window_update: got lock");

                        // don't hold the lock; we just used it to see if rendering was still happening
                        osd_lock_release(window->render_lock);

                        // ensure the target bounds are up-to-date, and then get the primitives
                        primlist = (*draw.window_get_primitives)(window);

                        // post a redraw request with the primitive list as a parameter
                        last_update_time = timeGetTime();
                        mtlog_add("winwindow_video_window_update: PostMessage start");
                        if (multithreading_enabled)
                                PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
                        else
                                SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
                        mtlog_add("winwindow_video_window_update: PostMessage end");
                }
        }


Linux:
Code: [Select]
                // only render if we have been signalled
                if (osd_event_wait(window->rendered_event, 0))
                {
                        worker_param wp;
                        render_primitive_list *primlist;

                        clear_worker_param(&wp);

                        // ensure the target bounds are up-to-date, and then get the primitives
                        primlist = &window->get_primitives(window);

                        // and redraw now

                        wp.list = primlist;
                        wp.window = window;
                        wp.machine = machine;

                        execute_async(&draw_video_contents_wt, &wp);
                }

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 06, 2011, 12:51:30 pm
I've attached the logs with the drm debug messages (still with iso 1.269) when running glxgears for a moment, hopefully it will give some info to catch the bug.

I'll need to look more into the code to understand how the osd works and so how your patch is modifying it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 06, 2011, 01:07:15 pm
I've attached the logs with the drm debug messages (still with iso 1.269) when running glxgears for a moment, hopefully it will give some info to catch the bug.

I'll need to look more into the code to understand how the osd works and so how your patch is modifying it.

I've figured out the SDL way of doing it, and it works pretty nice, I haven't been able to test it to prove it can go above 100% CPU and use both but suspecting it can.

The Windows side is looking like I may have figured it out, still testing that.  The key in both seems to be the fact they are using the rendering lock and that isn't necessary when using multithreading in the SDL version at all.   In the Windows version that rendering lock is actually Critical section (in SDL it's a mutex from SDL) and so in Windows we actually need to guard our vsync lock with that lock when locking/unlocking the vsync lock.  It also looks like I'll need to use possibly another type of lock than the built in they use for the render_lock, since for some reason it runs but keyboard and input don't work when using it that way.  It's odd, at least it seems to allow -mt and -waitvsync and -nothrottle to all work together the same at least as without the -mt option.  We will see if the threads are actually able to gain performance in this way, or if there's bottle necks possibly from them.

SDL:
Code: [Select]
diff --git a/src/emu/video.c b/src/emu/video.c
index a0720e1..2d152b8 100644
--- a/src/emu/video.c
+++ b/src/emu/video.c
@@ -248,6 +248,10 @@ void video_manager::frame_update(bool debug)
        if (!debug && !skipped_it && effective_throttle())
                update_throttle(current_time);
 
+       // Wait for vsync
+       if (!effective_throttle())
+               m_machine.osd().vsync_wait();
+
        // ask the OSD to update
        g_profiler.start(PROFILER_BLIT);
        m_machine.osd().update(!debug && skipped_it);
diff --git a/src/osd/osdepend.c b/src/osd/osdepend.c
index 110387e..95022ac 100644
--- a/src/osd/osdepend.c
+++ b/src/osd/osdepend.c
@@ -131,6 +131,16 @@ void osd_interface::update_hi(bool skip_redraw)
        //
 }
 
+//-------------------------------------------------
+// Vsync wait
+//-------------------------------------------------
+
+void osd_interface::vsync_wait()
+{
+       //
+       // Wait for vsync to send update
+       //
+}
 
 //-------------------------------------------------
 //  init_debugger - perform debugger-specific
diff --git a/src/osd/osdepend.h b/src/osd/osdepend.h
index 2915286..492da72 100644
--- a/src/osd/osdepend.h
+++ b/src/osd/osdepend.h
@@ -92,6 +92,9 @@ public:
       
        //MKCHAMP - DECLARING THE NEW osd_update_hi SUB
        virtual void update_hi(bool skip_redraw);
+
+       // vsync locking
+       virtual void vsync_wait();
       
 private:
        // internal state
diff --git a/src/osd/sdl/osdsdl.h b/src/osd/sdl/osdsdl.h
index 5b280fc..4ab7ec7 100644
--- a/src/osd/sdl/osdsdl.h
+++ b/src/osd/sdl/osdsdl.h
@@ -145,6 +145,9 @@ public:
        virtual void update(bool skip_redraw);
        virtual void update_hi(bool skip_redraw);
 
+       // vsync wait
+       virtual void vsync_wait();
+
        // debugger overridables
        virtual void init_debugger();
        virtual void wait_for_debugger(device_t &device, bool firststop);
diff --git a/src/osd/sdl/video.c b/src/osd/sdl/video.c
index 32ef4c8..c03a7f4 100644
--- a/src/osd/sdl/video.c
+++ b/src/osd/sdl/video.c
@@ -81,6 +81,7 @@ osd_gl_dispatch *gl_dispatch;
 
 static sdl_monitor_info *primary_monitor;
 static sdl_monitor_info *sdl_monitor_list;
+static int multithreading_enabled;
 
 //============================================================
 //  PROTOTYPES
@@ -326,6 +327,28 @@ sdl_monitor_info *sdlvideo_monitor_from_handle(UINT32 hmonitor)
 
 
 //============================================================
+// vsync_wait
+//============================================================
+void sdl_osd_interface::vsync_wait()
+{
+       sdl_window_info *window;
+
+       if( video_config.perftest || !multithreading_enabled)
+               return;
+
+       if (machine().video().throttled())
+               return;
+
+       for (window = sdl_window_list; window != NULL; window = window->next) {
+               while (!osd_event_wait(window->vsync_wait, osd_ticks_per_second())) {
+                       mame_printf_warning("vsync_wait: osd_event_wait timed out\n");
+               }
+       }
+       return;
+}
+
+
+//============================================================
 //  update
 //============================================================
 
@@ -349,11 +372,17 @@ void sdl_osd_interface::update(bool skip_redraw)
                                 int i;
                                 for (i = 0; i < machine().redraw; i++)
                                 {
+                                       vsync_wait();
                                         sdlwindow_video_window_update(&machine(), window);
                                 }
                         }
                 }
 //      profiler_mark(PROFILER_END);
+       } else if (multithreading_enabled && !machine().video().throttled()) {
+                for (window = sdl_window_list; window != NULL; window = window->next) {
+                       osd_event_set(window->vsync_wait);
+                       mame_printf_warning("update: osd_event_set removing vsync lock\n");
+               }
        }
 
        // poll the joystick values here
@@ -689,6 +718,8 @@ static void extract_video_config(running_machine *machine)
        video_config.restrictonemonitor = !options_get_bool(machine->options(), SDLOPTION_USEALLHEADS);
        #endif
 
+       multithreading_enabled = options_get_bool(machine->options(), SDLOPTION_MULTITHREADING);
+
 
        if (machine->debug_flags & DEBUG_FLAG_OSD_ENABLED)
                video_config.windowed = TRUE;
diff --git a/src/osd/sdl/window.c b/src/osd/sdl/window.c
index 404dd0a..105d044 100644
--- a/src/osd/sdl/window.c
+++ b/src/osd/sdl/window.c
@@ -694,6 +694,9 @@ int sdlwindow_video_window_create(running_machine *machine, int index, sdl_monit
        // create an event that we can use to skip blitting
        window->rendered_event = osd_event_alloc(FALSE, TRUE);
 
+       // wait event for vsync before we draw again
+       window->vsync_wait = osd_event_alloc(FALSE, TRUE);
+
        // load the layout
        window->target = machine->render().target_alloc();
 
@@ -788,6 +791,7 @@ static void sdlwindow_video_window_destroy(running_machine *machine, sdl_window_
 
        // free the event
        osd_event_free(window->rendered_event);
+       osd_event_free(window->vsync_wait);
 
        // free the window itself
        global_free(window);
@@ -990,7 +994,7 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                }
 
                // only render if we have been signalled
-               if (osd_event_wait(window->rendered_event, 0))
+               if (multithreading_enabled || osd_event_wait(window->rendered_event, 0))
                {
                        worker_param wp;
                        render_primitive_list *primlist;
@@ -1007,7 +1011,13 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                        wp.machine = machine;
 
                        execute_async(&draw_video_contents_wt, &wp);
+               } else if( !video_config.perftest && multithreading_enabled && !machine->video().throttled()) {
+                       osd_event_set(window->vsync_wait);
+                       mame_printf_warning("window_update: osd_event_set removing vsync lock from wait timeout\n");
                }
+       } else if( !video_config.perftest && multithreading_enabled && !machine->video().throttled()) {
+               osd_event_set(window->vsync_wait);
+               mame_printf_warning("window_update: osd_event_set removing vsync lock from target = NULL\n");
        }
 }
 
@@ -1229,8 +1239,13 @@ static OSDWORK_CALLBACK( draw_video_contents_wt )
        {
                if( video_config.perftest )
                        measure_fps(window, dc, update);
-               else
+               else {
                        window->draw(window, dc, update);
+                       if (multithreading_enabled && !wp->machine->video().throttled()) {
+                               osd_event_set(window->vsync_wait);
+                               //mame_printf_warning("draw: osd_event_set removing vsync lock from draw vsync\n");
+                       }
+               }
        }
 
        /* all done, ready for next */
diff --git a/src/osd/sdl/window.h b/src/osd/sdl/window.h
index fe993c6..090ff52 100644
--- a/src/osd/sdl/window.h
+++ b/src/osd/sdl/window.h
@@ -70,6 +70,7 @@ struct _sdl_window_info
 
        // rendering info
        osd_event *                     rendered_event;
+       osd_event *                     vsync_wait;
        render_target *         target;
        render_primitive_list *primlist;


Windows: (currently breaks input)
Code: [Select]
diff --git a/src/osd/windows/video.c b/src/osd/windows/video.c
index e64dfcc..f209f32 100644
--- a/src/osd/windows/video.c
+++ b/src/osd/windows/video.c
@@ -87,7 +87,7 @@ win_video_config video_config;
 // monitor info
 win_monitor_info *win_monitor_list;
 static win_monitor_info *primary_monitor;
-
+static int multithreading_enabled;
 
 
 //============================================================
@@ -207,6 +207,25 @@ win_monitor_info *winvideo_monitor_from_handle(HMONITOR hmonitor)
        return NULL;
 }
 
+//============================================================
+//  vsync_wait
+//============================================================
+
+void windows_osd_interface::vsync_wait()
+{
+       if (machine().video().throttled() || !video_config.waitvsync)
+               return;
+
+       if (!multithreading_enabled)
+               return;
+
+       for (win_window_info *window = win_window_list; window != NULL; window = window->next) {
+               osd_lock_acquire(window->render_lock);
+               osd_lock_acquire(window->vsync_lock);
+               osd_lock_release(window->render_lock);
+       }
+       return;
+}
 
 
 //============================================================
@@ -224,7 +243,7 @@ void windows_osd_interface::update(bool skip_redraw)
         }
 
        // if we're not skipping this redraw, update all windows
-       if (!skip_redraw)
+       if (!skip_redraw) {
                for (win_window_info *window = win_window_list; window != NULL; window = window->next)
                {
                        winwindow_video_window_update(window);
@@ -233,10 +252,19 @@ void windows_osd_interface::update(bool skip_redraw)
                                int i;
                                for (i = 0; i < machine().redraw; i++)
                                {
+                                      vsync_wait();
                                        winwindow_video_window_update(window);
                                }
                        }
                }
+       } else {
+               for (win_window_info *window = win_window_list; window != NULL; window = window->next) {
+                       osd_lock_acquire(window->render_lock);
+                       osd_lock_release(window->vsync_lock);
+                       osd_lock_release(window->render_lock);
+               }
+       }
+               
 
        // poll the joystick values here
        winwindow_process_events(&machine(), TRUE);
@@ -273,7 +301,7 @@ void windows_osd_interface::update_hi(bool skip_redraw)
                                }
                        }
                }
-        }
+        }
 
        // poll the joystick values here
        winwindow_process_events(&machine(), TRUE);
@@ -447,6 +475,8 @@ static void extract_video_config(running_machine *machine)
        video_config.keepaspect    = options_get_bool(machine->options(), WINOPTION_KEEPASPECT);
        video_config.numscreens    = options_get_int(machine->options(), WINOPTION_NUMSCREENS);
 
+       multithreading_enabled = options_get_bool(machine->options(), WINOPTION_MULTITHREADING);
+
        // if we are in debug mode, never go full screen
        if (machine->debug_flags & DEBUG_FLAG_OSD_ENABLED)
                video_config.windowed = TRUE;
diff --git a/src/osd/windows/window.c b/src/osd/windows/window.c
index aac1453..40b38a9 100644
--- a/src/osd/windows/window.c
+++ b/src/osd/windows/window.c
@@ -634,6 +634,7 @@ void winwindow_video_window_create(running_machine *machine, int index, win_moni
 
        // create a lock that we can use to skip blitting
        window->render_lock = osd_lock_alloc();
+       window->vsync_lock = osd_lock_alloc();
 
        // load the layout
        window->target = machine->render().target_alloc();
@@ -704,6 +705,7 @@ static void winwindow_video_window_destroy(win_window_info *window)
 
        // free the lock
        osd_lock_free(window->render_lock);
+       osd_lock_free(window->vsync_lock);
 
        // free the window itself
        global_free(window);
@@ -763,7 +765,9 @@ void winwindow_video_window_update(win_window_info *window)
                mtlog_add("winwindow_video_window_update: try lock");
 
                // only block if we're throttled
-               if (window->machine->video().throttled() || timeGetTime() - last_update_time > 250)
+               if (multithreading_enabled && !window->machine->video().throttled())
+                       got_lock = TRUE;
+               else if (window->machine->video().throttled() || timeGetTime() - last_update_time > 250)
                        osd_lock_acquire(window->render_lock);
                else
                        got_lock = osd_lock_try(window->render_lock);
@@ -776,7 +780,8 @@ void winwindow_video_window_update(win_window_info *window)
                        mtlog_add("winwindow_video_window_update: got lock");
 
                        // don't hold the lock; we just used it to see if rendering was still happening
-                       osd_lock_release(window->render_lock);
+                       if (!multithreading_enabled && window->machine->video().throttled())
+                               osd_lock_release(window->render_lock);
 
                        // ensure the target bounds are up-to-date, and then get the primitives
                        primlist = (*draw.window_get_primitives)(window);
@@ -790,6 +795,10 @@ void winwindow_video_window_update(win_window_info *window)
                                SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
                        mtlog_add("winwindow_video_window_update: PostMessage end");
                }
+       } else {
+               osd_lock_acquire(window->render_lock);
+               osd_lock_release(window->vsync_lock);
+               osd_lock_release(window->render_lock);
        }
 
        mtlog_add("winwindow_video_window_update: end");
@@ -1524,8 +1533,11 @@ static void draw_video_contents(win_window_info *window, HDC dc, int update)
                {
                        (*draw.window_draw)(window, dc, update);
                        mtlog_add("draw_video_contents: drawing finished");
+
+                       osd_lock_release(window->vsync_lock);
+                       mtlog_add("draw_video_contents: vsync lock released");
                }
-       }
+       }
 
        osd_lock_release(window->render_lock);
        mtlog_add("draw_video_contents: render lock released");
diff --git a/src/osd/windows/window.h b/src/osd/windows/window.h
index e8be2ac..9141ffd 100644
--- a/src/osd/windows/window.h
+++ b/src/osd/windows/window.h
@@ -97,6 +97,7 @@ struct _win_window_info
 
        // rendering info
        osd_lock *                      render_lock;
+       osd_lock *                      vsync_lock;
        render_target *         target;
        int                                     targetview;
        int                                     targetorient;
diff --git a/src/osd/windows/winmain.h b/src/osd/windows/winmain.h
index b5f5421..7f6fa77 100644
--- a/src/osd/windows/winmain.h
+++ b/src/osd/windows/winmain.h
@@ -164,6 +164,8 @@ public:
        //MKChamp - Declaring hi subroutine
        virtual void update_hi(bool skip_redraw);
 
+       // wait for vsync
+       virtual void vsync_wait();
 private:
        static void osd_exit(running_machine &machine);

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 07, 2011, 07:10:18 am
I've managed to patch if for Windows so both threads are synched through the VBLANK, so it's working now with multithreading 1 + throttle 0 + triplebuffer 1. I'm using the SetEvent / WaitForSingleObject Windows logic, and fortunately only the /src/osd/windows/window.c file needs to be patched.

Code: [Select]
diff -Nru a/src/osd/windows/window.c b/src/osd/windows/window.c
--- a/src/osd/windows/window.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/window.c 2011-01-07 12:55:40.000000000 +0100
@@ -148,6 +148,7 @@
 
 static HANDLE ui_pause_event;
 static HANDLE window_thread_ready_event;
+static HANDLE video_ready_event;
 
 
 
@@ -243,6 +244,11 @@
  ui_pause_event = CreateEvent(NULL, TRUE, FALSE, NULL);
  if (!ui_pause_event)
  fatalerror("Failed to create pause event");
+
+ // create an event to wait for video update
+ video_ready_event = CreateEvent(NULL, FALSE, FALSE, NULL);
+ if (!video_ready_event)
+ fatalerror("Failed to create video ready event");
 
  // if multithreading, create a thread to run the windows
  if (multithreading_enabled)
@@ -328,6 +334,10 @@
  if (ui_pause_event)
  CloseHandle(ui_pause_event);
 
+ // kill the video ready event
+ if (video_ready_event)
+ CloseHandle(video_ready_event);
+
  // kill the window thread ready event
  if (window_thread_ready_event)
  CloseHandle(window_thread_ready_event);
@@ -779,6 +789,9 @@
  else
  SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
  mtlog_add("winwindow_video_window_update: PostMessage end");
+
+ // wait for video update
+ WaitForSingleObject(video_ready_event, INFINITE);
  }
  }
 
@@ -1364,6 +1377,8 @@
  mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW end");
 
  ReleaseDC(wnd, hdc);
+ // inform main thread video update is done
+ SetEvent(video_ready_event);
  break;
  }
 

On the bad side, this patch only works when in fullscreen, so as soon as we switch to windowed mode or minimize it, the VBLANK signal is not available anymore so the fps gets crazy again. That's not so important as the aim of this is to run fullscreen all the time. However, in order to be perfect, the emulator part should be patched too, so we could keep throttle enabled all the time, but when we set mame for vsync or triplebuffer, just have the throttle function to exit itself, to avoid waiting twice, and when windowed or minimized or not vsynched, then use the normal throttle sleep wait.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 07, 2011, 07:21:24 am
I've managed to patch if for Windows so both threads are synched through the VBLANK, so it's working now with multithreading 1 + throttle 0 + triplebuffer 1. I'm using the SetEvent / WaitForSingleObject Windows logic, and fortunately only the /src/osd/windows/window.c file needs to be patched.

Code: [Select]
diff -Nru a/src/osd/windows/window.c b/src/osd/windows/window.c
--- a/src/osd/windows/window.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/window.c 2011-01-07 12:55:40.000000000 +0100
@@ -148,6 +148,7 @@
 
 static HANDLE ui_pause_event;
 static HANDLE window_thread_ready_event;
+static HANDLE video_ready_event;
 
 
 
@@ -243,6 +244,11 @@
  ui_pause_event = CreateEvent(NULL, TRUE, FALSE, NULL);
  if (!ui_pause_event)
  fatalerror("Failed to create pause event");
+
+ // create an event to wait for video update
+ video_ready_event = CreateEvent(NULL, FALSE, FALSE, NULL);
+ if (!video_ready_event)
+ fatalerror("Failed to create video ready event");
 
  // if multithreading, create a thread to run the windows
  if (multithreading_enabled)
@@ -328,6 +334,10 @@
  if (ui_pause_event)
  CloseHandle(ui_pause_event);
 
+ // kill the video ready event
+ if (video_ready_event)
+ CloseHandle(video_ready_event);
+
  // kill the window thread ready event
  if (window_thread_ready_event)
  CloseHandle(window_thread_ready_event);
@@ -779,6 +789,9 @@
  else
  SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
  mtlog_add("winwindow_video_window_update: PostMessage end");
+
+ // wait for video update
+ WaitForSingleObject(video_ready_event, INFINITE);
  }
  }
 
@@ -1364,6 +1377,8 @@
  mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW end");
 
  ReleaseDC(wnd, hdc);
+ // inform main thread video update is done
+ SetEvent(video_ready_event);
  break;
  }
 

Cool, that's great, I am actually trying something similar on the SDL side right now where I'm doing all the work just in the window.c file too.  I realized that really it's at that point where after the draw primatives are prepared we need to wait for the last write to finish. 
On the bad side, this patch only works when in fullscreen, so as soon as we switch to windowed mode or minimize it, the VBLANK signal is not available anymore so the fps gets crazy again. That's not so important as the aim of this is to run fullscreen all the time. However, in order to be perfect, the emulator part should be patched too, so we could keep throttle enabled all the time, but when we set mame for vsync or triplebuffer, just have the throttle function to exit itself, to avoid waiting twice, and when windowed or minimized or not vsynched, then use the normal throttle sleep wait.  I am leaning away from changing the emu/ part now if somehow can get away with not altering it, but I did see how the minimized thing would alter things quite a bit.  I do adjust for the 'bench mark' setting I think, at least see that in there too as another thing to let just run free.  Great that you did this because the Windows side of things was making me get confused, but I did realize the issue was I couldn't open up a Critical section and needed the type of wait event you talked about and are using so this is wonderful.  Also confirms that what I'm doing in the SDL stuff to change it to just work in the window.c part is going to probably work.  I've got it mostly working but I'm seeing a slight fluctuation/jump in running speed every so often, sort of like I saw before I disabled the render_wait mutex in how I was doing it before.  Doing it this way definitely simplifies the code that has to be touched so is seeming much better than going all the way into the video.c and through that to the osd interface to the emu code.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 07, 2011, 07:40:22 am
Yeah I agree not touching the /emu part is better and cleaner, and after all who cares about the minimizing issue. At least doing this has let me have some insight on the subtle differences among triplebuffer and syncrefresh/waitvsync options, inside the ddraw layer, something I had always wondered about, and the actual sequence and order of different waits happening.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 07, 2011, 08:36:02 am
Yeah I agree not touching the /emu part is better and cleaner, and after all who cares about the minimizing issue. At least doing this has let me have some insight on the subtle differences among triplebuffer and syncrefresh/waitvsync options, inside the ddraw layer, something I had always wondered about, and the actual sequence and order of different waits happening.


Wow it's amazing how much simpler the SDL patch is now and same results, possibly even better ones most likely..

Code: [Select]
diff --git a/src/osd/sdl/window.c b/src/osd/sdl/window.c
index 404dd0a..e4615e4 100644
--- a/src/osd/sdl/window.c
+++ b/src/osd/sdl/window.c
@@ -990,7 +990,7 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                }
 
                // only render if we have been signalled
-               if (osd_event_wait(window->rendered_event, 0))
+               if ((video_config.waitvsync && multithreading_enabled) || osd_event_wait(window->rendered_event, 0))
                {
                        worker_param wp;
                        render_primitive_list *primlist;
@@ -1007,6 +1007,10 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                        wp.machine = machine;
 
                        execute_async(&draw_video_contents_wt, &wp);
+
+                       // wait for last vsync to finish
+                       if (video_config.waitvsync && multithreading_enabled)
+                               osd_event_wait(window->rendered_event, osd_ticks_per_second() * 10000);
                }
        }
 }
@@ -1234,9 +1238,13 @@ static OSDWORK_CALLBACK( draw_video_contents_wt )
        }
 
        /* all done, ready for next */
-       osd_event_set(window->rendered_event);
+       if (!(video_config.waitvsync && multithreading_enabled))
+               osd_event_set(window->rendered_event);
        osd_free(wp);
 
+       if (video_config.waitvsync && multithreading_enabled)
+               osd_event_set(window->rendered_event);
+
        return NULL;
 }

Basically the 'rendered_event' SDL_mutex is just used slightly different in the vsyncwait+multithread case and given the ability to sleep.  It's interesting because what we essentially are doing is using the vsync to throttle and doing the sleep there, seems like the actual best correct way to do it other than the single threaded forced wait through drawing to the video buffer.  It's definitely nice to learn more about the internals of what we are trying to get to run with the vertical refresh, amazing though how much extra code I thought it'd take but this is all it actually needs.  Seeing your changes helped because I realized the places I was trying the new method in just window.c needed to happen a bit later than I was doing them, and looks like that was why I was seeing the slight speed hiccups every 30 seconds or so.  
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 07, 2011, 09:42:10 am
Yeah I agree not touching the /emu part is better and cleaner, and after all who cares about the minimizing issue. At least doing this has let me have some insight on the subtle differences among triplebuffer and syncrefresh/waitvsync options, inside the ddraw layer, something I had always wondered about, and the actual sequence and order of different waits happening.

I just submitted the SDL code/diff to the mame developers email address, If you want me to I can your windows one against 0141 and send it in your name or you can send it when you feel it's complete.  I think it'd be good to get both of these into mame so we don't have to worry about changes and also they might actually see something else and improve the vsync wait and multithreading some way we haven't thought of.  From the simplicity of both patches and pretty much cut and dry target at allowing waitvsync and multithreading to work normal and not break things, seems like a pretty straight forward fix that's needed and not a separate branch/patch from mame.  It's at least worth a shot, I'm guessing they'll be interested, might be open bugs or already a well known issue they just haven't had time to address and this might give them a handle on how to solve it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 07, 2011, 09:56:47 am
Oh, thanks so much, if you could also post my Windows patch. Even if they found a better way to do it, it's good to let them now as this issue should actually be addressed at some point, it's not really a hack but a feature that should be there.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 07, 2011, 10:09:46 am
Oh, thanks so much, if you could also post my Windows patch. Even if they found a better way to do it, it's good to let them now as this issue should actually be addressed at some point, it's not really a hack but a feature that should be there.
I just sent it too.  Thinking about it seems like this basically allows the whole rendering/setup of the next frame update while the current write is being performed and vsync is being waited for by the drawing to the video card.  So hopefully from that angle, this seems like a good patch.  I'm thinking that possibly there are other things tied into the frame write which could be separated out like input event polling?  I'm not sure though if there are things that should be separated from the vsync/throttle waiting or if that actually is a bad thing and would probably throw the whole thing out of sync.  Possibly just the preparation of them though if not already done with the way it is currently, interesting to look and see to learn more, but thinking it's possibly the limit of multithreading gain just be what we've done.  At least from everything I've read seems to say that the way mame currently multithreads is as good as it can get from the technical limitations of being an emulator.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 07, 2011, 10:53:22 am
Yes, page flipping is performed right when the electron beam starts its way up to the top of the screen, so when it begins drawing the screen the video memory buffer is already correct, and right after page flipping function returns the event is set so we start rendering the next frame while the electron beam is starting doing its work drawing the screen with the previous frame info, and if we are quick enough we'll end rendering the current frame before the previous one is completely drawn, so at that point we store the current frame into the back buffer and wait until the electron beam reaches the bottom, then we page flip and go on, so it's our videocard the one that provides the external timer we need and the cpu is released when we set it to wait.

For what I'm seeing, although the input is passed by the main thread, it's actually processed on the window thread. That makes me think that waiting for vsync in the window_proc callback is not a good idea as the thread will be locked for input during an instant. IDirectDraw7_WaitForVerticalBlank function had a param for passing it an event handle so that the waiting could be performed in a separate thread, but unfortunately they never supported it. So hopefully that is not affecting input too much, but anyway it was doing right that before multithreading, that might be a reason why different people have reported input lag when doing triplebuffer. The input lag by the way is something that should be studied to see if there's some way to reduce it. I read some time ago in the Soft-15KHz thread that SailorSat was working in a patch for polling the keyboard in a more effective way, it would be nice to know what he thinks.


Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on January 07, 2011, 11:42:39 am
I had the most bizarre input lag issue for a while when using triple buffering or vsync. It was most noticeable with trackball games-- rapid movement such as moving in one direction while simultaneously making loops (spiraling sideways, if you will) would begin to 'queue up' the input and then 'play it back' at a speed slower than originally inputted. It seemed to catch up when no input was being given. Sometimes this would lag input upwards of 2-3 seconds.

Doing some forum digging makes me think this might have been a quirk of ATI video drivers rather than mame; but deleting all the .INI files and starting fresh seemed to resolve it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 07, 2011, 04:06:43 pm
This patch should in theory make input really responsive and fine grained (I'm not sure if I'm missing something where the main mame emu layer needs to also be running too?), this is only for the SDL layer but guessing the same could be done in the Windows changes for vsync+multithreading. 

Code: [Select]
diff --git a/src/osd/sdl/video.c b/src/osd/sdl/video.c
index 32ef4c8..e760797 100644
--- a/src/osd/sdl/video.c
+++ b/src/osd/sdl/video.c
@@ -338,6 +338,10 @@ void sdl_osd_interface::update(bool skip_redraw)
                 skip_redraw = 0;
         }
 
+       // poll the joystick values here
+       sdlinput_poll(&machine());
+       check_osd_inputs(&machine());
+
        // if we're not skipping this redraw, update all windows
        if (!skip_redraw)
        {
diff --git a/src/osd/sdl/window.c b/src/osd/sdl/window.c
index 69bfe65..0ac3506 100644
--- a/src/osd/sdl/window.c
+++ b/src/osd/sdl/window.c
@@ -1009,8 +1009,14 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                        execute_async(&draw_video_contents_wt, &wp);
 
                        // wait for last vsync to finish
-                       if (video_config.waitvsync && multithreading_enabled)
-                               osd_event_wait(window->rendered_event, osd_ticks_per_second() * 10000);
+                       if (video_config.waitvsync && multithreading_enabled) {
+                               bool got_lock = FALSE;
+                               got_lock = osd_event_wait(window->rendered_event, 0);
+                               while (!got_lock) {
+                                       sdlinput_poll(machine);
+                                       got_lock = osd_event_wait(window->rendered_event, 1000);
+                               }
+                       }
                }
        }
 }


Basically the polling of the input seems to be done in that update osd function called from the emu layer, and so when we are waiting for the last vblank to happen, I'm just running that input polling the whole time.  So there's not any time period, besides 1000 milliseconds which should be nothing, where we aren't checking the input polling when in threading mode with vsync enabled.  Seems like what the issue would be with setups in the past having issues, and from just trying this, although I may just be having a placebo effect, seems like it's a bit more quick to respond to joystick movements.  If this isn't fully the fix, then it would also need the basic emu layer also moving to act on the input actions during this time.  I sort of doubt though that's really an issue, I'm guessing that this should remove any input lag when running without throttle and vsync.  Triple buffer may be a complete different story, I'm not sure, but it may need some other place to loop the input polling.  From what I can tell looping the input polling at any speed works fine, and it's not restricted to waiting for vblanks to occur.  That's the part I'm partly wondering about, is that really true, it so far seems correct though (unless it's basically not really helping if the actual lower emulation layer needs to also be freely running at the same time as waiting for the vblank).  Also it's interesting how with throttle, we always would be restricted it seems at not running the input like this, it's only possible through multi threading and vsync waiting together where we get this area of free looping to do tasks like input polling.  Also I found the minimum I could go is 1000 for waiting, any lower and CPU usage goes up, but at 1000 it's exactly the same as without the change.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 07, 2011, 05:54:25 pm
That patch looks really interesting, we'll need to find the right functions in the Windows part to do that. I think there will be a problem with that method in Windows, as even if we poll for inputs during the wait for event time, no input will be received as the thread that gets the input is the other one that's busy waiting for vsync. So the input will get stuck in the queue until the REDRAW message function exits. So we would need a third thread for achieving that ;) However, depending on when the usual poll is performed, it might be useful to make sure we poll for inputs right after we exit vblank and before the next frame is rendered. Anyway I may be wrong with all this, will need to look deeper.

BTW this thread is interesting, there's some comments by PsikyoFan on the input lag stuff.

http://shmups.system11.org/viewtopic.php?f=1&t=26394&start=30 (http://shmups.system11.org/viewtopic.php?f=1&t=26394&start=30)

It's also interesting this Shumpmame project, although these hacks are on the emulator layer:

http://shmups.system11.org/viewtopic.php?f=1&t=30659 (http://shmups.system11.org/viewtopic.php?f=1&t=30659)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 07, 2011, 07:18:51 pm
That patch looks really interesting, we'll need to find the right functions in the Windows part to do that. I think there will be a problem with that method in Windows, as even if we poll for inputs during the wait for event time, no input will be received as the thread that gets the input is the other one that's busy waiting for vsync. So the input will get stuck in the queue until the REDRAW message function exits. So we would need a third thread for achieving that ;) However, depending on when the usual poll is performed, it might be useful to make sure we poll for inputs right after we exit vblank and before the next frame is rendered. Anyway I may be wrong with all this, will need to look deeper.

BTW this thread is interesting, there's some comments by PsikyoFan on the input lag stuff.

http://shmups.system11.org/viewtopic.php?f=1&t=26394&start=30 (http://shmups.system11.org/viewtopic.php?f=1&t=26394&start=30)

It's also interesting this Shumpmame project, although these hacks are on the emulator layer:

http://shmups.system11.org/viewtopic.php?f=1&t=30659 (http://shmups.system11.org/viewtopic.php?f=1&t=30659)


Ah yeah, the input thing is sort of what I feared and possibly the same in SDL I'm guessing.  Although I did put the extra poll right before the part where we go into the video write stuff in that patch so it probably helps quite a bit I am guessing with just that.  Sounds like there would be some advantage to have another thread running doing input possibly just in the OSD so again wouldn't have to touch anything else that way.

Also in SDL 1.3 it seems to indicate this might be somewhat the case by default, something about a thread for it, not sure, but still figuring out.  At least seems to not hurt it with the change I made and I swear now I feel like i have more of a grasp on like pacman for instance, but then again it's hard to immediately say and might just be me thinking that or the other multithread patch doing that partly.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 08, 2011, 07:27:37 am
I've seen that the patch I posted yesterday can be made much simpler just by modifying the PostMessage api call by SendMessage (as it's done without multithreading), so it could be replaced here and have the same effect:

Code: [Select]
if (multithreading_enabled)
PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
else
SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
mtlog_add("winwindow_video_window_update: PostMessage end");

SendMessage waits, Postmessage doesn't, so we get rid of the need of creating and mantaining an event object.

I've also done this other patch, that replaces the other ones:

Code: [Select]
diff -Nru a/src/osd/windows/window.c b/src/osd/windows/window.c
--- a/src/osd/windows/window.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/window.c 2011-01-08 13:17:22.000000000 +0100
@@ -775,7 +775,14 @@
  last_update_time = timeGetTime();
  mtlog_add("winwindow_video_window_update: PostMessage start");
  if (multithreading_enabled)
- PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ {
+ HDC hdc = GetDC(window->hwnd);
+ mtlog_add("winwindow_video_window_proc: main thread video update begin");
+ window->primlist = primlist;
+ draw_video_contents(window, hdc, FALSE);
+ mtlog_add("winwindow_video_window_proc: main thread video update end");
+ ReleaseDC(window->hwnd, hdc);
+ }
  else
  SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
  mtlog_add("winwindow_video_window_update: PostMessage end");

The idea with this one is to do the video update on the main thread instead of on the window thread, so at leat in theory the window thread will be free to receive and process input while the main/emulator thread is waiting for the page flipping to happen, so we just lock one of the threads. It seems to work here, I still need to test it to see if it really improves input response, as it's something rather subjective it seems (to be honest I can't notice the difference yet even when using Shumpmame but it could be I'm testing it on a lcd that has its own lag).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 09, 2011, 01:24:33 pm
This one patch is a variation of the previous one, to allow continuous poll of the input devices during waiting for vblank.

Code: [Select]
diff -Nru a/src/osd/windows/drawdd.c b/src/osd/windows/drawdd.c
--- a/src/osd/windows/drawdd.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/drawdd.c 2011-01-09 18:43:57.000000000 +0100
@@ -55,6 +55,7 @@
 // MAMEOS headers
 #include "winmain.h"
 #include "window.h"
+#include "input.h"
 #include "config.h"
 
 
@@ -179,7 +180,7 @@
 static int drawdd_window_init(win_window_info *window);
 static void drawdd_window_destroy(win_window_info *window);
 static render_primitive_list *drawdd_window_get_primitives(win_window_info *window);
-static int drawdd_window_draw(win_window_info *window, HDC dc, int update);
+static int drawdd_window_draw(win_window_info *window, HDC dc, int update, running_machine *machine);
 
 // surface management
 static int ddraw_create(win_window_info *window);
@@ -344,7 +345,7 @@
 //  drawdd_window_draw
 //============================================================
 
-static int drawdd_window_draw(win_window_info *window, HDC dc, int update)
+static int drawdd_window_draw(win_window_info *window, HDC dc, int update, running_machine *machine)
 {
  dd_info *dd = (dd_info *)window->drawdata;
  render_primitive *prim;
@@ -457,10 +458,12 @@
  if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X unlocking blit surface\n", (int)result);
 
  // sync to VBLANK
- if ((video_config.waitvsync || video_config.syncrefresh) && window->machine->video().throttled() && (!window->fullscreen || dd->back == NULL))
+ if ((video_config.waitvsync || video_config.syncrefresh))
  {
- result = IDirectDraw7_WaitForVerticalBlank(dd->ddraw, DDWAITVB_BLOCKBEGIN, NULL);
- if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X waiting for VBLANK\n", (int)result);
+ BOOL lpbIsInVB;
+ while (IDirectDraw7_GetVerticalBlankStatus(dd->ddraw, &lpbIsInVB) == DD_OK && lpbIsInVB == FALSE)
+ {
+ winwindow_process_events(machine, TRUE);
+ wininput_poll(machine);
+ }
  }
 
  // complete the blitting
diff -Nru a/src/osd/windows/video.c b/src/osd/windows/video.c
--- a/src/osd/windows/video.c 2010-11-06 18:24:58.000000000 +0100
+++ b/src/osd/windows/video.c 2011-01-09 18:48:50.000000000 +0100
@@ -221,7 +221,7 @@
  // if we're not skipping this redraw, update all windows
  if (!skip_redraw)
  for (win_window_info *window = win_window_list; window != NULL; window = window->next)
- winwindow_video_window_update(window);
+ winwindow_video_window_update(window, &machine());
 
  // poll the joystick values here
  winwindow_process_events(&machine(), TRUE);
diff -Nru a/src/osd/windows/window.c b/src/osd/windows/window.c
--- a/src/osd/windows/window.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/window.c 2011-01-09 17:03:16.000000000 +0100
@@ -157,7 +157,7 @@
 
 static void winwindow_exit(running_machine &machine);
 static void winwindow_video_window_destroy(win_window_info *window);
-static void draw_video_contents(win_window_info *window, HDC dc, int update);
+static void draw_video_contents(win_window_info *window, HDC dc, int update, running_machine *machine);
 
 static unsigned __stdcall thread_entry(void *param);
 static int complete_create(win_window_info *window);
@@ -716,7 +716,7 @@
 //  (main thread)
 //============================================================
 
-void winwindow_video_window_update(win_window_info *window)
+void winwindow_video_window_update(win_window_info *window, running_machine *machine)
 {
  int targetview, targetorient;
  render_layer_config targetlayerconfig;
@@ -775,7 +775,16 @@
  last_update_time = timeGetTime();
  mtlog_add("winwindow_video_window_update: PostMessage start");
  if (multithreading_enabled)
- PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ {
+ HDC hdc = GetDC(window->hwnd);
+
+ mtlog_add("winwindow_video_update: video update begin");
+ window->primlist = primlist;
+ draw_video_contents(window, hdc, FALSE, machine);
+ mtlog_add("winwindow_video_update: video update end");
+
+ ReleaseDC(window->hwnd, hdc);
+ }
  else
  SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
  mtlog_add("winwindow_video_window_update: PostMessage end");
@@ -1215,7 +1224,8 @@
  {
  PAINTSTRUCT pstruct;
  HDC hdc = BeginPaint(wnd, &pstruct);
- draw_video_contents(window, hdc, TRUE);
+ if (hdc)
+ draw_video_contents(window, hdc, TRUE, NULL);
  if (win_has_menu(window))
  DrawMenuBar(window->hwnd);
  EndPaint(wnd, &pstruct);
@@ -1357,13 +1367,15 @@
  case WM_USER_REDRAW:
  {
  HDC hdc = GetDC(wnd);
+ if (hdc)
+ {
+ mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW begin");
+ window->primlist = (render_primitive_list *)lparam;
+ draw_video_contents(window, hdc, FALSE, NULL);
+ mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW end");
 
- mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW begin");
- window->primlist = (render_primitive_list *)lparam;
- draw_video_contents(window, hdc, FALSE);
- mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW end");
-
- ReleaseDC(wnd, hdc);
+ ReleaseDC(wnd, hdc);
+ }
  break;
  }
 
@@ -1409,7 +1421,7 @@
 //  (window thread)
 //============================================================
 
-static void draw_video_contents(win_window_info *window, HDC dc, int update)
+static void draw_video_contents(win_window_info *window, HDC dc, int update, running_machine *machine)
 {
  assert(GetCurrentThreadId() == window_threadid);
 
@@ -1433,7 +1445,7 @@
  // otherwise, render with our drawing system
  else
  {
- (*draw.window_draw)(window, dc, update);
+ (*draw.window_draw)(window, dc, update, machine);
  mtlog_add("draw_video_contents: drawing finished");
  }
  }
diff -Nru a/src/osd/windows/window.h b/src/osd/windows/window.h
--- a/src/osd/windows/window.h 2010-10-18 02:51:58.000000000 +0200
+++ b/src/osd/windows/window.h 2011-01-09 14:16:58.000000000 +0100
@@ -122,7 +122,7 @@
 
  int (*window_init)(win_window_info *window);
  render_primitive_list *(*window_get_primitives)(win_window_info *window);
- int (*window_draw)(win_window_info *window, HDC dc, int update);
+ int (*window_draw)(win_window_info *window, HDC dc, int update, running_machine *machine);
  void (*window_destroy)(win_window_info *window);
 };
 
@@ -149,7 +149,7 @@
 
 BOOL winwindow_has_focus(void);
 void winwindow_update_cursor_state(running_machine *machine);
-void winwindow_video_window_update(win_window_info *window);
+void winwindow_video_window_update(win_window_info *window, running_machine *machine);
 win_monitor_info *winwindow_video_window_monitor(win_window_info *window, const RECT *proposed);
 
 LRESULT CALLBACK winwindow_video_window_proc(HWND wnd, UINT message, WPARAM wparam, LPARAM lparam);

It's much more code, mainly because it needs that *machine param being passed down to the ddraw layer in order to poll the inputs there, something that is not designed to be used in that scope, so it's become rather dirty because of that. It's also repairing a bug with the last patch when draw_video_contents function could actually be called again from the windowproc while still being waiting from vblank, causing a null hdc.

This patch works when using syncrefresh 1, triplebuffer 0, throttle 0, multithreading 1. So instead of triplebuffer for vsynching+page flipping, we're directly blitting to the primary surface during vblank. Instead of using WaitForVerticalBlank I'm using GetVerticalBlankStatus, that tells us the vblank state without waiting, so I do a loop there to poll the input during the wait, and still can do it while using only two threads. I haven't put any sleep during that loop (should be done), but anyway the cpu usage does not go crazy.

Of course this works with single screen games, I guess that using this method to throttle with multiple screens would have unpredictable results. So think about this as experimental stuff.

That said, I notice no difference with this method and the default in Mame, so maybe they're already doing the best possible thing when polling inputs right after returning from the update video function. Maybe the Linux implementation can take any advantage of how that os works, I don't know. I've been messing these days with Mame source, only that small part of it, and I must say I'm amazed with it. Mame is a complex object, it takes days to get to understand just any of the modules, I believe there must be very few people, if any, that really have a full understanding of the whole thing in their heads.

UPDATE: I've added the {} that were missing after the 'while', so now should be doing what it was supposed to.
 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 09, 2011, 10:14:25 pm
This one patch is a variation of the previous one, to allow continuous poll of the input devices during waiting for vblank.

Code: [Select]
diff -Nru a/src/osd/windows/drawdd.c b/src/osd/windows/drawdd.c
--- a/src/osd/windows/drawdd.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/drawdd.c 2011-01-09 18:43:57.000000000 +0100
@@ -55,6 +55,7 @@
 // MAMEOS headers
 #include "winmain.h"
 #include "window.h"
+#include "input.h"
 #include "config.h"
 
 
@@ -179,7 +180,7 @@
 static int drawdd_window_init(win_window_info *window);
 static void drawdd_window_destroy(win_window_info *window);
 static render_primitive_list *drawdd_window_get_primitives(win_window_info *window);
-static int drawdd_window_draw(win_window_info *window, HDC dc, int update);
+static int drawdd_window_draw(win_window_info *window, HDC dc, int update, running_machine *machine);
 
 // surface management
 static int ddraw_create(win_window_info *window);
@@ -344,7 +345,7 @@
 //  drawdd_window_draw
 //============================================================
 
-static int drawdd_window_draw(win_window_info *window, HDC dc, int update)
+static int drawdd_window_draw(win_window_info *window, HDC dc, int update, running_machine *machine)
 {
  dd_info *dd = (dd_info *)window->drawdata;
  render_primitive *prim;
@@ -457,10 +458,12 @@
  if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X unlocking blit surface\n", (int)result);
 
  // sync to VBLANK
- if ((video_config.waitvsync || video_config.syncrefresh) && window->machine->video().throttled() && (!window->fullscreen || dd->back == NULL))
+ if ((video_config.waitvsync || video_config.syncrefresh))
  {
- result = IDirectDraw7_WaitForVerticalBlank(dd->ddraw, DDWAITVB_BLOCKBEGIN, NULL);
- if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X waiting for VBLANK\n", (int)result);
+ BOOL lpbIsInVB;
+ while (IDirectDraw7_GetVerticalBlankStatus(dd->ddraw, &lpbIsInVB) == DD_OK && lpbIsInVB == FALSE)
+ {
+ winwindow_process_events(machine, TRUE);
+ wininput_poll(machine);
+ }
  }
 
  // complete the blitting
diff -Nru a/src/osd/windows/video.c b/src/osd/windows/video.c
--- a/src/osd/windows/video.c 2010-11-06 18:24:58.000000000 +0100
+++ b/src/osd/windows/video.c 2011-01-09 18:48:50.000000000 +0100
@@ -221,7 +221,7 @@
  // if we're not skipping this redraw, update all windows
  if (!skip_redraw)
  for (win_window_info *window = win_window_list; window != NULL; window = window->next)
- winwindow_video_window_update(window);
+ winwindow_video_window_update(window, &machine());
 
  // poll the joystick values here
  winwindow_process_events(&machine(), TRUE);
diff -Nru a/src/osd/windows/window.c b/src/osd/windows/window.c
--- a/src/osd/windows/window.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/window.c 2011-01-09 17:03:16.000000000 +0100
@@ -157,7 +157,7 @@
 
 static void winwindow_exit(running_machine &machine);
 static void winwindow_video_window_destroy(win_window_info *window);
-static void draw_video_contents(win_window_info *window, HDC dc, int update);
+static void draw_video_contents(win_window_info *window, HDC dc, int update, running_machine *machine);
 
 static unsigned __stdcall thread_entry(void *param);
 static int complete_create(win_window_info *window);
@@ -716,7 +716,7 @@
 //  (main thread)
 //============================================================
 
-void winwindow_video_window_update(win_window_info *window)
+void winwindow_video_window_update(win_window_info *window, running_machine *machine)
 {
  int targetview, targetorient;
  render_layer_config targetlayerconfig;
@@ -775,7 +775,16 @@
  last_update_time = timeGetTime();
  mtlog_add("winwindow_video_window_update: PostMessage start");
  if (multithreading_enabled)
- PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ {
+ HDC hdc = GetDC(window->hwnd);
+
+ mtlog_add("winwindow_video_update: video update begin");
+ window->primlist = primlist;
+ draw_video_contents(window, hdc, FALSE, machine);
+ mtlog_add("winwindow_video_update: video update end");
+
+ ReleaseDC(window->hwnd, hdc);
+ }
  else
  SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
  mtlog_add("winwindow_video_window_update: PostMessage end");
@@ -1215,7 +1224,8 @@
  {
  PAINTSTRUCT pstruct;
  HDC hdc = BeginPaint(wnd, &pstruct);
- draw_video_contents(window, hdc, TRUE);
+ if (hdc)
+ draw_video_contents(window, hdc, TRUE, NULL);
  if (win_has_menu(window))
  DrawMenuBar(window->hwnd);
  EndPaint(wnd, &pstruct);
@@ -1357,13 +1367,15 @@
  case WM_USER_REDRAW:
  {
  HDC hdc = GetDC(wnd);
+ if (hdc)
+ {
+ mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW begin");
+ window->primlist = (render_primitive_list *)lparam;
+ draw_video_contents(window, hdc, FALSE, NULL);
+ mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW end");
 
- mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW begin");
- window->primlist = (render_primitive_list *)lparam;
- draw_video_contents(window, hdc, FALSE);
- mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW end");
-
- ReleaseDC(wnd, hdc);
+ ReleaseDC(wnd, hdc);
+ }
  break;
  }
 
@@ -1409,7 +1421,7 @@
 //  (window thread)
 //============================================================
 
-static void draw_video_contents(win_window_info *window, HDC dc, int update)
+static void draw_video_contents(win_window_info *window, HDC dc, int update, running_machine *machine)
 {
  assert(GetCurrentThreadId() == window_threadid);
 
@@ -1433,7 +1445,7 @@
  // otherwise, render with our drawing system
  else
  {
- (*draw.window_draw)(window, dc, update);
+ (*draw.window_draw)(window, dc, update, machine);
  mtlog_add("draw_video_contents: drawing finished");
  }
  }
diff -Nru a/src/osd/windows/window.h b/src/osd/windows/window.h
--- a/src/osd/windows/window.h 2010-10-18 02:51:58.000000000 +0200
+++ b/src/osd/windows/window.h 2011-01-09 14:16:58.000000000 +0100
@@ -122,7 +122,7 @@
 
  int (*window_init)(win_window_info *window);
  render_primitive_list *(*window_get_primitives)(win_window_info *window);
- int (*window_draw)(win_window_info *window, HDC dc, int update);
+ int (*window_draw)(win_window_info *window, HDC dc, int update, running_machine *machine);
  void (*window_destroy)(win_window_info *window);
 };
 
@@ -149,7 +149,7 @@
 
 BOOL winwindow_has_focus(void);
 void winwindow_update_cursor_state(running_machine *machine);
-void winwindow_video_window_update(win_window_info *window);
+void winwindow_video_window_update(win_window_info *window, running_machine *machine);
 win_monitor_info *winwindow_video_window_monitor(win_window_info *window, const RECT *proposed);
 
 LRESULT CALLBACK winwindow_video_window_proc(HWND wnd, UINT message, WPARAM wparam, LPARAM lparam);

It's much more code, mainly because it needs that *machine param being passed down to the ddraw layer in order to poll the inputs there, something that is not designed to be used in that scope, so it's become rather dirty because of that. It's also repairing a bug with the last patch when draw_video_contents function could actually be called again from the windowproc while still being waiting from vblank, causing a null hdc.

This patch works when using syncrefresh 1, triplebuffer 0, throttle 0, multithreading 1. So instead of triplebuffer for vsynching+page flipping, we're directly blitting to the primary surface during vblank. Instead of using WaitForVerticalBlank I'm using GetVerticalBlankStatus, that tells us the vblank state without waiting, so I do a loop there to poll the input during the wait, and still can do it while using only two threads. I haven't put any sleep during that loop (should be done), but anyway the cpu usage does not go crazy.

Of course this works with single screen games, I guess that using this method to throttle with multiple screens would have unpredictable results. So think about this as experimental stuff.

That said, I notice no difference with this method and the default in Mame, so maybe they're already doing the best possible thing when polling inputs right after returning from the update video function. Maybe the Linux implementation can take any advantage of how that os works, I don't know. I've been messing these days with Mame source, only that small part of it, and I must say I'm amazed with it. Mame is a complex object, it takes days to get to understand just any of the modules, I believe there must be very few people, if any, that really have a full understanding of the whole thing in their heads.

UPDATE: I've added the {} that were missing after the 'while', so now should be doing what it was supposed to.
 

Yeah that's interesting because on the SDL side for Linux the machine is brought into the input stuff already, I get the feeling in Linux SDL possibly the whole input thing is already having some advantage perhaps in how SDL input is done.  From what I can tell I think the thing I did in SDL which was pretty basic probably requires the more complicated way your doing it on the Windows side of things.  Also I saw and thought about the screen thing with more than one screen, even though only SDL 1.3 can do that for Linux, it already seems like the Linux side adapts to that case from what I can tell but guessing in the Windows side things are slightly trickier perhaps.  Could see possibly an advantage of another thread or a thread for each screen in the dual screen case, but I'm not sure if that really would be necessary.  It's definitely amazing looking at how mame works, and confusing a bit in the emulation side and I'm still tracing down the main execution of the machine/cpu's loop to really know where input and sound and video all are at during any given time.  I might be wrong, but seems like it'd be nice to have the 3 be somewhat separate and gathered by the UI from the emulation layer and have that emulation layer basically produce the video frames and audio samples, wait for input, and wait for the UI to pick each of them up through separate interfaces.  Since the timing of things are usually controlled by the throttle  stuff, and if that's off then the UI controls the timing through the vblank or triple  buffering I guess (still not sure how triple buffering times it really just by nature, guessing there's more to that and throttles in itself somewhere?).  Basically it would be interesting to have the emulation layer running waiting for input all the time, queing up audio samples and video frames or not queing but I guess having them ready and allow all three to be somewhat separate so the UI can pick them up anyway it wants in multiple threads or whatever it decides to do.  I think it's somewhat close to being that way now but sounds like the limitation is that the emulation layer really needs to be one single thread for efficiency and so we have to stop the emulation machine and wait every time we pass anything between the UI and it, else without throttle it would just go out of control and run as fast as it can without using the video frame as timing for the input (which then you've got audio which needs that timing too, so that's interesting, and I haven't fully understood yet where exactly the audio and video are timed together at all or it's just a byproduct of the single main thread waiting on the last video frame to flip/vblank to the screen). 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 11, 2011, 04:58:43 pm
Hello,


 first = Thanks  ^^

 But ... (always but .... )

 i'm lost with windows version ...

 I've just reinstalled XP sp2 on a laptop connected to a 31khz lcd monitor for tests (will be in an egret 2 15khz rotatable monitor)

 I've generated modelines for crt_emudriver_9.3_1.2 with VMMAker.exe against mame 0.140u3 home made build.

 Modelines appears in the inf file of the driver.

 I've installed the drivers, rebooted, and tried to launch a vertical game in mame :

Code: [Select]
switchres rfjet --soft15khz
[] "rfjet" vertical 320x240@54.000 (1.333) --> 432x320@54.000 (1.331)

 Now i've got two problems ... as you can see it select 432x320 instead of 320x240 ....

switchres select the good resolution if i use  mo 2 :

Code: [Select]
D:\Mame>switchres.exe rfjet --soft15khz --mo 2
[] "rfjet" vertical 320x240@54.000 (1.333) --> 320x240@54.000 (1.333)

 But image is upside down and not usable .. i mean that it is like playing a vertical game on an horizontal monitor and with a mirror ...

 How can i get a "normal" mode with good resolution (remembre that i will use my monitor in vertical mode ^^) ?

 It seems too that i'm not using 15khz mode .. because my 31k lcd (not tri sync) can handle it ...

 Do i need to install soft15khz (Thanks SailorSat too for this beautifull tool) ?

 Could you please explain a little more how to make this interesting tool to work for brainless people like me ?

 Regards

EDIT= It may be related to VMMAKer.ini .... ?

 Here is a pastebin of this config file :

http://pastebin.com/4pwCbJiP (http://pastebin.com/4pwCbJiP)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 11, 2011, 05:39:09 pm
Hi dapsaille,

First, it's not your fault you're confused. The VMMaker app was done to be used on its own for static mode lists + inis, so if you're going to use Switchres for dynamic modelines then it's better you don't create the modelines with VMMaker for now. Switchres has a pearl script for creating the mode list, but for a Windows user it may be easier for you to just install Soft-15Khz over my patched drivers, so that will replace the existing modes with its own ones. Then use a custom mode list to replace the default Soft-15Khz modelines with the ones you are going to need. I strongly recommend you to use the mode list I posted one or two pages ago.

Then, using that mode list and renaming or deleting Mame's .ini folder (important), use Switchres on it, and be sure to use the new options for vertical games on rotating monitors. I'm seeing your logs, and it seems the inis created by VMMaker are messing up Switchres command line optios, so make sure you delete or rename the .ini folder.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 11, 2011, 06:08:54 pm
Hi dapsaille,

First, it's not your fault you're confused. The VMMaker app was done to be used on its own for static mode lists + inis, so if you're going to use Switchres for dynamic modelines then it's better you don't create the modelines with VMMaker for now. Switchres has a pearl script for creating the mode list, but for a Windows user it may be easier for you to just install Soft-15Khz over my patched drivers, so that will replace the existing modes with its own ones. Then use a custom mode list to replace the default Soft-15Khz modelines with the ones you are going to need. I strongly recommend you to use the mode list I posted one or two pages ago.

Then, using that mode list and renaming or deleting Mame's .ini folder (important), use Switchres on it, and be sure to use the new options for vertical games on rotating monitors. I'm seeing your logs, and it seems the inis created by VMMaker are messing up Switchres command line optios, so make sure you delete or rename the .ini folder.

 Thanks for your reply ..

 I've checked your modelist but i cannot find 320x240@56 .....
and if i use 320x240@60 i got horrible tearing for backgrounds in rfjet (and i'me sure that it's not present in the original pcb, i own it ^^)
I can see a modelines file generated by vmmaker ... can i use it contents as a usermodes.txt for soft15khz ?

 I must admit that if i can do that .. i don't understand the advantages of switchres  :P ....

 I'm trying what you say now .

 Thanks again

 I was thinking that switchres will extract
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 11, 2011, 06:14:02 pm
You don't need the 320x240@56 anymore as it will be generated out of the 320x240@60 dummy modeline, tweaking it right before starting Mame. So using Switchres you can have infinite modelines.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 11, 2011, 06:16:44 pm
You don't need the 320x240@56 anymore as it will be generated out of the 320x240@60 dummy modeline, tweaking it right before starting Mame. So using Switchres you can have infinite modelines.



 humm .. i like magic  ;D ..

 so switchres extract the resolution informations from mame.exe itself ?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 11, 2011, 06:17:21 pm
Hi dapsaille,

First, it's not your fault you're confused. The VMMaker app was done to be used on its own for static mode lists + inis, so if you're going to use Switchres for dynamic modelines then it's better you don't create the modelines with VMMaker for now. Switchres has a pearl script for creating the mode list, but for a Windows user it may be easier for you to just install Soft-15Khz over my patched drivers, so that will replace the existing modes with its own ones. Then use a custom mode list to replace the default Soft-15Khz modelines with the ones you are going to need. I strongly recommend you to use the mode list I posted one or two pages ago.

Then, using that mode list and renaming or deleting Mame's .ini folder (important), use Switchres on it, and be sure to use the new options for vertical games on rotating monitors. I'm seeing your logs, and it seems the inis created by VMMaker are messing up Switchres command line optios, so make sure you delete or rename the .ini folder.

 Thanks for your reply ..

 I've checked your modelist but i cannot find 320x240@56 .....
and if i use 320x240@60 i got horrible tearing for backgrounds in rfjet (and i'me sure that it's not present in the original pcb, i own it ^^)
I can see a modelines file generated by vmmaker ... can i use it contents as a usermodes.txt for soft15khz ?

 I must admit that if i can do that .. i don't understand the advantages of switchres  :P ....

 I'm trying what you say now .

 Thanks again

 I was thinking that switchres will extract

Like Calamity says switchres can actually alter the modeline refresh rate, from 60 to 54, so that refresh rate actually doesn't matter it has.  It actually just uses the height and width and creates the rest of the modeline dynamically upon run (use -v -v options, more the more verbose, to see more info of what it's doing).

Also the key is that the 320x240 is only generated that way for a vertical game with the --mo 2 setting, since otherwise the 320 part is actually the height of the game, I think that combined with possibly the direction it's rotating (it uses -ror rotate right for mame) might be an issue.  

Basically doing what Calamity said, and running with the --mo 2 setting (and also trying --monitor cga for your 15khz arcade monitor, or --monitor generic, or --monitor h9110, or --monitor vga for the LCD screen) should be good, but of course the --mo 2 setting will rotate the image to the right and the 320x240 is in reference to the fact it's a vertical monitor.  Else it'll have to use 320 as the height and the wider width to make up for the horizontal monitor it think's it's on, or is on.  
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 11, 2011, 06:18:40 pm
You don't need the 320x240@56 anymore as it will be generated out of the 320x240@60 dummy modeline, tweaking it right before starting Mame. So using Switchres you can have infinite modelines.



 humm .. i like magic  ;D ..

 so switchres extract the resolution informations from mame.exe itself ?

Yep it looks up the xml info from mame directly, can mostly figure out if you've patched it with cabmame patches too and adjust for that.  The -v -v -v option will show you more details, and the mame command line it uses.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 11, 2011, 06:39:16 pm
Hummm ...
ok with the help of -v -v -v -v -v -v -v (and from you two of course) i understand a little more how switchres works ...

 So .. here is THE big question ...
is there is any plan (possibility) to use a real 320x240 resolution for vertical games instead of 720x512 ?

Code: [Select]
D:\Mame>switchres rfjet --soft15khz -v -v -v
snip
......
Got Soft15khz registry modeline 720x512@60 - DALDTMCRTBCD720x512x0x60:
             "720x512@60" 15.850000 720 752 824 952 512 514 519 555 -HSync -VSyn
c interlace
Setup monitor limits min=184x108 max=0x608
Using interlace
Starting with Horizontal freq of 14.850 and Vertical refresh of 54.00
Increased horizontal frequency from 14.850 to 15.250
Using 12 lines padding
# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Interlace | Virtualize | Vpad +12 l
ines | )
Setting registery video mode DALDTMCRTBCD720x512x0x60 with:
(60039/59854/60039) Modeline 14.150000 720 752 816 928 512 520 526 565 interlace

Opening  modes file for mode 720x512@54
Running Emulator: mame rfjet -resolution 720x512@60 -resolution0 720x512@60 -vid
eo ddraw -nocleanstretch -hwstretch -nochangeres -redraw auto -nothrottle -nomt
-syncrefresh -triplebuffer
Target refresh = 54.000000
Error creating DirectSound: 88780078
Average speed: 133.84% (8 seconds)
Setting registery video mode DALDTMCRTBCD720x512x0x60 with:
(59854/59854/59854) Modeline 15.850000 720 752 824 952 512 514 519 555 interlace

 Picture is OK but ... not a 320x240 (who talked about perfection ? ?)  ;D


 Thanks for all your great work
(your gentoo ebuild seems interesting too ..... time to destroy another working mamecab  :laugh:)


EDIT = don't worry abount dsound issue .. no drivers installed
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 11, 2011, 06:45:11 pm
Hummm ...
ok with the help of -v -v -v -v -v -v -v (and from you two of course) i understand a little more how switchres works ...

 So .. here is THE big question ...
is there is any plan (possibility) to use a real 320x240 resolution for vertical games instead of 720x512 ?

Code: [Select]
D:\Mame>switchres rfjet --soft15khz -v -v -v
snip
......
Got Soft15khz registry modeline 720x512@60 - DALDTMCRTBCD720x512x0x60:
             "720x512@60" 15.850000 720 752 824 952 512 514 519 555 -HSync -VSyn
c interlace
Setup monitor limits min=184x108 max=0x608
Using interlace
Starting with Horizontal freq of 14.850 and Vertical refresh of 54.00
Increased horizontal frequency from 14.850 to 15.250
Using 12 lines padding
# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Interlace | Virtualize | Vpad +12 l
ines | )
Setting registery video mode DALDTMCRTBCD720x512x0x60 with:
(60039/59854/60039) Modeline 14.150000 720 752 816 928 512 520 526 565 interlace

Opening  modes file for mode 720x512@54
Running Emulator: mame rfjet -resolution 720x512@60 -resolution0 720x512@60 -vid
eo ddraw -nocleanstretch -hwstretch -nochangeres -redraw auto -nothrottle -nomt
-syncrefresh -triplebuffer
Target refresh = 54.000000
Error creating DirectSound: 88780078
Average speed: 133.84% (8 seconds)
Setting registery video mode DALDTMCRTBCD720x512x0x60 with:
(59854/59854/59854) Modeline 15.850000 720 752 824 952 512 514 519 555 interlace

 Picture is OK but ... not a 320x240 (who talked about perfection ? ?)  ;D


 Thanks for all your great work
(your gentoo ebuild seems interesting too ..... time to destroy another working mamecab  :laugh:)


EDIT = don't worry abount dsound issue .. no drivers installed

It's actually about the monitor, you will get 320x240 with the --mo 2 setting because you'll be using a vertical monitor.  Default is --monitor cga, so on a CGA 15khz monitor you can't use more than 288 lines (vertical game, it wants 320 lines for height, too much), so it has to use interlacing and comes up with that 720x512 resolution.  Now using --monitor vga on your flatscreen should be better, and do the 320x240 fine.

Update:
So basically on your flatscreen to test,  "switchres rfjet --monitor vga -v --mo 0" will be needed, and you'll get the 432x320.  On your 15khz monitor you'll want to use  "switchres rfjet --monitor cga -v --mo 2" (default is cga type monitor) and you'll get 320x240 and it'll be correctly displayed vertically.  
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 11, 2011, 06:49:14 pm
Humm .. for now i'm only using my vga lcd monitor, not my 15khz monitor ...

 For exemple, if i use my original vertical pcb on my arcade monitor in horizontal position .... the resolution will be 320x240 like in mame, my monitor doesn't care if this is a vertical or horizontal game ..

 So why i cannot do the same with mame/switchres ?  

 I'm pretty sure that you've already answered me about this question but i must admit that my english knowledge is .... poor  :-\

UPDATE too :

Quote
On your 15khz monitor you'll want to use  "switchres rfjet --monitor cga -v --mo 2" (default is cga type monitor) and you'll get 320x240 and it'll be correctly displayed vertically. 

 Be sure that i will do it tomorrow .. for now it's 01AM and my wife will strangle me with a jamma harness if i go to my egret 2 ^^

 Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 11, 2011, 06:57:54 pm
Humm .. for now i'm only using my vga lcd monitor, not my 15khz monitor ...

 For exemple, if i use my original vertical pcb on my arcade monitor in horizontal position .... the resolution will be 320x240 like in mame, my monitor doesn't care if this is a vertical or horizontal game ..

 So why i cannot do the same with mame/switchres ?  

 I'm pretty sure that you've already answered me about this question but i must admit that my english knowledge is .... poor  :-\

UPDATE too :

Quote
On your 15khz monitor you'll want to use  "switchres rfjet --monitor cga -v --mo 2" (default is cga type monitor) and you'll get 320x240 and it'll be correctly displayed vertically. 

 Be sure that i will do it tomorrow .. for now it's 01AM and my wife will strangle me with a jamma harness if i go to my egret 2 ^^

 Thanks.

Sounds good, well not the strangle part :), but I think they key is that you'll need to use the two different command lines for each setup and the vga flatscreen horizontal just isn't going to be perfect but you'll see with the second command and same setup on the vertical arcade monitor it should be close to perfect.  Definitely great to have you testing this too, the vertical monitor support is new so if there's anything needed, I'll make sure to fix it and make it work correctly.  I *think* it is good to go, but will be interesting to see how it goes for you on the vertical arcade monitor and if  there's anything else I need to do to make it work.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 12, 2011, 05:37:47 am
 Hello,

 i've juste tested like you said and i've got the same results as in my vnc session
(i must admit that i didn't trust that the results will be differents from a vnc session, my arcade monitor will not magically invert output from vga  ;D)


 Good picture but not right resolution ...

(http://img687.imageshack.us/img687/7351/img20110112112244.th.jpg) (http://img687.imageshack.us/i/img20110112112244.jpg/)
(http://img691.imageshack.us/img691/8271/img20110112112253.th.jpg) (http://img691.imageshack.us/i/img20110112112253.jpg/)
(http://img225.imageshack.us/img225/6023/img20110112112300.th.jpg) (http://img225.imageshack.us/i/img20110112112300.jpg/)


Good resolution but ror applied .. ?

(http://img42.imageshack.us/img42/9516/img20110112112330.th.jpg) (http://img42.imageshack.us/i/img20110112112330.jpg/)
(http://img810.imageshack.us/img810/6096/img20110112112343.th.jpg) (http://img810.imageshack.us/i/img20110112112343.jpg/)
(http://img40.imageshack.us/img40/8579/img20110112112354.th.jpg) (http://img40.imageshack.us/i/img20110112112354.jpg/)


 Could it be possible to treat rfjet and other verticals roms as horizontal roms (but does it involve mame modifications) ?

 I've seen that in the second run (with mo 2) the mame commande line contain -ror ....

 I mean that for people like me who use a tate monitor, there is no difference about horitontal and vertical, we only rotate our monitors ..

 If i launch stock mame by default the picture is OK even in vga mode (except resolutions of course),
i need to do a 90degree rotation to the right with my head if i use an horizontal monitor to see the picture but ok for my vertical setup..
it is the expected results for my setup and it seems that mame or switchres WANT to treat this rom with a vertical condition who may be needed for vertical games on horizontal monitors but that don't seems to be needed for vertical monitors...
it may be the problem .. or not  :D
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 12, 2011, 08:21:46 am
Hi dapsaille,

Could it be that you've manually disabled the 'rotate' option in mame.ini?

The 'ror' param is there to do exactly what you need when no other rotation option has been modified. It's the method I was using with no problems. However, re-reading Mame's config.txt it seems it would be better not to use the 'ror' option in Switchres but the -norotate option instead:

Quote
-[no]rotate

   Rotate the game to match its normal state (horizontal/vertical). This
   ensures that both vertically and horizontally oriented games show up
   correctly without the need to rotate your monitor. If you want to keep
   the game displaying 'raw' on the screen the way it would have in the
   arcade, turn this option OFF.
The default is ON (-rotate).

That may be the correct config for tate orientation.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 12, 2011, 08:47:26 am
Hi dapsaille,

Could it be that you've manually disabled the 'rotate' option in mame.ini?

The 'ror' param is there to do exactly what you need when no other rotation option has been modified. It's the method I was using with no problems. However, re-reading Mame's config.txt it seems it would be better not to use the 'ror' option in Switchres but the -norotate option instead:

Quote
-[no]rotate

   Rotate the game to match its normal state (horizontal/vertical). This
   ensures that both vertically and horizontally oriented games show up
   correctly without the need to rotate your monitor. If you want to keep
   the game displaying 'raw' on the screen the way it would have in the
   arcade, turn this option OFF.
The default is ON (-rotate).

That may be the correct config for tate orientation.


 Calamity  .... thanks ^^

 It works perfectly with rotate 1 in mame.ini

 it is a real pleasure to retrieve exactly the same display as my pcb ....  :applaud: :applaud: :applaud:

  Many thanks to you two for helping me ^^

 If i can do any test that you want (i've got 5 cabs, 2 are TATE) don't hesiTATE (huhuhu), and i will try the gentoo ebuild on one mamecab.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 12, 2011, 10:16:11 am
Hi dapsaille,

Could it be that you've manually disabled the 'rotate' option in mame.ini?

The 'ror' param is there to do exactly what you need when no other rotation option has been modified. It's the method I was using with no problems. However, re-reading Mame's config.txt it seems it would be better not to use the 'ror' option in Switchres but the -norotate option instead:

Quote
-[no]rotate

   Rotate the game to match its normal state (horizontal/vertical). This
   ensures that both vertically and horizontally oriented games show up
   correctly without the need to rotate your monitor. If you want to keep
   the game displaying 'raw' on the screen the way it would have in the
   arcade, turn this option OFF.
The default is ON (-rotate).

That may be the correct config for tate orientation.


 Calamity  .... thanks ^^

 It works perfectly with rotate 1 in mame.ini

 it is a real pleasure to retrieve exactly the same display as my pcb ....  :applaud: :applaud: :applaud:

  Many thanks to you two for helping me ^^

 If i can do any test that you want (i've got 5 cabs, 2 are TATE) don't hesiTATE (huhuhu), and i will try the gentoo ebuild on one mamecab.

Ah great, so sounds like the -ror with -rotate basically are necessary, and I should add the -rotate option when the -ror is needed?  Had no clue about that -rotate option, and if turned off the -ror option doesn't work, odd but interesting :).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 12, 2011, 10:42:15 am
Ah great, so sounds like the -ror with -rotate basically are necessary, and I should add the -rotate option when the -ror is needed?  Had no clue about that -rotate option, and if turned off the -ror option doesn't work, odd but interesting :).

It seems we can get rid of the the -ror param by just using -rotate / -norotate. So if we explicitly use those ones when dealing with vertical games, we can override the ones in Mame.ini. Then:

- For vertical games on horizontal monitor: -rotate
- For vertical games on rotating monitor: -norotate ( = -rotate + -ror)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 12, 2011, 10:59:12 am
Ah great, so sounds like the -ror with -rotate basically are necessary, and I should add the -rotate option when the -ror is needed?  Had no clue about that -rotate option, and if turned off the -ror option doesn't work, odd but interesting :).

It seems we can get rid of the the -ror param by just using -rotate / -norotate. So if we explicitly use those ones when dealing with vertical games, we can override the ones in Mame.ini. Then:

- For vertical games on horizontal monitor: -rotate
- For vertical games on rotating monitor: -norotate ( = -rotate + -ror)


What would horizontal games on a vertical monitor need, the -ror works for that but interesting that this rotate option takes the place of it, is it just -rotate for those too then?  Is it always rotating it right I'm guessing with -rotate, and never needs to rotate left since sounds like no one mounts  monitors that way?  So basically -rotate is -ror but overrides it and seems like a more universal option to say rotate or not to rotate.

Update:

Ok from what I can tell, basically for horizontal games on the vertical  monitor actually '-rotate -rol' does the same orientation as the -norotate does, so guessing -rol is necessary and the direction to actually do the rotation in that case.  Every other case seems to be able to use -rotate and -norotate except the horizontal game on a vertical monitor.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 12, 2011, 11:50:12 am
I just uploaded compiled versions of SwitchRes 1.281-ec5b6ae which should be better about setting up the monitor orientation, please test to make sure I got it correct :) .  Also I added a few command line switches...

* --notriplebuffer - can avoid use of triple buffer and use waitvsync instead
* --threads         - use threads even with waitvsync on, only useful with patched mame (which I have windows builds up now for mess/mame 0141 with all cabmame/hiscore patches + threads patches to allow waitvsync and multithreading).
* Now the redraw option is only used in cases where it's twice the refresh rate, else it's off by default, auto seems to sometimes make mistakes.
* --noswitchres   - for those who want the command line setup wrapper features (LCD maybe), or just to test, basically avoid changing resolutions and use -noswitchres command line instead to mame without resolution args.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 12, 2011, 11:50:39 am
Ok from what I can tell, basically for horizontal games on the vertical  monitor actually '-rotate -rol' does the same orientation as the -norotate does, so guessing -rol is necessary and the direction to actually do the rotation in that case.  Every other case seems to be able to use -rotate and -norotate except the horizontal game on a vertical monitor.

Yes, I believe so, after all that case (horizontal game on vertical monitor) is not a very common one but good to have support for it. On the ror / rol subject, rotation is documented in mame.xml using degrees, so that could be used to guess if the monitor was always rotated to the same direction or not, so 90ş or 270ş could refer to that (haven't tested that).

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 12, 2011, 01:34:16 pm
Could you please build with static linked library please ? ^^

 i don't have cygwin installed nor the knowledge to build under windows
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 12, 2011, 01:38:45 pm
Could you please build with static linked library please ? ^^

 i don't have cygwin installed nor the knowledge to build under windows
It include the cygwin1.dll file which is the only one needed, so it's as static linked actually as it can be (cygwin doesn't allow static linking to that .dll file).  It just needs to be in the same directory switchres is in, or the windows system directory with other .dll files, and it should work like that.  So no need to install cygwin, that's just a runtime helper .dll included since it was compiled with cygwin.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 12, 2011, 01:52:47 pm
switchres.exe v1.281 => 58Ko
switchres.exe v1.263 => 2056ko

  ;D v1.281 complains about missing cygxml2-2.dll

 i wasn't talking about cygwin1.dll, i've got plenty in many folders on my win machine  ::)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 12, 2011, 02:01:21 pm
switchres.exe v1.281 => 58Ko
switchres.exe v1.263 => 2056ko

  ;D v1.281 complains about missing cygxml2-2.dll

 i wasn't talking about cygwin1.dll, i've got plenty in many folders on my win machine  ::)
Oh oops, I'll fix that :) forgot the correct compile option, ha I should have seen how much smaller it was than usual.


Ok there's a new one up now with the fix, thanks for catching that, has been a week or since I compiled one and totally forgot about the way I was doing it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 12, 2011, 02:05:45 pm
Thanks ^^

 I will try this new version after dinner.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: SailorSat on January 14, 2011, 03:59:47 am
Somehow this seems to get very interesting lately :)
Have to spend more time reading this thread :)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 16, 2011, 01:17:17 pm
I've been investigating the Linux kernel more and trying to find why the J-Pac setup doesn't seem to work with vblank/page flip interrupt setup of the Radeon DRM driver.  From what I can tell, the reason my d9800 works with the force option, or any arcade monitor would, is because it does do the DDC part although gives a basic empty EDID full of 0xFFFFFFFF or all ones.  Yet it does output an EDID, and in your logs (Calamity) I see no EDID seen at all compared with how mine just complains it's an invalid one (with the 4350, I'm assuming the AVGA actually does give an invalid EDID too, maybe this is another vbios change of the AVGA to do this even on a J-Pac?).  I think I am getting close to seeing something interesting, basically the DDC check may be what we need to short circuit and just create a invalid EDID full of ones and let the DRM layer of Linux pass that to the radeon and have it be happy with the j-pac after that (at least enable interrupts for the pageflip and vblank). The main interesting part of the logs, are that it never gets to even trying to check the EDID at all, which points to the first i2c transfer check for the DDC and getting the EDID data is where the failure must be happening and force-on/enable option isn't properly honored after that.  The only other possible thing I can see is that it actually is giving a valid EDID that isn't really right and so it's not saying any messages about a bad EDID, and yet that EDID doesn't allow interrupts and vblank (Which I am pretty sure this is not the case, seems like then we wouldn't need to force the output on at all for the first DVI port).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 16, 2011, 03:00:00 pm
I see what you mean and makes a lot of sense. If you are able to find that point in the code then maybe it could be modified for the case when we're forcing outputs so we fed it with a fake edid, that would be great. It's a very promising approach, and could be interesting to have a door for future testing with valid custom edids.

It seems videocards are not able to sense the jpac board in the same way they do with a monitor, I remember SailorSat mentioning that:
http://forum.arcadecontrols.com/index.php?topic=66402.msg982901#msg982901 (http://forum.arcadecontrols.com/index.php?topic=66402.msg982901#msg982901)

So it could be that the videocard just doesn't go on with checking for the edid as it does not detect any monitor. I don't know if this feature has always been there or only the newer ones are affected. So maybe my ArcadeVGA only works because it's based on an older card (I'll try to get some logs with this one if I have the chance).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: SailorSat on January 16, 2011, 03:23:24 pm
VGA cards usualy detect presence of a monitor by 75ohms resistance on the RGB pins.
The J-PAC doens't have any.
Another way of detection is a connection between pin 5 and 11, but most modern cards don't use that method.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 16, 2011, 09:19:56 pm
Calamity,

After doing more testing, I have found something interesting.  I am starting to wonder if the lack of vblank interrupts has some other cause than the J-Pac, seeing that the AVGA cab is on J-Pac and from the results of my tests.  I basically did some changes and forced EDID's, that doesn't seem to be a problem, so then bypassed the path taken for the lack of DDC, and oddly that doesn't make a difference (just makes every output say it's connected all the time, but still things work fine too when that's done).  The key though is that I started booting without any monitor connected and did see the same messages output you see, no EDID check and pretty much the same.  It still does vblank interrupts, page flipping, that way.  So from what I can tell, that is the most close to a J-Pac because there's nothing connected according to the hardware/kernel and still the interrupts happen here.  So there's this message though in your dmesg output:


Jan  6 12:14:24 GroovyArcade kernel: [    1.570616] radeon 0000:02:00.0: PCI: Disallowing DAC for device
Jan  6 12:14:24 GroovyArcade kernel: [    1.570678] radeon: No suitable DMA available.


Which is definitely a bit odd, and even though Alex Deucher didn't think that mattered I am starting to think it is the key.  That there's something different about Linux supporting your motherboard/processor and the Radeon iommu possibly.  That it essentially is refusing to run DMA and any kind of interrupts/transfers to that card, odd, my setup is a 4350 too, but if not the ATI card branding/setup difference it's something else probably. 

So we might not have a generic J-Pac issue, it may just be a non-supported hardware combination for advanced OpenGL/DRM vblank from the hardware and interrupts from the video card. 

I do have a test version you can try, I don't think it'll help but might at least be interesting and get past any possibility of it being something really that we can fix in the radeon driver code.  Otherwise this might be some completely different Linux kernel issue :/.

There's a test LiveCD version uploading in the LiveCD/Incoming/ folder right now, a Mini build so it's smaller, and when it appears in a few hours you can try it when you have time and see what the messages look like from it.  I'm still not sure if this is a good change, only if it helps this problem probably, else it's really kinda odd because it forces every arcade monitor to act more like mine with the d9800 and sees a false DDC but gets a NULL EDID (seems most likely my d9800 is just NULL/not there, but DDC is there still just doesn't find an EDID so it's in between J-Pac and a normal EDID monitor).

This will be the test version when it's uploaded :  LiveCD32-Mini-NMO-1.282-b299821.iso

Good news is the newer ISO I uploaded today has all the Multitasking + vsync support and on the 32 bit CD now I can use virtua racer with 130% cpu usage (both CPU's) and still get perfect vsync, so it's definitely no longer limited to the single CPU with that option after our patches to Mame for that.  I think running in that mode has probably made the waitvsync option feel a lot better, since it's now threading the two processes still, and also looks like it can really utilize both CPU's too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 17, 2011, 08:56:39 am
Here are the logs testing you new LiveCD32-Mini-NMO-1.282-b299821.iso, hope they help.

glxgears still shows a black screen so the issue is still there. I've turned debug messages on to get some info anyway.

It's interesting what you've tested by switching the monitor's cable off, it actually seems to point somewhere else now :(
And as you say, that DMA message might be the key.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 17, 2011, 09:45:01 am
Here are the logs testing you new LiveCD32-Mini-NMO-1.282-b299821.iso, hope they help.

glxgears still shows a black screen so the issue is still there. I've turned debug messages on to get some info anyway.

It's interesting what you've tested by switching the monitor's cable off, it actually seems to point somewhere else now :(
And as you say, that DMA message might be the key.

Ah those logs are not from the new cd :)...

[    0.000000] Linux version 2.6.36.2+ (root@arcade) (gcc version 4.4.4 (Gentoo 4.4.4-r2 p1.3, pie-0.4.5) ) #1 SMP Wed Dec 29 14:02:10 CST 2010

The new one should have this..
[    0.000000] Linux version 2.6.36.2+ (root@GroovyArcade) (gcc version 4.4.4 (Gentoo 4.4.4-r2 p1.3, pie-0.4.5) ) #1 SMP Sun Jan 16 17:17:56 CST 2011

Mainly the Jan 16th timestamp

Guessing it got mixed up possibly, also checking on the cd the version.txt file for:
GroovyArcade Mini-NMO-1.282-b299821 32bit 01-16-2011_17:58:23
To help figure out if it's the right one, might be the logs.rar file was an older one from the last version posted there (downloaded it a few times and getting the same older logs ).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 17, 2011, 09:49:20 am
Oh, let me check, I might have mixed the cds...

Checked the version.txt file: GroovyArcade Full-O-1.282-b299821 32bit 01-15-2011_22:03:46

So it's an old one isn't it? I'll download the right one later.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 17, 2011, 01:55:24 pm
Oh, let me check, I might have mixed the cds...

Checked the version.txt file: GroovyArcade Full-O-1.282-b299821 32bit 01-15-2011_22:03:46

So it's an old one isn't it? I'll download the right one later.

Yeah, that's the current Full version but not the test version in the LiveCD/Incoming/ folder :).  Also Alex got back about this and sees that it's probably more of a pci issue or platform issue rather than a radeon issue.  He recommends adding this "pci=nomsi" kernel command line option when booting on your system and see if that fixes it (but not something generally we'd want to do, since it's only to fix that specific hardware and work around for now).  Also recommends reporting the issue upstream, after we test that and see if it fixes the issue.  Have you been able to edit the grub command line in the boot menu?   It's pretty easy, just have to press 'e', here's some instructions I found that may explain it better (how to remove the splash thing below, just basically add that pci=nomsi option somewhere in this line below)...

To modify the boot options within the grub menu, highlight the operating system you want to edit and press 'e'.  You may also want to highlight the 'kernel' line press 'e' to edit and remove the word 'splash' from the end of the line.
After making any necessary modifications you can press 'b' to boot that operating system.
These modifications will not persist across reboots.


Basically change this:

kernel /boot/vmlinuz real_root=/dev/loop0 looptype=squashfs loop=/livecd.squashfs initrd udev nodevfs cdroot CGADVI video=DVI-I-1:640x480ec

To this:
kernel /boot/vmlinuz real_root=/dev/loop0 looptype=squashfs loop=/livecd.squashfs initrd udev nodevfs cdroot pci=nomsi CGADVI video=DVI-I-1:640x480ec


Try with that change, and without it, using that test Live/Mini ISO (or even try this change with the one your using, since shouldn't matter which ISO this test is tried on).  I'm pretty sure this is more of a possible working change, while the test ISO might be interesting but I suspect it'll still not help the issue.

Here's an excerpt and the URL for the MSI info, basically if this works you'll need the output of 'lspci -v' (as root, sudo -s) and send it to them:
Code: [Select]
5.1. Disabling MSIs globally
298
299 Some host chipsets simply don't support MSIs properly.  If we're
300 lucky, the manufacturer knows this and has indicated it in the ACPI
301 FADT table.  In this case, Linux will automatically disable MSIs.
302 Some boards don't include this information in the table and so we have
303 to detect them ourselves.  The complete list of these is found near the
304 quirk_disable_all_msi() function in drivers/pci/quirks.c.
305
306 If you have a board which has problems with MSIs, you can pass pci=nomsi
307 on the kernel command line to disable MSIs on all devices.  It would be
308 in your best interests to report the problem to linux-pci@vger.kernel.org
309 including a full 'lspci -v' so we can add the quirks to the kernel.

The entire MSI howto: http://www.mjmwired.net/kernel/Documentation/PCI/MSI-HOWTO.txt (http://www.mjmwired.net/kernel/Documentation/PCI/MSI-HOWTO.txt)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 17, 2011, 03:03:26 pm
I'll try to do that, however it's going to be difficult as I'm nearly blind during the grub part (jpac is not able to show a readable picture with this card). I'll let you know.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 17, 2011, 03:13:28 pm
I'll try to do that, however it's going to be difficult as I'm nearly blind during the grub part (jpac is not able to show a readable picture with this card). I'll let you know.

One way to do it, if you can open the ISO as files and edit the boot/grub.conf and boot/menu.lst files on there and do that to both of them, could be done that way.  I could make an ISO with that option too pretty easily.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 17, 2011, 03:33:07 pm
I'll try to do that, however it's going to be difficult as I'm nearly blind during the grub part (jpac is not able to show a readable picture with this card). I'll let you know.

One way to do it, if you can open the ISO as files and edit the boot/grub.conf and boot/menu.lst files on there and do that to both of them, could be done that way.  I could make an ISO with that option too pretty easily.

I am adding the nomsi option as the last option in Grub to choose, so you can test with that ISO hopefully.  Do you think that'll be able to get chosen with the monitor like it looks?  I think it'll be good to have it in there for cases like this, to be an option if the interrupts fail.  Hopefully it works that way, looks like it's not terrible to use that way, just automatically does it usually for certain motherboards and your most likely is one that needs this.  Seems that the others are also VIA ones and suspect no ones reported it yet.  At least the other test ISO should be interesting to see logs from and should have a new ISO with this kernel option up later today.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 17, 2011, 03:38:23 pm
Oh great if you can add that option, I'll be able to select it, it's readable to that point so I know where the text lines are but text itself is terribly distorted to the right and moving to the sides, specially the upper part. I'll test the Mini iso anyway to get the logs.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 17, 2011, 04:18:20 pm
Oh great if you can add that option, I'll be able to select it, it's readable to that point so I know where the text lines are but text itself is terribly distorted to the right and moving to the sides, specially the upper part. I'll test the Mini iso anyway to get the logs.
This version LiveCD32-Mini-NMO-1.283-1fd9849.iso should appear in the Incoming folder in a few hours, it'll have the nomsi option as the last choice in the Grub menu.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 17, 2011, 05:09:49 pm
I've finally tested LiveCD32-Mini-NMO-1.282-b299821.iso, logs attached.

The issue is still there. However there's something odd now, the desktop mode is doublescanned + interlaced, so I can only see the upper part. So adding that fake edid there seems to be having some unexpected effect.

I'll test the new one as soon as I can.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 17, 2011, 05:17:54 pm
I've finally tested LiveCD32-Mini-NMO-1.282-b299821.iso, logs attached.

The issue is still there. However there's something odd now, the desktop mode is doublescanned + interlaced, so I can only see the upper part. So adding that fake edid there seems to be having some unexpected effect.

I'll test the new one as soon as I can.
Yeah it actually doesn't use an EDID but just fakes the DDC so every interface is seen as 'connected'.  Makes sense sort of it does that odd doublescan/interlace thing since that's what happened in X Windows when we forced all interfaces on there too.  Hopefully the nomsi option fixes things for the interrupts, seems promising.  At least we know in general things should work fine for J-Pac, and now looks like you just have that one motherboard which is one of the lucky ones with a broken MSI and doesn't tell the system about it (I'm guessing in Windows they have it masked probably and so know to disable MSI, interestingly that motherboard was sold with the intent for Windows Vista support).  If we can confirm the MSI issue, then we'll be able to help the Linux kernel by submitting the bug about it and they can mask it in the kernel.  The others masked are similar VIA sounding models, so seems to make sense, just hopefully this is the source of the vblank bug.  The ISO should be done uploading in the next hour, so will be ready for you to test when you can.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 17, 2011, 05:26:25 pm
Sounds good, will keep an eye on it. It's been completely impossible to edit the grub line on my screen, hopefuly some day I have time to get back to that asm patch for it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 18, 2011, 06:00:44 pm
 :applaud:  :applaud:  :applaud:  :applaud:

It's working! Using this new grub option all is finally PERFECT! I can see glxgears running and vsynced, and I've been launching games with wahcade, all of them run at perfect 100% with on their correct resolutions. I'm eager to mount some drive to test all games, and hopefully install this on the hardrive soon. I'm happy you managed to figure this out, there have been so many obstacles in the way and this final one is finally beaten.

So it was that, I'm the lucky owner of one the problematic motherboards and it's a kernel issue. Hopefully they might do a fix for it, but at least with this boot option the problem is totally bypassed.

UPDATE: I've added the lspci -v output.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 18, 2011, 06:52:08 pm
:applaud:  :applaud:  :applaud:  :applaud:

It's working! Using this new grub option all is finally PERFECT! I can see glxgears running and vsynced, and I've been launching games with wahcade, all of them run at perfect 100% with on their correct resolutions. I'm eager to mount some drive to test all games, and hopefully install this on the hardrive soon. I'm happy you managed to figure this out, there have been so many obstacles in the way and this final one is finally beaten.

So it was that, I'm the lucky owner of one the problematic motherboards and it's a kernel issue. Hopefully they might do a fix for it, but at least with this boot option the problem is totally bypassed.

UPDATE: I've added the lspci -v output.

Great, that definitely is amazing that it took that to make it work and was just the msi issue.  I'll have to file a bug report at the kernel bugtracker website, so hopefully eventually won't be necessary to pick the other option.  Sounds like a good thing to have there for people to use in cases like these. 

Interested to see how it all works with different games on the CGA monitor, I'm actually looking to get a basic 19" and Jpac to have a some sort of cocktail test station to play around with the actual analog monitor like that and real Jamma connection.  Might get those 60n1 board vertical games and the 19n1 horizontal PCB too, would be interesting to have a test setup where I can run both originals and mame emulations one after another on the same monitor/setup.  Of course that is looking like a few months probably of saving/working on it gathering the stuff and figuring out about how to aquire or build the structure to hold it.  Sounds fun to actually see how this all looks on the true 19" standard CGA curved screen monitor in vertical and horizontal positions.  I think I've found one that is cheap, used with slight burnin and a Wells Gardner from around 2005, at least at the price around 150 US dollars w/shipping seems like a deal.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dmarcum99 on January 19, 2011, 10:23:09 pm
Hi Guys!

I'm playing with switchres and I like it a lot.  Sorry I've been in and out of the thread, but I'm mostly lurking though.  I saved up all my new questions for one more post and hopefully it's the last.

A page or two back, it was mentioned that we could use the genres.pl script to generate more modelines in windows and use them in soft15khz.  How would I go about doing this?  I mean, what program do I need to run the script...what syntax do I use, etc.....  I'm really slow at this stuff sometimes.

Also, it really never sunk in about setting up a custom config file for my monitor.  What name do I give the file and what do I need to include?  I have a NEC XM2950 so with it being able to do the whole range (15-50khz), I'm a little confused on what timings I should provide.  Could one of you guys help me out with that again?  I read the readme, but it was a little deeper than the kiddie pool for me.   :dunno

Lastly, with all the changes that have been made since the inception, I am a little unsure what type of settings I'll get if I don't use any special switches.  Things like....is triple buffer off by default?  If not, does the triple buffer that switchres implements not have the sound synch issue?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 19, 2011, 10:56:16 pm
Hi Guys!

I'm playing with switchres and I like it a lot.  Sorry I've been in and out of the thread, but I'm mostly lurking though.  I saved up all my new questions for one more post and hopefully it's the last.

A page or two back, it was mentioned that we could use the genres.pl script to generate more modelines in windows and use them in soft15khz.  How would I go about doing this?  I mean, what program do I need to run the script...what syntax do I use, etc.....  I'm really slow at this stuff sometimes.

Also, it really never sunk in about setting up a custom config file for my monitor.  What name do I give the file and what do I need to include?  I have a NEC XM2950 so with it being able to do the whole range (15-50khz), I'm a little confused on what timings I should provide.  Could one of you guys help me out with that again?  I read the readme, but it was a little deeper than the kiddie pool for me.   :dunno

Lastly, with all the changes that have been made since the inception, I am a little unsure what type of settings I'll get if I don't use any special switches.  Things like....is triple buffer off by default?  If not, does the triple buffer that switchres implements not have the sound synch issue?

The genres.pl program uses perl, basically you'll get the same output as me and your monitor should work good with the same settings as a d9800.  So here's the basic output you probably could use that it would output with the ATI Catalyst driver Calamity has hacked, so it can use these ~130 custom modes (this is probably better too because I use |sort -n in Linux and in Windows there isn't a sort command to order these better.  I need to improve the generation of these or have some files for each type of monitor, although this list should be fine for anybody/anymonitor really)...

genres.pl -x mame.xml -m d9800

(Note that these modelines only are using the HxW part, the refresh rate is dynamically altered by switchres and the rest of the modeline too, so they are all just set to 60HZ yet won't be that when used by switchres).

Code: [Select]
ModeLine "1024x512@60" 40.907520 1024 1048 1200 1272 512 513 516 536 -HSync -VSync
ModeLine "1024x544@60" 23.990400 1024 1072 1184 1344 544 551 558 595 -HSync -VSync interlace
ModeLine "1280x592@60" 29.706600 1280 1344 1480 1680 592 599 606 643 -HSync -VSync interlace
ModeLine "240x192@60" 4.773600 240 256 280 312 192 216 219 255 -HSync -VSync
ModeLine "240x224@60" 4.773600 240 256 280 312 224 232 235 255 -HSync -VSync
ModeLine "240x240@60" 4.758000 240 256 280 312 240 265 268 305 -HSync -VSync
ModeLine "248x224@60" 4.896000 248 264 288 320 224 232 235 255 -HSync -VSync
ModeLine "248x240@60" 4.889705 248 264 288 320 240 245 248 266 -HSync -VSync
ModeLine "256x192@60" 5.140800 256 272 296 336 192 216 219 255 -HSync -VSync
ModeLine "256x224@60" 5.131636 256 272 296 336 224 230 233 252 -HSync -VSync
ModeLine "256x240@60" 5.281920 256 272 296 336 240 243 246 262 -HSync -VSync
ModeLine "256x256@60" 5.758560 256 272 304 344 256 259 262 279 -HSync -VSync
ModeLine "264x224@60" 5.263987 264 280 304 344 224 233 236 257 -HSync -VSync
ModeLine "264x240@60" 5.533440 264 280 312 352 240 243 246 262 -HSync -VSync
ModeLine "272x224@60" 5.498181 272 288 320 360 224 230 233 252 -HSync -VSync
ModeLine "272x240@60" 5.659200 272 288 320 360 240 243 246 262 -HSync -VSync
ModeLine "280x224@60" 5.623150 280 296 328 368 224 232 235 255 -HSync -VSync
ModeLine "280x240@60" 5.784960 280 296 328 368 240 243 246 262 -HSync -VSync
ModeLine "288x224@60" 5.742545 288 304 336 376 224 230 233 252 -HSync -VSync
ModeLine "288x240@60" 5.910720 288 304 336 376 240 243 246 262 -HSync -VSync
ModeLine "296x224@60" 5.875200 296 312 344 384 224 232 235 255 -HSync -VSync
ModeLine "296x240@60" 6.046153 296 312 344 384 240 243 246 262 -HSync -VSync
ModeLine "304x224@60" 5.997600 304 320 352 392 224 232 235 255 -HSync -VSync
ModeLine "304x240@60" 6.288000 304 320 352 400 240 243 246 262 -HSync -VSync
ModeLine "304x256@60" 6.584400 304 320 352 400 256 259 262 279 -HSync -VSync
ModeLine "312x288@60" 7.937280 312 328 368 424 288 291 295 312 -HSync -VSync
ModeLine "320x192@60" 6.364800 320 336 368 416 192 216 219 255 -HSync -VSync
ModeLine "320x224@60" 6.364800 320 336 368 416 224 232 235 255 -HSync -VSync
ModeLine "320x240@60" 6.354816 320 336 368 416 240 246 249 268 -HSync -VSync
ModeLine "320x256@60" 6.963840 320 336 368 416 256 259 262 279 -HSync -VSync
ModeLine "328x224@60" 6.487200 328 344 376 424 224 232 235 255 -HSync -VSync
ModeLine "328x240@60" 6.467696 328 344 376 424 240 244 247 263 -HSync -VSync
ModeLine "328x256@60" 7.519531 328 344 384 440 256 259 262 280 -HSync -VSync
ModeLine "336x224@60" 6.589647 336 352 384 432 224 231 234 254 -HSync -VSync
ModeLine "336x240@60" 6.782362 336 352 384 432 240 243 246 262 -HSync -VSync
ModeLine "336x256@60" 7.499520 336 352 392 448 256 259 262 279 -HSync -VSync
ModeLine "344x240@60" 6.916800 344 360 392 440 240 243 246 262 -HSync -VSync
ModeLine "352x224@60" 6.854400 352 368 400 448 224 232 235 255 -HSync -VSync
ModeLine "352x240@60" 7.048949 352 368 400 448 240 243 246 262 -HSync -VSync
ModeLine "352x256@60" 7.767360 352 368 408 464 256 259 262 279 -HSync -VSync
ModeLine "360x224@60" 6.976800 360 376 408 456 224 232 235 255 -HSync -VSync
ModeLine "360x240@60" 6.965856 360 376 408 456 240 246 249 268 -HSync -VSync
ModeLine "360x256@60" 7.352544 360 376 416 464 256 259 262 278 -HSync -VSync
ModeLine "368x224@60" 7.099200 368 384 416 464 224 232 235 255 -HSync -VSync
ModeLine "368x240@60" 7.545600 368 384 424 480 240 243 246 262 -HSync -VSync
ModeLine "368x256@60" 8.035200 368 384 424 480 256 259 262 279 -HSync -VSync
ModeLine "376x224@60" 7.329545 376 392 432 480 224 233 236 258 -HSync -VSync
ModeLine "376x240@60" 7.671360 376 392 432 488 240 243 246 262 -HSync -VSync
ModeLine "376x256@60" 8.218625 376 400 440 496 256 259 262 279 -HSync -VSync
ModeLine "384x192@60" 7.588800 384 400 440 496 192 216 219 255 -HSync -VSync
ModeLine "384x224@60" 7.588800 384 400 440 496 224 232 235 255 -HSync -VSync
ModeLine "384x240@60" 7.797120 384 400 440 496 240 243 246 262 -HSync -VSync
ModeLine "384x256@60" 7.583840 384 400 440 496 256 259 262 278 -HSync -VSync
ModeLine "384x288@60" 9.734400 384 408 456 520 288 291 295 312 -HSync -VSync
ModeLine "384x384@60" 13.527360 384 424 464 528 384 396 400 427 -HSync -VSync
ModeLine "392x224@60" 7.711200 392 408 448 504 224 232 235 255 -HSync -VSync
ModeLine "400x224@60" 7.833600 400 416 456 512 224 232 235 255 -HSync -VSync
ModeLine "400x240@60" 8.048640 400 416 456 512 240 243 246 262 -HSync -VSync
ModeLine "400x256@60" 8.191560 400 424 464 520 256 259 262 278 -HSync -VSync
ModeLine "400x288@60" 7.936000 400 416 456 512 288 291 294 310 -HSync -VSync
ModeLine "400x384@60" 13.555347 400 440 480 544 384 395 399 425 -HSync -VSync
ModeLine "408x256@60" 7.952584 408 424 464 520 256 260 263 279 -HSync -VSync
ModeLine "416x224@60" 8.200800 416 440 480 536 224 232 235 255 -HSync -VSync
ModeLine "416x256@60" 9.240480 416 440 488 552 256 259 262 279 -HSync -VSync
ModeLine "424x256@60" 9.374400 424 448 496 560 256 259 262 279 -HSync -VSync
ModeLine "432x224@60" 8.435112 432 456 496 552 224 234 237 259 -HSync -VSync
ModeLine "432x256@60" 9.508320 432 456 504 568 256 259 262 279 -HSync -VSync
ModeLine "432x384@60" 11.732000 432 464 504 560 384 393 396 419 -HSync -VSync
ModeLine "440x256@60" 9.127296 440 464 512 576 256 259 262 278 -HSync -VSync
ModeLine "448x224@60" 8.812800 448 472 512 576 224 232 235 255 -HSync -VSync
ModeLine "448x240@60" 9.180480 448 472 520 584 240 243 246 262 -HSync -VSync
ModeLine "448x288@60" 11.381760 448 472 528 608 288 291 295 312 -HSync -VSync
ModeLine "448x512@60" 18.009600 448 456 528 560 512 513 516 536 -HSync -VSync
ModeLine "464x224@60" 9.180000 464 488 536 600 224 232 235 255 -HSync -VSync
ModeLine "464x256@60" 10.177920 464 488 536 608 256 259 262 279 -HSync -VSync
ModeLine "480x192@60" 9.424800 480 504 552 616 192 216 219 255 -HSync -VSync
ModeLine "480x224@60" 9.424800 480 504 552 616 224 232 235 255 -HSync -VSync
ModeLine "480x240@60" 9.538267 480 504 552 616 240 243 246 262 -HSync -VSync
ModeLine "480x464@60" 18.044160 480 488 560 592 464 474 476 508 -HSync -VSync
ModeLine "480x480@60" 19.152000 480 496 568 608 480 490 492 525 -HSync -VSync
ModeLine "488x384@60" 16.170400 488 536 584 656 384 395 399 425 -HSync -VSync
ModeLine "496x224@60" 9.669600 496 520 568 632 224 232 235 255 -HSync -VSync
ModeLine "496x240@60" 10.060800 496 520 568 640 240 243 246 262 -HSync -VSync
ModeLine "496x384@60" 16.233317 496 544 592 664 384 395 399 425 -HSync -VSync
ModeLine "496x480@60" 19.656000 496 512 584 624 480 490 492 525 -HSync -VSync
ModeLine "504x384@60" 13.575600 504 544 584 648 384 393 396 419 -HSync -VSync
ModeLine "512x192@60" 10.036800 512 536 584 656 192 216 219 255 -HSync -VSync
ModeLine "512x224@60" 10.036800 512 536 584 656 224 232 235 255 -HSync -VSync
ModeLine "512x240@60" 10.312320 512 536 584 656 240 243 246 262 -HSync -VSync
ModeLine "512x256@60" 11.249280 512 536 592 672 256 259 262 279 -HSync -VSync
ModeLine "512x288@60" 13.096699 512 544 608 696 288 291 295 312 -HSync -VSync
ModeLine "512x384@60" 18.036480 512 568 624 704 384 396 400 427 -HSync -VSync
ModeLine "512x400@60" 18.754560 512 568 624 704 400 412 416 444 -HSync -VSync
ModeLine "512x432@60" 21.196800 512 576 640 736 432 445 450 480 -HSync -VSync
ModeLine "512x448@60" 18.345600 512 520 592 624 448 457 459 490 -HSync -VSync
ModeLine "512x480@60" 20.412000 512 528 608 648 480 490 492 525 -HSync -VSync
ModeLine "512x512@60" 20.839680 512 528 608 648 512 513 516 536 -HSync -VSync
ModeLine "520x384@60" 13.935569 520 560 600 664 384 393 396 419 -HSync -VSync
ModeLine "520x408@60" 16.961013 520 568 616 688 408 419 423 449 -HSync -VSync
ModeLine "520x480@60" 20.664000 520 536 616 656 480 490 492 525 -HSync -VSync
ModeLine "544x224@60" 10.526400 544 568 616 688 224 232 235 255 -HSync -VSync
ModeLine "544x256@60" 11.769785 544 568 624 704 256 259 262 279 -HSync -VSync
ModeLine "544x480@60" 21.420000 544 560 640 680 480 490 492 525 -HSync -VSync
ModeLine "576x224@60" 11.238636 576 600 656 736 224 233 236 258 -HSync -VSync
ModeLine "576x400@60" 21.313363 576 640 704 800 400 412 416 444 -HSync -VSync
ModeLine "576x432@60" 23.500800 576 640 712 816 432 445 450 480 -HSync -VSync
ModeLine "624x384@60" 16.618947 624 672 720 792 384 393 396 419 -HSync -VSync
ModeLine "640x224@60" 12.607200 640 672 736 824 224 232 235 255 -HSync -VSync
ModeLine "640x240@60" 12.953280 640 672 736 824 240 243 246 262 -HSync -VSync
ModeLine "640x256@60" 13.927680 640 672 736 832 256 259 262 279 -HSync -VSync
ModeLine "640x384@60" 22.135680 640 704 768 864 384 396 400 427 -HSync -VSync
ModeLine "640x480@60" 25.200000 640 656 752 800 480 490 492 525 -HSync -VSync
ModeLine "648x240@60" 13.079040 648 680 744 832 240 243 246 262 -HSync -VSync
ModeLine "648x448@60" 23.284800 648 664 752 792 448 457 459 490 -HSync -VSync
ModeLine "672x240@60" 13.438993 672 704 768 856 240 243 246 262 -HSync -VSync
ModeLine "680x224@60" 13.218539 680 712 776 864 224 232 235 255 -HSync -VSync
ModeLine "680x288@60" 13.392000 680 712 776 864 288 291 294 310 -HSync -VSync
ModeLine "680x512@60" 27.271680 680 696 800 848 512 513 516 536 -HSync -VSync
ModeLine "704x240@60" 14.097899 704 736 800 896 240 243 246 262 -HSync -VSync
ModeLine "704x480@60" 27.440554 704 720 824 872 480 490 492 525 -HSync -VSync
ModeLine "712x288@60" 14.012000 712 744 808 904 288 291 294 310 -HSync -VSync
ModeLine "720x480@60" 27.972000 720 736 840 888 480 490 492 525 -HSync -VSync
ModeLine "736x264@60" 16.727040 736 776 856 968 264 267 270 288 -HSync -VSync
ModeLine "768x224@60" 14.906181 768 800 872 976 224 230 233 252 -HSync -VSync
ModeLine "800x600@60" 38.885760 800 832 952 1032 600 601 605 628 -HSync -VSync


You really should be able to use the --monitor d9800 option for your monitor, basically that should create the most optimal modelines that in theory will work with it the best (and here I've found does just about perfect for every single game).  I think that any kind of custom settings for the monitor range would just include the 40-50KHz range and that really isn't necessary for any game Mame emulates.

Switchres really should detect everything you need, if your using cabmame or my builds of mame with the cabmame patches the most you'll need is to add the soundsync=1 and ff=1 to the switchres.conf file under c:\etc\switchres.conf.  Those are the only ones that aren't autodetected at the command line unless the name of the executable has 'cabmame' in it, then they are enabled.  So it mostly autodetects what to do now for the mame your running.  By default it's using triple buffer, but you probably don't need it and with my builds can use these settings to use vsync instead (Calamity may have better details since he has tested this all under Windows actually)...

http://sourceforge.net/projects/groovyarcade/files/Mame_Windows_Builds/ (http://sourceforge.net/projects/groovyarcade/files/Mame_Windows_Builds/)

# Put into C:\etc\switchres.conf
mon=d9800
soft15khz=1
soundsync=1
ff=1
triplebuffer=0
threads=1

Without my build, you won't want to mess with threads (and similarly remove the ff/soundsync options if it's not a cabmame based version of mame), basically the above enables the soundsync/frogger hacks disables triple buffer and uses waitvsync instead, and enables threads with waitvsync (which only works with the builds I have, even with cabmame normally that won't work since we don't use throttle and there's a patch in the build I have that fixes that problem).

You also may want to play around with the above triplebuffer option too and see how it acts either way if it doesn't work great with the above settings, would be good to have more feedback about how it works in different setups.

Also here's a  somewhat ok example of the config file and monitor settings, although probably not necessary...
http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob;f=src/SwitchResC/extra/switchres.conf;hb=HEAD (http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob;f=src/SwitchResC/extra/switchres.conf;hb=HEAD)

Here's where Perl can be gotten for Windows, although probably would get the same output as above unless you used custom monitor settings...
http://www.activestate.com/activeperl/downloads (http://www.activestate.com/activeperl/downloads)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 20, 2011, 08:39:19 am
May be a little off topic ...

 But .. could you propose a cabmame 0.141 build for windows in your repository (i've only found gentoo ebuilds, and that's great ^^) ?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on January 20, 2011, 09:28:39 am
A 64bit build would be nice too. I don't recall seeing one. Please correct me if I am wrong.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: SailorSat on January 20, 2011, 10:16:56 am
I'll upload the new builds later this day.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 20, 2011, 11:06:08 am
I'll upload the new builds later this day.

 Many thanks SailorSat  ;)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 20, 2011, 11:57:16 am
I'll upload the new builds later this day.
Great, also you may want to look at adding this patch, it's submitted to mame but not sure if it'll get in and it's not in 0141.  It allows switchres to do a little more magic when able to utilize the waitvsync option and not need triple buffer, if the monitor is able to run at the original refresh rate.

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob;f=overlays/games-emulation/mame/files/vsync_mt_fix.diff;h=30898fa427573500b2679a91ebaa5fb23648042b;hb=HEAD (http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob;f=overlays/games-emulation/mame/files/vsync_mt_fix.diff;h=30898fa427573500b2679a91ebaa5fb23648042b;hb=HEAD)

Basically this is what allows the waitvsync and multithreading to work with nothrottle, fixes what seems to be some sort of bug in the way  mame does the multithreading and locking while waiting for the vblank.  Calamity wrote the Windows part of the patch, which of course is all the cabmame build needs of yours, also great to get 64 bit versions up since I only have 0141 in 32 bit mame/mess versions. 

The patch of mine that made the changes for 0141 to your cabmame patches are here (and added Linux support) since there were some painful parts changed by mame over 0140-0140u2 turning the machine into a class structure or something like that...

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob;f=overlays/games-emulation/mame/files/groovyarcade-0141.patch;h=7c7e64a2c6f2e74d57355adb2c6f9a1e99373bce;hb=HEAD (http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob;f=overlays/games-emulation/mame/files/groovyarcade-0141.patch;h=7c7e64a2c6f2e74d57355adb2c6f9a1e99373bce;hb=HEAD)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: SailorSat on January 20, 2011, 12:21:40 pm
I'll take a look into it :)
Turned out my "inputlag fix" didn't help at all xD
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 20, 2011, 12:41:59 pm
With your combined works, we're near to the "Perfect Mame"(tm) setup  :o

 I'm really impressed  :applaud:
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 20, 2011, 01:37:53 pm
It would be nice to gather a brief txt with the basic config for using switchres with most popular frontends. I only use AdvanceMenu, but if anyone had success using Mala, HyperSpin, etc. + switchres please let us know your config.

On the default Mame config stuff, if you use the 0.141 binary with cabmame patches on built by bitbytebit: (http://sourceforge.net/projects/groovyarcade/files/Mame_Windows_Builds/ (http://sourceforge.net/projects/groovyarcade/files/Mame_Windows_Builds/)) it's already using the best config by default. So for what I've seen looking through the code and testing, triplebuffer (wait + flip) is the right option we should use in Windows for vsyncing, being waitvsync and syncrefresh (wait only) somehow deprecated (even if one can patch the code to restore their original function it seems triplebuffer is the way intended by mame devs to do this stuff, and I can't see any lag produced by it compared to the other methods). Of course in this context we're always using Mame versions with the soundsync hack, for cases where we can't match the original game refresh (i.e. Pacman, cga monitor, set horizontally).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on January 20, 2011, 02:41:17 pm
I have been attempting to get switchres to work within Hyperspin for a while now and have yet to have success. I need to take it to the official hyperspin forums, but have not do so yet.

At the moment, on my machine, when I set it to launch switchres as it's default mame executable with the argument of --soft15khz, it successfully launches switchres, and switchres successfully launches mame, however switchres has some failure of reading the settings from for the rom, thus it sets it runs it at whatever the desktop resolution already was. It also usually does not throttle the game either.

I am assuming this is some kind of path issue; Hyperspin launches the game either as a complete path (eg: "c:\mame\switchres.exe" "romname") or as a relative path (eg: "..\mame\switchres.exe" "romname" or ".\mame\switchres.exe" "romname"). On a whim I set my mame, and rom directories up in the %PATH% variable, but I either did something wrong, or that didn't work anyway.

Getting this working would be wonderful.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 20, 2011, 02:44:47 pm
I have been attempting to get switchres to work within Hyperspin for a while now and have yet to have success. I need to take it to the official hyperspin forums, but have not do so yet.

At the moment, on my machine, when I set it to launch switchres as it's default mame executable with the argument of --soft15khz, it successfully launches switchres, and switchres successfully launches mame, however switchres has some failure of reading the settings from for the rom, thus it sets it runs it at whatever the desktop resolution already was. It also usually does not throttle the game either.

I am assuming this is some kind of path issue; Hyperspin launches the game either as a complete path (eg: "c:\mame\switchres.exe" "romname") or as a relative path (eg: "..\mame\switchres.exe" "romname" or ".\mame\switchres.exe" "romname"). On a whim I set my mame, and rom directories up in the %PATH% variable, but I either did something wrong, or that didn't work anyway.

Getting this working would be wonderful.

It does sound like switchres can't find the mame executable, try putting the mame.exe (maybe rename it to that, or use --emulator <name_of_mame_executable>) in the same directory switchres is in, or in a very common windows path possibly.  I wonder if possibly Hyperspin is launching mame in an environment that doesn't allow it to find the mame executable, or another possibility is it's trying to add extra arguments but doesn't seem like that's happening.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on January 20, 2011, 02:51:33 pm
I've named it to mame.exe and it's in the same folder.

What I'm confused about is how switchres is able to launch the mame executable but unable to use it to find the display information. Is mame called as a function of the current working directory? Maybe an absolute path to the mame executable and rom directory could be set up as a config variable?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 20, 2011, 02:58:27 pm
I've named it to mame.exe and it's in the same folder.

What I'm confused about is how switchres is able to launch the mame executable but unable to use it to find the display information. Is mame called as a function of the current working directory? Maybe an absolute path to the mame executable and rom directory could be set up as a config variable?
Is it the newest switchres?  One thing I did have to do awhile back was change some things on how it gets the XML information when launching the mame executable.  Basically it uses mame to check for the games information first, so that execution is failing or it can't get the file output it uses.  In Windows I'm having to write the xml info out to a file and read it in from that, doesn't allow me for some reason to easily redirect the mame output to read it into switchres in a stream like I can in Linux (even in Cygwin, it's an issue with posix compliance I guess).  So maybe that file output is failing, so it can't get the information most likely from mame on what resolution the game should be.  I am guessing the way that Hyperspin is launching switchres is either having the current working directory in a non-writable place or some other form of launching it that doesn't allow the method of writing out a file and reading it back in to work.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 20, 2011, 03:30:57 pm
I've named it to mame.exe and it's in the same folder.

What I'm confused about is how switchres is able to launch the mame executable but unable to use it to find the display information. Is mame called as a function of the current working directory? Maybe an absolute path to the mame executable and rom directory could be set up as a config variable?
Not sure if you've seen this, seems like maybe this could help or at least give insight into what is going on...

http://www.hyperspin-fe.com/forum/downloads.php?do=file&id=3603 (http://www.hyperspin-fe.com/forum/downloads.php?do=file&id=3603)

Quote
HyperLaunch is a compiled script that handles the launching of emulators via HyperSpin. The Official compiles of HyperLaunch include the compiled (HyperLaunch.exe) and the raw HyperLaunch.ahk. Just place the HyperLaunch.exe into your HyperSpin directory and overwrite your old one. The .ahk file is included for you to edit and compile your own version using AutoHotKey.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on January 20, 2011, 03:45:09 pm
I have not used the most recent switchres. I will do that as soon as I can and report back. If it's compiling it's own .xml now then I bet that will help resolve the issue. Any chance we could get a -v -v -v -v etc log dump option?

As for Hyperlaunch, I am not using it. It's current behavior is to force-quit programs to return to the FE, doing so prevents mame from outputting nvram updates, hiscores, or configuration changes.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 20, 2011, 03:54:23 pm
I was having a similar problem with AdvanceMenu, the params passed by Switchres weren't working because rom names were passed as "romname.zip" instead of "romname". However the right game was actually loaded, but Mame was using its default settings. It got fixed by using %s param instead of %f, like this:

emulator "mame_switchres" generic "c:\Emuladores\Mame\switchres.exe" "%s  --soft15khz --monitor h9110"

Is there a similar param available in HyperSpin? If it's missing and that was the problem, maybe Switchres could be changed to always rip the romname string in order to get the plain "romname" when launching Mame.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 20, 2011, 03:55:12 pm
I have not used the most recent switchres. I will do that as soon as I can and report back. If it's compiling it's own .xml now then I bet that will help resolve the issue. Any chance we could get a -v -v -v -v etc log dump option?

As for Hyperlaunch, I am not using it. It's current behavior is to force-quit programs to return to the FE, doing so prevents mame from outputting nvram updates, hiscores, or configuration changes.

Yeah hopefully that's the issue, will see if my work to fix issues reading that xml output in windows worked or not.  The dynamic reading from mame is nice because it's fast from not having to open a large 40+ Meg XML file and search through it, process it with the XML reader, could see how that would be a bit slower.  Yeah I should be able to output to a file all the details, will need to look at that and having my info messages write to a file instead of stderr.  

That does sound bad with Hyperlaunch, if it forced switchres to quit would probably be a bit nasty (I think), wonder why it does that for.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 20, 2011, 03:56:30 pm
I was having a similar problem with AdvanceMenu, the params passed by Switchres weren't working because rom names were passed as "romname.zip" instead of "romname". It got fixed by using %s param instead of %f, like this:

emulator "mame_switchres" generic "c:\Emuladores\Mame\switchres.exe" "%s  --soft15khz --monitor h9110"

Is there a similar param available in HyperSpin? If it's missing and that was the problem, maybe Switchres could be changed to always rip the romname string in order to get the plain "romname" when launching Mame.

Nope, I already do that in switchres :), it strips off any extension to the rom name given, changes all case to lower case, so shouldn't be an issue.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 20, 2011, 04:02:14 pm
for Malafe you need to edit mala.ini and replace Exe=Mame.exe by Exe=SwitchRes.exe ....

 if you try to do it by the gui, gui will crash  :lol
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 20, 2011, 04:04:50 pm
Nope, I already do that in switchres :), it strips off any extension to the rom name given, changes all case to lower case, so shouldn't be an issue.

Ah it was already there! nice to know  ;D
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 20, 2011, 04:16:04 pm
I should have a build for Windows/Linux up in a bit that will write out to a file all the information output if the config file has an file specified to write logs to.  So hopefully that can help get to the bottom of what's going on when launching from Hyperspin. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on January 20, 2011, 04:27:47 pm
And the config file needs to be in c:\etc\?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 20, 2011, 05:53:53 pm
I should have a build for Windows/Linux up in a bit that will write out to a file all the information output if the config file has an file specified to write logs to.  So hopefully that can help get to the bottom of what's going on when launching from Hyperspin. 

I have a new build up, SwitchResWin-1.286-88e4632.7z, which now can log to a file.  You can put logfile=c:\logfile.txt or something in the config now, or --logfile <filename> on the command line.  Also now you can specify verbosity level at the config file like verbose=3 or something, and if you add more -v options at the command line it'll add onto that base level from the config file.

Yeah, the config file either needs to be in c:\etc\ or in the windows directory you launch switchres from (which I'm guessing might not work correctly if launched from an external app and you won't know where that is, but not sure).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 20, 2011, 06:02:55 pm
I have not used the most recent switchres. I will do that as soon as I can and report back. If it's compiling it's own .xml now then I bet that will help resolve the issue. Any chance we could get a -v -v -v -v etc log dump option?

As for Hyperlaunch, I am not using it. It's current behavior is to force-quit programs to return to the FE, doing so prevents mame from outputting nvram updates, hiscores, or configuration changes.

I am looking through Hyperlaunch, first thing I noticed was this...
Code: [Select]
/*
 Most emu's can be closed with CloseProcess when using a 2 key combo, if not set a custom
 close.
*/

CloseProcess:

WinShow, BlackScreen
Process, Exist, %Executable%

;for emus that won't close normally
if AlternateClose = true
   ControlSend, , {Esc}, %Errorlevel%
;   Process, Close, %Executable%

DetectHiddenWindows, on

WinHide, ahk_pid %Errorlevel%
WinKill, ahk_pid %Errorlevel%
Sleep 6000
Process, WaitClose, %Executable%

Loop, Addons\*.*,2 ;close running addons
   {
      addonpath = %A_LoopFileFullPath%
      Loop, %addonpath%\*.exe
         {
               Process, Exist, %A_LoopFileName%
               Winclose, ahk_pid %Errorlevel%
         }
   }
Goto ExitScript


So I suspect this shows that the behavior of forcing the emulator to close is possibly a bug in Hyperlaunch and fixable or it is on purpose and we could change it in this script at that point above.  So will be interesting to see logs of launching switchres with the new version I just posted, and looks like possibly a customized Hyperlaunch script might not kill off mame/switchres and let them exit cleanly.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on January 21, 2011, 05:40:59 am
Ok, testing the new swtichres at the moment (and posting from my cab)

This message appears before switchres launches mame:

      1 [main] switchres 2192 dtable::stdio_init: couldn't make stderr distinct
from stdout, Win32 error 6

I'm about to set up a config file and try and dump a verbosity level 3 log for this happening.

Edit: Now this doesn't make a damn bit of sense.. When I added --logfile <path to my log> to my hyperspin launch, it started finding the roms and generating correct mode lines. Wtf. yay?
Edit2: Is the source download up to date for your mame build? I'd like to recompile for 64bit. Several newer games won't run fullspeed at the moment that did (or at least came close) on my previous mame exe.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 21, 2011, 06:34:07 am
Ok, testing the new swtichres at the moment (and posting from my cab)

This message appears before switchres launches mame:

      1 [main] switchres 2192 dtable::stdio_init: couldn't make stderr distinct
from stdout, Win32 error 6

I'm about to set up a config file and try and dump a verbosity level 3 log for this happening.

Edit: Now this doesn't make a damn bit of sense.. When I added --logfile <path to my log> to my hyperspin launch, it started finding the roms and generating correct mode lines. Wtf. yay?
Edit2: Is the source download up to date for your mame build? I'd like to recompile for 64bit. Several newer games won't run fullspeed at the moment that did (or at least came close) on my previous mame exe.

That's very interesting, I'm guessing somehow stderr was the issue in however Hyperspin launches it, must be doing some input/output redirection that messes that up.  So seems the logfile fixes that indirectly by not using stderr, weird but I guess that works for now.

Yeah the patches are all here that I used on the 0141 sources...

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=tree;f=overlays/games-emulation/mame/files;hb=HEAD (http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=tree;f=overlays/games-emulation/mame/files;hb=HEAD)

Basically add the hiscore patch first, then the groovyarcade one, then the hilofix (not fully necessary, basically make the hiscore.dat file always checked for in the hi\ directory where the score files are kept, so it's always in the same place), then the vsync_mt_fix last (also there's the enable_nag_default.diff which makes it so you have to explicitly disable the nag/intro screens yourself in mame.  This makes it so the build doesn't disable those screens by default, so as not to go against the mame guidelines of not making builds that do that so as to avoid false bug reports for games they know are already not working.  If your distributing the build, this probably should be included, else people get unhappy as I found out on the Mame World forums :/ ).  The sdlfix patch is just for compiling SDL/Linux so not necessary, basically grab all the .patch and .diff files in that directory and apply in the order I just went through.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 22, 2011, 06:53:16 am
Humm ....

 problem  ;D

 When i launch mame.exe rfjet all is ok (except resolution ^^)
 but when i use latest switchres (i didn't kept the older version to try :/) with switchres.exe rfjet --soft15khz --mo 2 (even without --mo 2) throttle is activated ....

 Do you have any idea ? tried with official mame builds / sailorsat build (thanks again) and personnal build, same result .. seems that switchres add an option to mame  ..


EDIT = i'm sure that it is throttle because if i press F10 speed go to normal ..
 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 22, 2011, 07:25:37 am
dapsaille, make sure the throttle option is off in mame.ini, seems that ini options have priority over the others.

Edit: that game seems to use a 54 Hz refresh. So, if the proper video mode (proper vfreq) is actually used, you shouldn't see hardly any difference either using throttle or not. So try to find what video mode is actually selected (use -v).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 22, 2011, 07:45:34 am
dapsaille, make sure the throttle option is off in mame.ini, seems that ini options have priority over the others.

Edit: that game seems to use a 54 Hz refresh. So, if the proper video mode (proper vfreq) is actually used, you shouldn't see hardly any difference either using throttle or not. So try to find what video mode is actually selected (use -v).


 I've already played with throttle 0 or 1, no modifications.

Code: [Select]
Got Soft15khz registry modeline 321x240@60 - DALDTMCRTBCD321x240x0x60:
             "321x240@60" 6.640000 320 336 368 424 240 242 245 261 -HSync -VSync

# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vpad +23 lines | )
Setting registery video mode DALDTMCRTBCD321x240x0x60 with:
(62986/63001/62986) Modeline 6.470000 320 336 368 424 240 252 255 283
Opening  modes file for mode 320x240@54
Target refresh = 54.000000
Average speed: 276.27% (35 seconds)
Setting registery video mode DALDTMCRTBCD321x240x0x60 with:
(63001/63001/63001) Modeline 6.640000 320 336 368 424 240 242 245 261

D:\Mame>

 strange ^^

EDIT = it seems that i didn't used the latest version .. i'm trying it in 2 minutes.

EDIT2 = same problem .... it must be related to my mame.ini
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 22, 2011, 07:56:46 am
Just tried with a new mame.ini (mame -cc only modified rom path) and same problem .....
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 22, 2011, 07:59:43 am
Quote
Average speed: 276.27% (35 seconds)

Seems no kind of throttle or triplebuffer is working. Try disabling multithreading in Mame.ini, it could be the patch we made is not working... strange.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 22, 2011, 08:01:07 am
Quote
Average speed: 276.27% (35 seconds)

Seems no kind of throttle or triplebuffer is working. Try disabling multithreading in Mame.ini, it could be the patch we made is not working... strange.


already disabled .....

http://pastebin.com/XaiBkHKi (http://pastebin.com/XaiBkHKi)

FI I'm using switchres without /etc/config file
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 22, 2011, 08:29:13 am
Problem solved by using

switchres.exe rfjet.zip --soft15khz --mo 2 -vv --throttle --soundsync


 But now with frameskip 0 mame sometimes rune at 99 then 100 then 101 then 100% ...

 Musics are really speed in rfjet so i can hear the differences between 99 and 100 ... sound is distorded ...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 22, 2011, 08:45:50 am
Good, anyway enabling throttle should not be the way to go, as you are not relying on the video card sync pulses any more but on the inner clock, that's why your fps fluctuates. When using switchres, try passing "-v -v -v" instead of "-v" so you'll get the actual mame command line being used prompted.

I'm testing the same game here, with Mame 0.141 from bitbytebit, and both new Switchres and an older one, and it's working ok here  ???
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 22, 2011, 10:05:02 am
Mame version = http://sourceforge.net/projects/groovyarcade/files/Mame_Windows_Builds/ (http://sourceforge.net/projects/groovyarcade/files/Mame_Windows_Builds/) 0.141 windows build

Mame.ini
Code: [Select]
<UNADORNED0>              

#
# CORE CONFIGURATION OPTIONS
#
readconfig                1
writeconfig               0

#
# CORE SEARCH PATH OPTIONS
#
rompath                   d:\roms
hashpath                  hash
samplepath                samples
artpath                   artwork
ctrlrpath                 ctrlr
inipath                   .;ini
fontpath                  .
cheatpath                 cheat
crosshairpath             crosshair

#
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory             cfg
nvram_directory           nvram
memcard_directory         memcard
input_directory           inp
state_directory           sta
snapshot_directory        snap
diff_directory            diff
comment_directory         comments
hiscore_directory         hi

#
# CORE STATE/PLAYBACK OPTIONS
#
state                    
autosave                  0
playback                  
record                    
mngwrite                  
aviwrite                  
wavwrite                  
snapname                  %g/%i
snapsize                  auto
snapview                  internal
burnin                    0

#
# CORE PERFORMANCE OPTIONS
#
autoframeskip             0
frameskip                 0
seconds_to_run            0
throttle                  0
sleep                     1
speed                     1.0
refreshspeed              0

#
# CORE ROTATION OPTIONS
#
rotate                    1
ror                       0
rol                       0
autoror                   0
autorol                   0
flipx                     0
flipy                     0

#
# CORE ARTWORK OPTIONS
#
artwork_crop              1
use_backdrops             0
use_overlays              1
use_bezels                0

#
# CORE SCREEN OPTIONS
#
brightness                1.0
contrast                  1.0
gamma                     1.0
pause_brightness          0.65
cleanstretch              1
changeres                 0
effect                    none
redraw                    0
froggerhack               1

#
# CORE VECTOR OPTIONS
#
antialias                 1
beam                      1.0
flicker                   0

#
# CORE SOUND OPTIONS
#
sound                     1
samplerate                48000
samples                   1
volume                    0

#
# CORE INPUT OPTIONS
#
coin_lockout              1
ctrlr                    
mouse                     0
joystick                  1
lightgun                  0
multikeyboard             0
multimouse                0
steadykey                 0
offscreen_reload          0
joystick_map              auto
joystick_deadzone         0.1
joystick_saturation       0.95
natural                   0
uimodekey                 auto

#
# CORE INPUT AUTOMATIC ENABLE OPTIONS
#
paddle_device             keyboard
adstick_device            keyboard
pedal_device              keyboard
dial_device               keyboard
trackball_device          keyboard
lightgun_device           keyboard
positional_device         keyboard
mouse_device              mouse

#
# CORE DEBUGGING OPTIONS
#
log                       0
verbose                   0
update_in_pause           0
debug                     0
debugscript              
debug_internal            0

#
# CORE MISC OPTIONS
#
bios                      
cheat                     0
skip_gameinfo             1
uifont                    default

#
# CORE MKChamp OPTIONS
#
disable_hiscore_patch     0
disable_nagscreen_patch   0
disable_loading_patch     0

#
# WINDOWS DEBUGGING OPTIONS
#
oslog                     0
watchdog                  0
debugger_font             "Lucida Console"
debugger_font_size        9

#
# WINDOWS PERFORMANCE OPTIONS
#
priority                  0
multithreading            0
numprocessors             auto
profile                   0
bench                     0

#
# WINDOWS VIDEO OPTIONS
#
video                     ddraw
numscreens                1
window                    0
maximize                  0
keepaspect                1
prescale                  0
waitvsync                 1
syncrefresh               0

#
# DIRECTDRAW-SPECIFIC OPTIONS
#
hwstretch                 0

#
# DIRECT3D-SPECIFIC OPTIONS
#
d3dversion                9
filter                    0

#
# PER-WINDOW VIDEO OPTIONS
#
screen                    auto
aspect                    auto
resolution                auto
view                      auto
screen0                   auto
aspect0                   auto
resolution0               auto
view0                     auto
screen1                   auto
aspect1                   auto
resolution1               auto
view1                     auto
screen2                   auto
aspect2                   auto
resolution2               auto
view2                     auto
screen3                   auto
aspect3                   auto
resolution3               auto
view3                     auto

#
# FULL SCREEN OPTIONS
#
triplebuffer              1
switchres                 1
full_screen_brightness    1.0
full_screen_contrast      1.0
full_screen_gamma         1.0

#
# WINDOWS SOUND OPTIONS
#
audio_latency             2

#
# INPUT DEVICE OPTIONS
#
dual_lightgun             0

Switchres Version =
SwitchResWin-1.286-88e4632

Video Cards/ Drivers =
Ati radeon xpress1200 / Your drivers ^^

Output of switchres =
Code: [Select]
Got Soft15khz registry modeline 321x240@60 - DALDTMCRTBCD321x240x0x60:
             "321x240@60" 6.640000 320 336 368 424 240 242 245 261 -HSync -VSync

Setup monitor limits min=184x108 max=0x608
Starting with Horizontal freq of 13.922 and Vertical refresh of 54.00
Increased horizontal frequency from 13.922 to 15.250
Increasing 1 line from horizontal freq 15228.000 to 15282.000
Using 23 lines padding
# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vpad +23 lines | )
Setting registery video mode DALDTMCRTBCD321x240x0x60 with:
(62986/63001/62986) Modeline 6.470000 320 336 368 424 240 252 255 283
Opening  modes file for mode 320x240@54
Running Emulator: mame rfjet -resolution 321x240@60 -resolution0 321x240@60 -vid
eo ddraw -norotate -cleanstretch -nothrottle -nomt -syncrefresh -triplebuffer
Target refresh = 54.000000
Average speed: 333.93% (9 seconds)
Setting registery video mode DALDTMCRTBCD321x240x0x60 with:
(63001/63001/63001) Modeline 6.640000 320 336 368 424 240 242 245 261

D:\Mame>switchres rfjet --soft15khz --mo 2 -v -v -v -v -verbose

 It is really strange because i've already ran successfully this game with switchres ... but result was nos perfect (soundsync lag input .....)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 22, 2011, 11:20:50 am
Yes, it's strange as it seems vsync is not working, that can be the reason why speed goes so fast. That can happen when ddraw acceleration is failing. Run dxdiag and in screen tab, check if all DirectX features are enabled. If they're disabled, you'll probably need to reinstall the drivers, running catuninstaller before installing.

I'm thinking of another possible reason, although it's not probably that. You're using 321x labelled resolutions, that's not necessary anymore with my drivers. Maybe Soft-15Khz is doing that?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 22, 2011, 12:10:00 pm
Desinstalled catalyst, rebooter, reinstalled ,installed directx .. same problem  :banghead: :banghead:

 I'm downloading the gentoo livecd and will give a shot to switchres under gentoo ....

EDIT = could you please explain howto use your modified driver for a 15khz output ?

 Do i need to use soft15khz ? it is not really clear for me so the problem may come from that. ?!
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 22, 2011, 01:37:34 pm
But did you check dxdiag for ddraw acceleration? I'm thinking it could be the key of the problem. Is vsync working at all with other games?
Unfortunately, ATI drivers are sometimes buggy when installing/reinstalling, even if everything looks fine you have to check that dxdiag app to be sure it's working ok. If ddraw acceleration is disabled, let me know and I'll try to help with that.

My hacked drivers need no extra software for 15Khz output. You only need to install them. But the built in mode table is not the best one in order to use Switchres with, as it is intended to be used as a static mode list with inis for each rom. That's why it's recommended to use a special mode table when using dynamic modelines (Switchres), like the one I posted. So Soft-15khz is only used here to store that special mode table into the registry. My drivers come with the VMMaker app that was intended for static mode lists + inis (does a great job imho) but I should update it to the new paradigm so it will create a mode list specially designed for Switchres, and I'm thinking of uploading a new version of the drivers that already has the right mode table so you don't need to do anything apart from installing the drivers and using Switchres.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 22, 2011, 05:24:44 pm
Well .. in dxdiag's Display panel  i've got a directdraw acceleration = unavalaible .... but i get direct3d avalaible and activated .. strange ...

 Seems that ddraw is sort of broken on my rig...

 Just for being clear= your driver specify resolution that ARE 15khz OOB, so soft15khz is only used to modify resolutions provided by your driver for made them more accurate regarding to arcade games resolution, right ?

 If this is right, i don't need soft15khz for getting a basic 15khz win xp system, i only need to install your drivers and switchres will try to use the best resolution (based on modelines provided by your driver) ?

 I'm really sorry to ask for some informations who may have already been explained but the mechanisms of switchres and your drivers is new for me and my english knowledge is not good as i wish.

 I only undrestand mechanisms of official catalyst drivers + soft15khz who add 15khz modelines (or/and 24/31khz) (again thanks sailorsat ^^)

 Regards.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 22, 2011, 06:28:29 pm
Quote
Well .. in dxdiag's Display panel  i've got a directdraw acceleration = unavalaible .... but i get direct3d avalaible and activated .. strange ...

Don't search any more, that's the problem. The drivers are not working properly. Unfortunately this happens from time to time, have no clue of the reason but I've seen the only way to repair it is to completely clean the system from any previous Catalyst software before installing the new Catalyst. You'd better do it starting in safe mode. Then run Catalyst Uninstaller (http://downloads.guru3d.com/download.php?det=1275 (http://downloads.guru3d.com/download.php?det=1275)) or Driver Cleaner. Reboot, and reinstall my hacked drivers. You may need to do that several times (yes), until you run dxdiag and ddraw is enabled... don't know the reason, but the last time that happened to me it took me some hours to fix it, it really sucks.

I'll explain the other stuff in a while...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 23, 2011, 04:31:17 am
Quote
Well .. in dxdiag's Display panel  i've got a directdraw acceleration = unavalaible .... but i get direct3d avalaible and activated .. strange ...

Don't search any more, that's the problem. The drivers are not working properly. Unfortunately this happens from time to time, have no clue of the reason but I've seen the only way to repair it is to completely clean the system from any previous Catalyst software before installing the new Catalyst. You'd better do it starting in safe mode. Then run Catalyst Uninstaller (http://downloads.guru3d.com/download.php?det=1275 (http://downloads.guru3d.com/download.php?det=1275)) or Driver Cleaner. Reboot, and reinstall my hacked drivers. You may need to do that several times (yes), until you run dxdiag and ddraw is enabled... don't know the reason, but the last time that happened to me it took me some hours to fix it, it really sucks.

I'll explain the other stuff in a while...

 You're right, the problem was related to the fact that i didn't have directdraw acceleration,  :applaud: :applaud: :applaud:
 i've uninstalled/cleaned/reinstalled (at least 3 times) and now ddraw acceleration is here ^^

 Hummmm "real" vsync is much stable than "fake" vsync/throttle .. not perfect but really better.

 I've re-read  your previous posts and now i understand better the mechanisms of your drivers and soft15khz switchres chain...

 Thanks again for your support, and your patience  ;D
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 23, 2011, 06:57:00 am
It's good it was that! Thanks for testing. I'm preparing a new version of my drivers with a mode table specially designed for Switchres, hopefully I'll have it ready soon.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 23, 2011, 09:36:58 am
humm .. i've read that triple buffer may involve some "input lag"

http://shmups.system11.org/viewtopic.php?t=19516 (http://shmups.system11.org/viewtopic.php?t=19516)

 So i've tried with --args -notriplebuffer and ... 245% speed for mame ...

 Does the triplebuffer is mandatory for getting the right resolutions or can it be desactivated ?

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 23, 2011, 10:13:56 am
humm .. i've read that triple buffer may involve some "input lag"

http://shmups.system11.org/viewtopic.php?t=19516 (http://shmups.system11.org/viewtopic.php?t=19516)

 So i've tried with --args -notriplebuffer and ... 245% speed for mame ...

 Does the triplebuffer is mandatory for getting the right resolutions or can it be desactivated ?



You should be able to run switchres without triple buffer actually, and not need to send it that option.  It needs to know your turning off triple buffer basically, so doing this...

switchres <game> --soft15khz --notriplebuffer --threads

Should do it without triple buffer, seeing if taking away --threads above also may be tried if that still doesn't fix it.   I'm thinking possibly running it using --args is probably causing it to fail to work, so see if the above method works better.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 23, 2011, 10:17:04 am
switchres --mo 2 rfjet -v -v  -v -v -v -v -v --notriplebuffer

Opening  modes file for mode 320x240@54
Running Emulator: mame rfjet -resolution 320x240@54 -resolution0 320x240@54 -vid
eo ddraw -norotate -cleanstretch -nothrottle -nomt -waitvsync
Target refresh = 54.000000
Average speed: 365.00% (8 seconds)


Tried with --threads too and same bad result

EDIT = tried switchres <game> --soft15khz --notriplebuffer --threads   with no success , same problem....
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 23, 2011, 10:27:21 am
switchres --mo 2 rfjet -v -v  -v -v -v -v -v --notriplebuffer

Opening  modes file for mode 320x240@54
Running Emulator: mame rfjet -resolution 320x240@54 -resolution0 320x240@54 -vid
eo ddraw -norotate -cleanstretch -nothrottle -nomt -waitvsync
Target refresh = 54.000000
Average speed: 365.00% (8 seconds)


Tried with --threads too and same bad result

Weird, well that's the right way to run it like that, but seems like the vblank/vsync for the video card still isn't working, is the computer still saying it's available?  Calamity probably has more ideas what to try in Windows at that point since he has it running there like this.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 23, 2011, 10:30:12 am
Weird, well that's the right way to run it like that, but seems like the vblank/vsync for the video card still isn't working, is the computer still saying it's available?  Calamity probably has more ideas what to try in Windows at that point since he has it running there like this.

 Hummm .... dxdiag seems ok about ddraw acceleration ...

 Time for me to switch to Gentoo ^^
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 23, 2011, 11:27:29 am
I don't know if there is a thread dedicated to your GroovyArcade iso but  ...

 It seems that dhcp is not launched at boot, is this normal ?

 Also, when i boot latest revision on my laptop with a lcd connected to vga connector (no display panel, broken and removed) the MULTI grub menu give me a OUT OF SYNC on my lcd ... tried other modes too but i cannot get a vga boot.

 Here is the output of my lspci

Code: [Select]
GroovyArcade ~ # lspci
00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge
00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx)
00:04.0 PCI bridge: ATI Technologies Inc Device 7914
00:05.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 1)
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2)
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14)
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

 Can i specify my output at grub ? (vga connector instead internal lvd)

EDIT= GENTOO_MIRRORS may not be good for everyone ^^
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 23, 2011, 11:50:25 am
I don't know if there is a thread dedicated to your GroovyArcade iso but  ...

 It seems that dhcp is not launched at boot, is this normal ?

 Also, when i boot latest revision on my laptop with a lcd connected to vga connector (no display panel, broken and removed) the MULTI grub menu give me a OUT OF SYNC on my lcd ... tried other modes too but i cannot get a vga boot.

 Here is the output of my lspci

Code: [Select]
GroovyArcade ~ # lspci
00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge
00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx)
00:04.0 PCI bridge: ATI Technologies Inc Device 7914
00:05.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 1)
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2)
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14)
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

 Can i specify my output at grub ? (vga connector instead internal lvd)

This thread basically can cover the liveCD too, there's one in the Linux forum but since the liveCD is centered around running the switchres linux version to focus on supporting the features fully, seems like it is as good of place as any in this one.

It actually has the setup for the network when you startup, and that'll turn on dhcp at that point.  In theory it should display on both screens with the multi option or LCD/Flat panel VGA, although it will probably pick the lcd screen as the primary one.  It can be turned off at boot, the option on the grub command line is something like this...

video=LVDS-0:d

Also output to VGA/lcd monitors with the liveCD is slightly broken with anything not using good EDID monitor information currently, since it mainly focuses on arcade monitors that type of support right now is somewhat altered with the patches.  I need to eventually redo the patches to change how it works in those cases.  They currently sort of override everything for normal monitors and could be done better in working for all types. Also I'm not fully sure how X Windows will act although it might be fine after that command line is given. 

At the bottom of this page it explains how to add video= options and control monitor outputs...

http://nouveau.freedesktop.org/wiki/KernelModeSetting (http://nouveau.freedesktop.org/wiki/KernelModeSetting)

You can turn different video inputs on/off and choose resolutions for them, somewhat, although again it's really limited right now with how I've basically short circuited the normal support to CGA mode in the current kernel patches. 
Title: A
Post by: dapsaille on January 23, 2011, 12:25:07 pm
Well ..

 i've decided to stop trying to boot livecd with a vga monitor,
 i've just tried to boot livecd on my cab (the same that i used for windows switchres, so monitor is OK at 15khz)
and i cannot get a stable picture ..

 At boot it is at 31khz for grub menu (splitted in two by my jpac) but when i select Groovy Arcade LiveCD [CGA Arcade Monitor First VGA Output] the boot process stay at 31khz then suddently the picture divide by 4 instead of 2 like in 31khz mode ... i got 4 squares containing the picture of the boot process ..

 Tried DVI boot, nothing at screen (normal)

 I will try other boot methods but it is really strange ...

Title: Re: A
Post by: bitbytebit on January 23, 2011, 12:31:22 pm
Well ..

 i've decided to stop trying to boot livecd with a vga monitor,
 i've just tried to boot livecd on my cab (the same that i used for windows switchres, so monitor is OK at 15khz)
and i cannot get a stable picture ..

 At boot it is at 31khz for grub menu (splitted in two by my jpac) but when i select Groovy Arcade LiveCD [CGA Arcade Monitor First VGA Output] the boot process stay at 31khz then suddently the picture divide by 4 instead of 2 like in 31khz mode ... i got 4 squares containing the picture of the boot process ..

 Tried DVI boot, nothing at screen (normal)

 I will try other boot methods but it is really strange ...


Is your VGA output the first on the card or the second output?  It always chooses the first output for these, so anything else won't be 15khz.
Title: Re: A
Post by: dapsaille on January 23, 2011, 01:17:58 pm
Well ..

 i've decided to stop trying to boot livecd with a vga monitor,
 i've just tried to boot livecd on my cab (the same that i used for windows switchres, so monitor is OK at 15khz)
and i cannot get a stable picture ..

 At boot it is at 31khz for grub menu (splitted in two by my jpac) but when i select Groovy Arcade LiveCD [CGA Arcade Monitor First VGA Output] the boot process stay at 31khz then suddently the picture divide by 4 instead of 2 like in 31khz mode ... i got 4 squares containing the picture of the boot process ..

 Tried DVI boot, nothing at screen (normal)

 I will try other boot methods but it is really strange ...


Is your VGA output the first on the card or the second output?  It always chooses the first output for these, so anything else won't be 15khz.

 It is a laptop witha  broken screen on lvds and a vga output ... i will boot up a linux distro and launch a xrandr for being sure that there is no other "logical" output

Here is a picture after the grub selection (you can see that the jpac to the left is synced)
(http://img16.imageshack.us/img16/3795/img20110123183451.jpg)

when loading (sync ok too ... strange ^^)
(http://img522.imageshack.us/img522/9724/img20110123183650.jpg)

 And after at X (no sync)
(http://img40.imageshack.us/img40/8802/img20110123183832.jpg)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 23, 2011, 01:52:56 pm
Good news is you have video, and jpac gets sync, so it's probably your monitor not being able to sync at that hfreq, try to slightly adjust your hfreq potenciometer, could be that.

EDIT: Oh, just noticed the picture is doubled, forget what I've said.

EDIT2: Try CGA Arcade Monitor Second VGA Output (if it's a laptop, then VGA will likely be the second output).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 23, 2011, 02:33:17 pm
Weird, well that's the right way to run it like that, but seems like the vblank/vsync for the video card still isn't working, is the computer still saying it's available?  Calamity probably has more ideas what to try in Windows at that point since he has it running there like this.

Well, syncrefresh/waitvsync, according to the code, only work in the context of throttle + notriplebuffer (dd->back == NULL):

/src/osd/windows/drawdd.c

Code: [Select]
// sync to VBLANK
if ((video_config.waitvsync || video_config.syncrefresh) && window->machine->video().throttled() && (!window->fullscreen || dd->back == NULL))
  {
result = IDirectDraw7_WaitForVerticalBlank(dd->ddraw, DDWAITVB_BLOCKBEGIN, NULL);
if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X waiting for VBLANK\n", (int)result);
        }

So as we're disabling throttle, the above condition will not be true, so syncrefresh/waitvsync won't work. It will go directly to the blit without waiting.

After we do the blit, triplebuffer is checked. If it's enabled, we will wait+flip:

Code: [Select]
// page flip if triple buffered
if (window->fullscreen && dd->back != NULL)
{
result = IDirectDrawSurface7_Flip(dd->primary, NULL, DDFLIP_WAIT);
if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X waiting for VBLANK\n", (int)result);


So syncrefresh/waitvsync wait BEFORE the blit, triplebuffer waits+flips AFTER the blit. That's the only difference. So only one of those waits should happen (as is intended on the conditions above).

Of course we can patch Mame so that syncrefresh/waitvsync are considered even without throttle, doing this (haven't tested):

Code: [Select]
- if ((video_config.waitvsync || video_config.syncrefresh) && window->machine->video().throttled() && (!window->fullscreen || dd->back == NULL))
+ if ((video_config.waitvsync || video_config.syncrefresh) && (!window->fullscreen || dd->back == NULL))

But with the current CabMame builds triplebuffer is the only possibility by now to vsync without throttle.

Have a look at this one patch I posted:

http://forum.arcadecontrols.com/index.php?topic=106405.msg1150987#msg1150987 (http://forum.arcadecontrols.com/index.php?topic=106405.msg1150987#msg1150987)

That actually allows syncrefresh/waitvsync without throttle/triplebuffer, and at the same time performs a continuos poll of inputs while waiting, to minimize input lag. It needs multithreading enabled (--threads) otherwise will crash, so it's more of an experimental hack than anything else, though some ideas there could be useful.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 23, 2011, 02:48:51 pm
Weird, well that's the right way to run it like that, but seems like the vblank/vsync for the video card still isn't working, is the computer still saying it's available?  Calamity probably has more ideas what to try in Windows at that point since he has it running there like this.

Well, syncrefresh/waitvsync, according to the code, only work in the context of throttle + notriplebuffer (dd->back == NULL):

/src/osd/windows/drawdd.c

Code: [Select]
// sync to VBLANK
if ((video_config.waitvsync || video_config.syncrefresh) && window->machine->video().throttled() && (!window->fullscreen || dd->back == NULL))
  {
result = IDirectDraw7_WaitForVerticalBlank(dd->ddraw, DDWAITVB_BLOCKBEGIN, NULL);
if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X waiting for VBLANK\n", (int)result);
        }

So as disable throttle, the above condition will not be true, so syncrefresh/waitvsync won't work. It will go directly to the blit without waiting.

After we do the blit, triplebuffer is checked. If it's enabled, we will wait+flip:

Code: [Select]
// page flip if triple buffered
if (window->fullscreen && dd->back != NULL)
{
result = IDirectDrawSurface7_Flip(dd->primary, NULL, DDFLIP_WAIT);
if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X waiting for VBLANK\n", (int)result);


So syncrefresh/waitvsync wait BEFORE the blit, triplebuffer waits+flips AFTER the blit. That's the only difference. So only one of those waits should happen (as is intended on the conditions above).

Of course we can patch Mame so that syncrefresh/waitvsync are considered even without throttle, doing this (haven't tested):

Code: [Select]
- if ((video_config.waitvsync || video_config.syncrefresh) && window->machine->video().throttled() && (!window->fullscreen || dd->back == NULL))
+ if ((video_config.waitvsync || video_config.syncrefresh) && (!window->fullscreen || dd->back == NULL))

But with the current CabMame builds triplebuffer is the only possibility by now to vsync without throttle.

Have a look at this one patch I posted:

http://forum.arcadecontrols.com/index.php?topic=106405.msg1150987#msg1150987 (http://forum.arcadecontrols.com/index.php?topic=106405.msg1150987#msg1150987)

That actually allows syncrefresh/waitvsync without throttle/triplebuffer, and at the same time performs a continuos poll of inputs while waiting, to minimize input lag. It needs multithreading enabled (--threads) otherwise will crash, so it's more of an experimental hack than anything else, though some ideas there could be useful.

Ah I see, interesting, so that change should make this work it sounds like.  I'll have to add that into the builds and patches, I had used the original patch in the builds, but looks like that change too is needed to be in there for this to work without triple buffer.  Is triple buffer just a software thing or is it built into direct draw/3d?  I'm guessing it's specific to windows drivers since otherwise I'd guess they'd do the same in the SDL side too.  Is that the only change outside of the input changes that made it work correctly, or are there some more parts that changed from the first patch?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 23, 2011, 02:57:27 pm
I think the only change we should do by now is this:

Code: [Select]
- if ((video_config.waitvsync || video_config.syncrefresh) && window->machine->video().throttled() && (!window->fullscreen || dd->back == NULL))
+ if ((video_config.waitvsync || video_config.syncrefresh) && (!window->fullscreen || dd->back == NULL))

That should bring syncrefresh/waitvsync back to life.

The only thing triplebuffer does is to create a two back buffers (dd->back) so it can flip pages. If we don't use triplebuffer, then a raw blit to the visible video ram is performed instead, that's why we need syncrefresh/waitvsync to synchronize it with the vertical retrace.

I'm not fully sure if that page flip introduces any input lag because of page rotation (syncrefresh on the other hand should have the same input lag as throttle does).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 23, 2011, 03:33:57 pm
Sounds great, I've recompiled and have a new build of mame0141 up now with the fix...

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 23, 2011, 04:35:34 pm
I've tested new Mame build and it works ok  ;)
Now syncrefresh/waitvsync do the job even with nothrottle + notriplebuffer.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Haggar on January 24, 2011, 02:45:03 am
There are differences between "Switchres arcade monitor modeline generator and mame wrapper" and this method: http://postback.geedorah.com/foros/viewtopic.php?id=1424 (http://postback.geedorah.com/foros/viewtopic.php?id=1424) ?


I've tested new Mame build and it works ok  ;)
Now syncrefresh/waitvsync do the job even with nothrottle + notriplebuffer.
Can you explain me this "new feature"?

Refers to this, right?
Quote
-- CURRENT NEWS --
* Multiprocessor support for waitvsync mode with new mame patches, both Windows and Linux.
Thanks

EDIT:
Quote
That actually allows syncrefresh/waitvsync without throttle/triplebuffer, and at the same time performs a continuos poll of inputs while waiting, to minimize input lag.

In the past I've used Triple buffer with no throttle (and soundsync). Smooth scorlling, no stuttering at any resolution/Hz, but It caused heavy input lag.
Now I use only throttle+sync to monitor refresh (and always audiosync). All is fine and I have no input lag but I have to use a resolution with less Hz than the game (e.g. on 60Hz game I have to use 59.7 Hz), otherwise I get some spot accelerations.
What can I get with that new feature?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: SailorSat on January 24, 2011, 03:18:31 am
This sure will wet someones pants :)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 24, 2011, 05:02:37 am
There are differences between "Switchres arcade monitor modeline generator and mame wrapper" and this method: http://postback.geedorah.com/foros/viewtopic.php?id=1424 (http://postback.geedorah.com/foros/viewtopic.php?id=1424) ?

Both methods use similar modeline generation routines. But with VMMaker a static mode list is used, so a carefully selected mode list is needed to cover most situations, and mantaining a heavy ini folder so that each rom is assigned to the right video mode. You can modify VMMaker setup to get a different mode list + inis, but in order to see the results you need to reboot. That's why we say it's static. In a way it's the same method used by Soft-15Khz, in fact it's inspired on that program and Winmodelines, but with a built-in modeline generator that allows the automatization of the process. So with Soft-15Khz you would mantain a custom resolution list in a text file to feed the program with it, with VMMaker the list would be done for you extracting the needed info from Mame.xml. Another important feature is that VMMaker is intended to be used with my hacked Catalyst drivers (CRT_Emudriver), that allow more than a hundred video modes simultaneously, while normal Catalyst only admits 60. On the other hand VMMaker was still (is) on an experimental stage when I joined this thread, so it was limited to fixed-sync arcade monitors. And the dynamic modelines method I was testing would never be added to VMMaker, but to Switchres instead, as it is a much more ambitious project.

Switchres, under Windows, uses a dynamic mode list. That means that modelines can be recalculated on the fly right before launching Mame. So in way, you can see Switchres as the return of AdvanceMame. The method has its own limitations and we are working to get the best of it, but in practice it means you can have infinite modelines under Windows XP. Consider the variety of video modes derived from the resolution, i.e. 320x240. You have it in 50, 60, 57.55 Hz, etc. etc. Normally, you would have to store each of those video modes as a separate modeline. Now, you only have to store an instance of each resolution, say 320x240. All variety of needed vertical refreshes will be calculated out of 320x240 dummy resolution by Switchres.

I've tested new Mame build and it works ok  ;)
Now syncrefresh/waitvsync do the job even with nothrottle + notriplebuffer.
Can you explain me this "new feature"?

Refers to this, right?
Quote
-- CURRENT NEWS --
* Multiprocessor support for waitvsync mode with new mame patches, both Windows and Linux.
Thanks

EDIT:
Quote
That actually allows syncrefresh/waitvsync without throttle/triplebuffer, and at the same time performs a continuos poll of inputs while waiting, to minimize input lag.

In the past I've used Triple buffer with no throttle (and soundsync). Smooth scorlling, no stuttering at any resolution/Hz, but It caused heavy input lag.
Now I use only throttle+sync to monitor refresh (and always audiosync). All is fine and I have no input lag but I have to use a resolution with less Hz than the game (e.g. on 60Hz game I have to use 59.7 Hz), otherwise I get some spot accelerations.
What can I get with that new feature?

The input lag issue is a tricky subject. Many people are reporting input lag with triplebuffer, however I have never noticed it myself. I honestly can't see any difference even when using Shmupmame, but that could be because I'm not such a hardcore gamer and my eye is not trained on that. The joysticks on my cab are not the best ones for shmups either. I tended to believe people were having input lag because of choppyness introduced by their lousy setups when enabling triplebuffer with video modes far from correct. But this indeed deserves a deeper study.

What the new patch does is to enable vsync without page flipping (syncfresh vs triplebuffer), and still be able to turn throttle off. So you won't need to use a video mode with less Hz any more to avoid hiccups, by only enabling syncrefresh without triplebuffer/throttle. I would appreciate you tested this and tell us if you still have input lag or not, as I'm not the best one for determining that for the reasons I explained above.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Haggar on January 24, 2011, 06:13:29 am
Thank you very much for your explaination and thank you very much for CRT_Emudriver - VMMaker and the outstanding Arcade_OSD!

Years ago I was a very happy AdvanceMame+DOS user so for me this is great stuff!

I would appreciate you tested this and tell us if you still have input lag or not, as I'm not the best one for determining that for the reasons I explained above.
Sure!
Is there a compiled windows mame version with these fixes?

To test lag I use a little "trick": my spinner! With arkanoid the lag is easily noticeable :)

EDIT: I'm Kernel at ArcadeItalia forum :)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 24, 2011, 06:26:13 am
Try the one here:

http://sourceforge.net/projects/groovyarcade/files/Mame_Windows_Builds/ (http://sourceforge.net/projects/groovyarcade/files/Mame_Windows_Builds/)

Please tell us if you notice input lag with it.
Thanks!
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Haggar on January 24, 2011, 06:51:47 am
Mame settings I'll use (I hope to try it this evening at home): ddraw, nohwstretch, triplebuffer, nothrottle, soundsync
Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 24, 2011, 06:58:17 am
Mame settings I'll use (I hope to try it this evening at home): ddraw, nohwstretch, triplebuffer, nothrottle, soundsync
Thanks.

ddraw, nohwstretch, syncrefresh, notriplebuffer, nothrottle, soundsync

Try syncrefresh instead of triplebuffer, the purpose is to check if syncrefresh actually removes input lag compared to triplebuffer or if it's a myth:

(http://enemigapublica.files.wordpress.com/2008/08/mythbusters.jpg)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 24, 2011, 09:10:36 am
I'm not good as i wish at shmups so i cannot confirm if this works really, but ... it seems that it is better (really subjective).

 I've noticed a general "problem" ..
if i launch "stock" mame (configuration by default) without switchres and only frameskip set to 0 my games works perfectly, no sound or fps fluctuation .. always at 100%, but with switchres and modified mame.ini, i got lots of fluctuations in sound, even un old cps1 titles ... do you know where it can come, may it be related to cpu power ?

 It is really disturbing ...  ???

EDIT = with switchres  i can see Sound: buffer overflows=27 underflows=4 and in mame overflows=4 underflows=0 for the same game/gameplay ...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on January 24, 2011, 09:34:50 am
Hello, yesterday I can test the LiveCD32-Mini-NMO-1283-1fd9849.iso, I really liked how everything works properly, but I have seen problems when the installation / configuration, which will be very difficult to solve by inexperienced in linux, I comment with what I found.

Installation following steps are done well, but leaves to configure or set up some things wrong (I did the process 2 or 3 times, I think I did well but if not, then be my fault) I begin to enumerate.

1 The grub parameters are not correct, do not indicate where is the vmlinuz and the initrd have to put the correct path is / boot, remove the options you have the grub in the livecd etc ..

2 When it starts and ends the process I saw that I mounted / en / home / arcade, I have looked at fstab and actually do 2 times the mounting / as / root and / home / arcade, once removed this option and load without problems.

3 ş corrected the fstab, and does not charge directly wahcade, because it is waiting in the Xorg with a terminal, this is solved by copying in / home / arcade / file. Xclients do not know if this problem is derived from the assembly / in / home / arcade or because no copy.

4 ş missing symlinks in the folder / data that points to other configuration subcarpestas mame, also in / as many configuration files. Xinitrc. Config. Fvwm etc. .. that should be just in / home / arcade, this can cause the error mounting / en / home / arcade?

5 ş acpi does not work to stop the machine from the button poweroff the pc.

6 ş Wanting to stop the machine from wahcade faulted and restarted the X loading gdm waiting username and password, I think you should not use gdm, but directly launch X with startx (not if you have it so or not, I have not had time to see much)

7 The mame sound changes from one game to another one you hear very strong and in others much lower, it should normalize with alsa, no? but alsamixer does not work gives error can not find directory.

8 ş As information as it is not really a problem when loading some games I've seen errors on screen graphics information, but then the game works fine and without errors.

I see it is a great job (not like mine), but I think you should do as I did with Retrovicio, put all the mame config files etc. .. in / home / arcade, even the samba network etc. .. (After you pass a list as I have in retrovicio, that clear if it is implemented as well) and set up samba to share that folder, so people who do not have EXPERIENCE in linux atrabes network may keep the snap roms etc. .. from windows with no problems.

I think you should also introduce advmenu so you can choose, and they did not like at all wahcade, I personally do not like much, especially when games go past the images are not updated as advmenu, no configuration in the very front-end etc. ..

I hope this does not take it as a destructive criticism, but to be able to help or give ideas to improve your work and make it reach many more people, and you do not run on deaf ears, since it will be one heck anyone can be maintained to GroovyArcade.

And now a question rather silly "?? with all the work you've done with mame and I had not been geentoo easier advmame update to the newest version of mame?

One more thing, you could make a kernel over league, which puts less stuff? such as ubuntu, which is not what you charge and takes less time to boot?


Sorry for my English.

Spanish version for Calamity.

Code: [Select]
Hola , ayer ya puede probar la LiveCD32-Mini-NMO-1.283-1fd9849.iso , me ha gustado mucho como funciona  todo correctamente, pero he visto problemas a la hora de la instalacion/configuracion,los cuales seran muy complicado de resolver por inexpertos en linux, os comento con lo que me he encontrado.

Instalacion siguiendo los pasos se hace bien, pero deja por configurar o mal configuradas algunas cosas (hice el proceso 2 o 3 veces, creo que lo hice bien pero si no es asi, sera culpa mia) empiezo a enumerar.

1ş Los parametros de grub no son correctos, no les indica donde esta el vmlinuz ni el initrd hay que ponerle la ruta correcta que esta en /boot, hay que quitar las opciones que tiene el grub en el livecd etc..

2ş Cuando arranca y termina el proceso  he visto que me monta / en /home/arcade, he mirado en el fstab y efectivamente hace 2 veces el montaje del / , como / raiz, y en /home/arcade , una vez que se quita esa opcion ya carga sin problemas.

3ş Al corregir el fstab, ya no carga directamente wahcade , ya que se queda esperando en las Xorg con un terminal, esto se soluciona copiando en /home/arcade/ el fichero .Xclients, no se si este problema es derivado del montaje de / en /home/arcade o porque no se copia.

4ş Faltan enlaces simbolicos en la carpeta /data que apunta a otras subcarpestas de configuracion de mame, tambien hay en / muchos ficheros de configuracion como .xinitrc .config .fvwm etc.. que deberian de estar solo en /home/arcade, esto lo puede ocasionar el error de montaje de / en /home/arcade ??

5ş No funciona el acpi para poder apagar la maquina desde el boton de poweroff del pc.

6ş Al querer apagar la maquina desde wahcade da un fallo y se reinician las X cargando gdm esperando nombre de usuario y contraseńa, creo que no deberias de usar gdm, sino lanzar directamente las X con startx (no se si lo tienes asi o no, no me ha dado tiempo de ver mucho)

7ş El sonido con mame cambia de un juego para otro en uno se escucha muy fuerte y en otros mucho mas bajo, se deberia de normalizar con alsa,no? pero alsamixer no funciona da error de no encuentra directorio.

8ş Como informacion ya que no es realmente un problema, al cargar algunos juegos he visto que hay errores graficos en las pantallas de informacion , pero despues el juego funciona bien y sin errores.

Veo que es un trabajo estupendo (y no como el mio), pero creo que deberias de hacer como hice yo con Retrovicio , poner todos los ficheros de configuracion de mame etc.. en el /home/arcade , incluso los de red samba etc.. (luego te paso un listado de como lo tengo en retrovicio, eso claro si no esta ya implementado asi) y configurar samba para que comparta esa carpeta , asi la gente que no tenga esperiencia en linux podra atrabes de la red mantener las roms snap etc.. desde windows sin problemas.

Creo que tambien deberias de introducir advmenu para que se pueda elegir, ya que no les gustara a todos wahcade, a mi personalmente no me gusta mucho , sobre todo a la hora de ir pasando de juegos las imagenes no se actualizan como advmenu , no tiene configuracion en el propio front-end etc..

Espero que esto no te lo tomes como una critica destructiva sino para poder ayudarte o darte ideas para mejorar tu trabajo y hacerlo llegar a mucha mas gente, y que no se quede en saco roto, ya que sino sera una puńeta que nadie pueda ir manteniendo a GroovyArcade.

Y ahora una pregunta algo tontaż?ż? con todo el trabajo que has echo con el mame y con geentoo no te hubiese sido mas facil actualizar advmame a la nueva version de mame?

Una cosa mas, se podria hacer un kernel mas liguero , el cual carge menos cosas ? como el de ubuntu , que no se ve todo lo que carga y tarda menos en arrancar?


Thank.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 24, 2011, 10:37:24 am
Hello, yesterday I can test the LiveCD32-Mini-NMO-1283-1fd9849.iso, I really liked how everything works properly, but I have seen problems when the installation / configuration, which will be very difficult to solve by inexperienced in linux, I comment with what I found.

Installation following steps are done well, but leaves to configure or set up some things wrong (I did the process 2 or 3 times, I think I did well but if not, then be my fault) I begin to enumerate.

1 The grub parameters are not correct, do not indicate where is the vmlinuz and the initrd have to put the correct path is / boot, remove the options you have the grub in the livecd etc ..

2 When it starts and ends the process I saw that I mounted / en / home / arcade, I have looked at fstab and actually do 2 times the mounting / as / root and / home / arcade, once removed this option and load without problems.

3 ş corrected the fstab, and does not charge directly wahcade, because it is waiting in the Xorg with a terminal, this is solved by copying in / home / arcade / file. Xclients do not know if this problem is derived from the assembly / in / home / arcade or because no copy.

4 ş missing symlinks in the folder / data that points to other configuration subcarpestas mame, also in / as many configuration files. Xinitrc. Config. Fvwm etc. .. that should be just in / home / arcade, this can cause the error mounting / en / home / arcade?

5 ş acpi does not work to stop the machine from the button poweroff the pc.

6 ş Wanting to stop the machine from wahcade faulted and restarted the X loading gdm waiting username and password, I think you should not use gdm, but directly launch X with startx (not if you have it so or not, I have not had time to see much)

7 The mame sound changes from one game to another one you hear very strong and in others much lower, it should normalize with alsa, no? but alsamixer does not work gives error can not find directory.

8 ş As information as it is not really a problem when loading some games I've seen errors on screen graphics information, but then the game works fine and without errors.

I see it is a great job (not like mine), but I think you should do as I did with Retrovicio, put all the mame config files etc. .. in / home / arcade, even the samba network etc. .. (After you pass a list as I have in retrovicio, that clear if it is implemented as well) and set up samba to share that folder, so people who do not have EXPERIENCE in linux atrabes network may keep the snap roms etc. .. from windows with no problems.

I think you should also introduce advmenu so you can choose, and they did not like at all wahcade, I personally do not like much, especially when games go past the images are not updated as advmenu, no configuration in the very front-end etc. ..

I hope this does not take it as a destructive criticism, but to be able to help or give ideas to improve your work and make it reach many more people, and you do not run on deaf ears, since it will be one heck anyone can be maintained to GroovyArcade.

And now a question rather silly "?? with all the work you've done with mame and I had not been geentoo easier advmame update to the newest version of mame?

One more thing, you could make a kernel over league, which puts less stuff? such as ubuntu, which is not what you charge and takes less time to boot?


Sorry for my English.

Spanish version for Calamity.

Code: [Select]
Hola , ayer ya puede probar la LiveCD32-Mini-NMO-1.283-1fd9849.iso , me ha gustado mucho como funciona  todo correctamente, pero he visto problemas a la hora de la instalacion/configuracion,los cuales seran muy complicado de resolver por inexpertos en linux, os comento con lo que me he encontrado.

Instalacion siguiendo los pasos se hace bien, pero deja por configurar o mal configuradas algunas cosas (hice el proceso 2 o 3 veces, creo que lo hice bien pero si no es asi, sera culpa mia) empiezo a enumerar.

1ş Los parametros de grub no son correctos, no les indica donde esta el vmlinuz ni el initrd hay que ponerle la ruta correcta que esta en /boot, hay que quitar las opciones que tiene el grub en el livecd etc..

2ş Cuando arranca y termina el proceso  he visto que me monta / en /home/arcade, he mirado en el fstab y efectivamente hace 2 veces el montaje del / , como / raiz, y en /home/arcade , una vez que se quita esa opcion ya carga sin problemas.

3ş Al corregir el fstab, ya no carga directamente wahcade , ya que se queda esperando en las Xorg con un terminal, esto se soluciona copiando en /home/arcade/ el fichero .Xclients, no se si este problema es derivado del montaje de / en /home/arcade o porque no se copia.

4ş Faltan enlaces simbolicos en la carpeta /data que apunta a otras subcarpestas de configuracion de mame, tambien hay en / muchos ficheros de configuracion como .xinitrc .config .fvwm etc.. que deberian de estar solo en /home/arcade, esto lo puede ocasionar el error de montaje de / en /home/arcade ??

5ş No funciona el acpi para poder apagar la maquina desde el boton de poweroff del pc.

6ş Al querer apagar la maquina desde wahcade da un fallo y se reinician las X cargando gdm esperando nombre de usuario y contraseńa, creo que no deberias de usar gdm, sino lanzar directamente las X con startx (no se si lo tienes asi o no, no me ha dado tiempo de ver mucho)

7ş El sonido con mame cambia de un juego para otro en uno se escucha muy fuerte y en otros mucho mas bajo, se deberia de normalizar con alsa,no? pero alsamixer no funciona da error de no encuentra directorio.

8ş Como informacion ya que no es realmente un problema, al cargar algunos juegos he visto que hay errores graficos en las pantallas de informacion , pero despues el juego funciona bien y sin errores.

Veo que es un trabajo estupendo (y no como el mio), pero creo que deberias de hacer como hice yo con Retrovicio , poner todos los ficheros de configuracion de mame etc.. en el /home/arcade , incluso los de red samba etc.. (luego te paso un listado de como lo tengo en retrovicio, eso claro si no esta ya implementado asi) y configurar samba para que comparta esa carpeta , asi la gente que no tenga esperiencia en linux podra atrabes de la red mantener las roms snap etc.. desde windows sin problemas.

Creo que tambien deberias de introducir advmenu para que se pueda elegir, ya que no les gustara a todos wahcade, a mi personalmente no me gusta mucho , sobre todo a la hora de ir pasando de juegos las imagenes no se actualizan como advmenu , no tiene configuracion en el propio front-end etc..

Espero que esto no te lo tomes como una critica destructiva sino para poder ayudarte o darte ideas para mejorar tu trabajo y hacerlo llegar a mucha mas gente, y que no se quede en saco roto, ya que sino sera una puńeta que nadie pueda ir manteniendo a GroovyArcade.

Y ahora una pregunta algo tontaż?ż? con todo el trabajo que has echo con el mame y con geentoo no te hubiese sido mas facil actualizar advmame a la nueva version de mame?

Una cosa mas, se podria hacer un kernel mas liguero , el cual carge menos cosas ? como el de ubuntu , que no se ve todo lo que carga y tarda menos en arrancar?


Thank.

It's good information, there's definitely a ton of things to get fixed up like these.  I agree on many of them, some of them are things I haven't had time to look closer at though or others stuff I am not sure are easily done. 

I like the idea of advancemenu, but I just have never seen it actually work, for some reason it's always failed to load for me and complains about my video card not being compatible.  Wahcade works for me, but I don't like the configuration of it either, wish it was more automated like advancemenu sounds.  Any help in how to get advancemenu working would be great.

I'm not sure how the grub.conf and fstab could be improved, but I'm open to fixes to them, they basically work for me on basic installs but may have issues I am guessing.  Really the system is meant as a basic liveCD just to run, for now, and hopefully these things can over time get more user friendly to being a generalized Linux system and arcade machine more for an installation.

The directory structures for the ROM locations is definitely a pain, I need to fix that somehow to be a lot better, it works for my setup here I have but am sure it's not perfect but of course haven't had too much closer detailed looking into what to do to fix it.

Actually gdm is used because of issues with the liveCD boot and how it is a root user, and setup when you first boot up.  Basically everything was really difficult to setup and get running smoothly then go into X Windows without gdm, plus it logs in the normal user automatically which seemed like a good bonus.  I seemed right because it's what most distributions do, it could launch wahcade (or another frontend in the future) instead of a window manager, right now has the choice of wahcade in setup but of course you have to set it up first and it's a pain.  So that does need work.

Actually the kernel config I use is from ubuntu, it is large but also should cover anybodys hardware.  I'd of course always be looking to remove extra stuff, like all the iptables/filtering stuff I have removed, it really should be smaller than Ubuntu's kernel.  The actual kernel itself might be slightly larger, the vmlinuz file, because it contains the radeon/drm layer and drivers plus the radeon firmware is compiled into it.  That is how you get 15khz right at boot after grub, you won't get that in any other Linux setup right now without an arcadeVGA card.

I probably need to fix acpi, I know on some machines it seems to not like rebooting smoothly.  For now I've left it at that because it's a liveCD mostly, and doesn't really matter if the user just switches the machine off.  It does seem to reboot fine though after you install to disk a lot of the time, at least the machines I've tested on.  I'm not sure why that is.

It uses OSS4 actually, Alsa is disabled, try the ossmix or ossxmix programs instead of alsamixer.  We use OSS4 now because it works better than Alsa, at least is more compatible with more cards and it doesn't have issues with sharing inputs.  It at least works it seems with mame, and that is the important part, and overall has acted better for me than Alsa did. 

I'm not sure why the audio is doing that, I've never seen that here.

Advancemame is really a complete rewrite of a large part of Mame from what I can tell, I don't think anybody can maintain it and update it.  Also I think we are doing better than Advance mame in a lot of ways, by separating things that we do  from Mame for the most part we are going to be able to run other emulators besides mame, we won't die like advance mame has from not being maintainable, and can somewhat do more stuff than it could and follow the operating systems procedures/API too.  I would love to explore advance mame more and find any information on how it was doing stuff, something on my todo list.

There is the GIT repository, so you can build and explore the actual distribution creating to for the ISO images, and can help fix things too.  Or you can even take the things this Groovy Arcade does and put them into yours your working on too.  It'd be great for the things I'm doing to be able to get used in your ISO too, because this in a lot of ways is a demonstration of how to use switchres but not the only possible linux system to use it on.  You could even take the GIT repository and completely use it for yours, or parts of it, which would be great too.  It's sort of a 'research project' in utilizing the most bleeding edge linux kernel and X Windows/Mesa/DRI/DRM code available to get the best arcade monitor output.  The actual full user friendly part may be more because it mostly is limited in function to work on arcade monitors, boot up and run mame, but mostly just a quick way to test hardware and see how switchres can work in Linux and show a baseline of which kernel with my patches and versions of X Windows and system setup are needed too.

It's great to hear the feedback about it, I'll be reading deeper into your feedback over time and hopefully this is just another todo list for me to follow and help make the ISO image even better.  Definitely check out the git repository too and see if you can build the ISO setup/build, and/or patch things, submit patches, would be great to have more help at fixing things up and figuring things out.




Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 24, 2011, 11:12:38 am
Looks like Mame 0141u1 has the -mt fix in it for vsync, looks interesting...

Code: [Select]
Added "-syncrefresh" option to osd/sdl. This will *limit* the game
speed to the video refresh rate and works in -mt mode as well. The
option has an effect only if "-waitsync" is specified.
[Couriersud, Chris Kennedy]

Which seems to be mainly this change...
Code: [Select]
diff -Nru src-old/osd/sdl/window.c src/osd/sdl/window.c
--- src-old/osd/sdl/window.c    2010-12-02 09:26:38.000000000 -0800
+++ src/osd/sdl/window.c        2011-01-22 04:51:52.000000000 -0800
@@ -949,6 +949,7 @@
 void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *window)
 {
 
+       osd_ticks_t             event_wait_ticks;
        ASSERT_MAIN_THREAD();
 
        // adjust the cursor state
@@ -977,8 +978,12 @@
                        }
                }
 
-               // only render if we have been signalled
-               if (osd_event_wait(window->rendered_event, 0))
+               if (video_config.waitvsync && video_config.syncrefresh)
+                       event_wait_ticks = osd_ticks_per_second(); // block at most a second
+               else
+                       event_wait_ticks = 0;
+
+               if (osd_event_wait(window->rendered_event, event_wait_ticks))
                {
                        worker_param wp;
                        render_primitive_list *primlist;


First glance tells me this is the same thing basically just done better and more interesting by splitting it out into two options.  I'll have to check though to see how accurate it runs, when testing it was really oddly picky about exactly where I waited and the patch I have currently is actually doing the wait slightly in a different spot in the drawing thread process.

Looks interesting, main thing though is that switchres and 0141u1 will definitely have to change some command line options to run correctly, and guessing the Windows side of this might be either not happening in Mame or waiting for more work by them to do it a different way.  So guess now in Linux the whole syncrefresh option and waitvsync option are there together, oddly now Linux in Mame uses -mt and -nothrottle and -waitvsync and -syncrefresh without problems most likely while Windows doesn't without the patch from Calamity.  From what I gathered the Windows OSD part of Mame is probably way harder to get changed at all since that's what the developers use most and there's only one or so that use the SDL stuff.

I'll have to give 0141u1 a test in Linux and see if it's the same or better than what I did in my patch originally.  Shouldn't be too hard in switchres to check for that options availability and setup the mame command line properly if it's available and add that -syncrefresh option.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 24, 2011, 11:44:08 am
simple stupid question ... what is the root password for GroovyArcade latest mini iso ? ^^

 (tired to chroot from a livecd, no vga monitor near cab)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 24, 2011, 11:44:17 am
Interesting. I'm not surprised they haven't consider the Windows patch yet for -mt as it's in the window.c osd core file and suppose that part needs to be controlled by the big boss, and after all that patch (SetEvent/WaitForSingleObject) was not the cleanest possible one. It turned out it was just necessary (equivalent) to do this:

/src/osd/windows/window.c

Code: [Select]
if (multithreading_enabled)
- PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
else
SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
mtlog_add("winwindow_video_window_update: PostMessage end");

... in other words, to revert the behaviour that is there by design. So the PostMessage method is the one that Mame devs have actually designed for ordering the main window to update itself when in multithreading context, but... as that makes both threads asynchronous (PostMessage does not wait) it breaks triplebuffer/syncrefresh (probably Mame devs are not using vsync anymore so didn't check this).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 24, 2011, 11:47:52 am
simple stupid question ... what is the root password for GroovyArcade latest mini iso ? ^^

 (tired to chroot from a livecd, no vga monitor near cab)
It's arcade by default, but also you can just type 'sudo -s' too and that'll not require a password.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 24, 2011, 11:49:57 am
simple stupid question ... what is the root password for GroovyArcade latest mini iso ? ^^

 (tired to chroot from a livecd, no vga monitor near cab)
It's arcade by default, but also you can just type 'sudo -s' too and that'll not require a password.

 Thanks but i've selected wahcade at boot,

 i'm happy that your distro work fine on my other mamecab, it seems that my laptop doesn't like linux and will stay under windows.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 24, 2011, 11:51:36 am
Interesting. I'm not surprised they haven't consider the Windows patch yet for -mt as it's in the window.c osd core file and suppose that part needs to be controlled by the big boss, and after all that patch (SetEvent/WaitForSingleObject) was not the cleanest possible one. It turned out it was just necessary (equivalent) to do this:

/src/osd/windows/window.c

Code: [Select]
if (multithreading_enabled)
- PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
else
SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
mtlog_add("winwindow_video_window_update: PostMessage end");

... in other words, to revert the behaviour that is there by design. So the PostMessage method is the one that Mame devs have actually designed for ordering the main window to update itself when in multithreading context, but... as that makes both threads asynchronous (PostMessage does not wait) it breaks triplebuffer/syncrefresh (probably Mame devs are not using vsync anymore so didn't check this).

Yeah, and from what I have gathered they really don't think of running on arcade monitors as something they need to adjust anything for.  So guessing on the Windows side we'll have to have a separate patch, since the general message seems to be that they are willing to let the SDL/Linux side be there for arcade monitors but in Windows they are focused on being able to test emulation themselves on modern monitors and that's it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 24, 2011, 11:53:39 am
simple stupid question ... what is the root password for GroovyArcade latest mini iso ? ^^

 (tired to chroot from a livecd, no vga monitor near cab)
It's arcade by default, but also you can just type 'sudo -s' too and that'll not require a password.

 Thanks but i've selected wahcade at boot,

 i'm happy that your distro work fine on my other mamecab, it seems that my laptop doesn't like linux and will stay under windows.

You should be able to do a Ctl+Alt+F1 and get to the console and do anything there needed.  Definitely is one of the issues with running the frontend by default instead of a window manager, sort of a tricky thing I haven't fully figured out a best way to deal with.  Hopefully the console works though and does the job.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 24, 2011, 11:56:19 am
simple stupid question ... what is the root password for GroovyArcade latest mini iso ? ^^

 (tired to chroot from a livecd, no vga monitor near cab)
It's arcade by default, but also you can just type 'sudo -s' too and that'll not require a password.

 Thanks but i've selected wahcade at boot,

 i'm happy that your distro work fine on my other mamecab, it seems that my laptop doesn't like linux and will stay under windows.

You should be able to do a Ctl+Alt+F1 and get to the console and do anything there needed.  Definitely is one of the issues with running the frontend by default instead of a window manager, sort of a tricky thing I haven't fully figured out a best way to deal with.  Hopefully the console works though and does the job.

 In the livecd environnement it is ok, i can get consoles already logged at root, but i've installed to my hdd and i get only prompt, no autologin for consoles .
 Problem is solved, password changed and dhcp activated ^^
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 24, 2011, 01:40:52 pm
I'm not good as i wish at shmups so i cannot confirm if this works really, but ... it seems that it is better (really subjective).

 I've noticed a general "problem" ..
if i launch "stock" mame (configuration by default) without switchres and only frameskip set to 0 my games works perfectly, no sound or fps fluctuation .. always at 100%, but with switchres and modified mame.ini, i got lots of fluctuations in sound, even un old cps1 titles ... do you know where it can come, may it be related to cpu power ?

 It is really disturbing ...  ???

EDIT = with switchres  i can see Sound: buffer overflows=27 underflows=4 and in mame overflows=4 underflows=0 for the same game/gameplay ...

I'll check it hopefully this evening. But... do you notice those fluctuations in game action (scroll) or only in sound and fps (f11)? If scroll is fluent, then vsync is ok, as the videocard acts as an accurate clock, better that using the cpu clock indeed. So REAL fps must be a constant figure, but... measured fps (the one Mame prompts) can fluctuate around as it's measured using the cpu clock. As soundsync patch uses that measured fps as a factor to apply to sound frequency, then sound pitch can actually fluctuate slightly due to that badly calculated value. A workaround could be to precalculate the sound factor as a cocient of our_modeline_fps / target_fps and then use that as a constant to apply to the soundbuffer frequency.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 24, 2011, 02:56:29 pm
Calamity, This uses your newest method of simplified fixing the Windows side of -mt and -waitvsync together and also the other fix for no triplebuffer and waitvsync.  See if this build works as well as the other builds...

In the Mame builds folder:
mame0141u1.7z
Code: [Select]
diff --git a/src/osd/windows/drawdd.c b/src/osd/windows/drawdd.c
index 0b8be96..56d28c1 100644
--- a/src/osd/windows/drawdd.c
+++ b/src/osd/windows/drawdd.c
@@ -457,7 +457,7 @@ static int drawdd_window_draw(win_window_info *window, HDC dc, int update)
        if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X unlocking blit surface\n", (int)result);
 
        // sync to VBLANK
-       if ((video_config.waitvsync || video_config.syncrefresh) && window->machine->video().throttled() && (!window->fullscreen || dd->back == NULL))
+       if ((video_config.waitvsync || video_config.syncrefresh) && (!window->fullscreen || dd->back == NULL))
        {
                result = IDirectDraw7_WaitForVerticalBlank(dd->ddraw, DDWAITVB_BLOCKBEGIN, NULL);
                if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X waiting for VBLANK\n", (int)result);
@@ -770,7 +780,7 @@ void winwindow_video_window_update(win_window_info *window)
                        // post a redraw request with the primitive list as a parameter
                        last_update_time = timeGetTime();
                        mtlog_add("winwindow_video_window_update: PostMessage start");
-                       if (multithreading_enabled)
+                       if (multithreading_enabled && !video_config.waitvsync && !video_config.syncrefresh)
                                PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
                        else
                                SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);


Also it works well in Linux now with the official mame u1 patch, so looks that's in there and I can't see a difference between it and the last version with my previous patch.

Update:
Almost forgot, there'll be a new version 1.294-48d17ef of switchres to work properly too using -syncrefresh correctly outside of triplebuffer.  That'll be up in a few minutes, I was confining that option to -triplebuffer but now see it and waitvsync are needed together it seems.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 24, 2011, 03:52:20 pm


I think you should also introduce advmenu so you can choose, and they did not like at all wahcade, I personally do not like much, especially when games go past the images are not updated as advmenu, no configuration in the very front-end etc. ..



Ves,  Do you have an example/good default advance menu config I could start from?  I am trying advance menu again and I now see it is working and definitely looks like it could be a lot better than wahcade when setup right.  I am having issues though figuring out how to do full screen mode, good default resolution for the 640x480 desktop, generally if there's some more optimal theme/colors and sound (or no default sound), just something more advanced than the basic config it comes with.  That would help me start using it on the ISO much quicker to get a jumpstart at a better setup.  Also is there a way to tell it to use the mame.ini file as being somewhere else besides /usr/local/bin/mame.ini ?  Seems odd it wants it there, and of course a user can't write to that location and it's way outside the home directory for /home/arcade/.  I definitely like the way it doesn't need some complicated steps to just get working, although also wondering how to do the artwork locations or where are they by default?   I've got it running switchres just fine and that looks good, was pretty simple to do that, but the config looks a bit difficult to quickly alter and mold to what would be better than wahcade.  Looks like I could configure it with all the different emulators too easier, and hopefully makes the interface issue better, I've actually been wanting to address this lately.

Also I figured out the acpid issue, thanks for seeing that, have been working on quite a few of the things you found, thanks again for the feedback.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 24, 2011, 05:55:32 pm
I confirm the last patch works great. So actually that:

 if (multithreading_enabled && !video_config.waitvsync && !video_config.syncrefresh)

... seems a clever solution as it only changes the behaviour when syncrefresh/waitvsync is on (triplebuffer on the other hand still allows both threads run full speed).

I'm thinking triplebuffer could be modified to remove it's internal vsync and only perform page flipping, as it's a bit confusing as it's now, that could be done by not using the DDFLIP_WAIT flag, so vsync should be explicitly stated by -syncrefresh... don't know if it's a good idea... it could mislead people already used to the normal vsynced triplebuffer.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on January 24, 2011, 05:59:19 pm
Hi bitbytebit , I put the advmenu.rc here is the configuration file for advmenu this is created in /home/user/.advmenu, with respect to the omitted advmenu mame.ini file that file the only searches for the executable or generic emulator which has been set, which creates in its folder .advmenu the mame.xml etc. ..

With respect to the easy user configuration you want to refer to my livecd that has passed away (which lasted little) is totally minimal, no desktop or gdm or anything else just carries on startx. Xinitrc is the advmenu to run that way which you can see that is fast, I think you should remove the sales managers as fwm etc .. and remove all gdm to not reload when an error.

Please try it and get all the items or files that you are utilies. (So if the music advmenu not remember where the service but do not think it a problem)

http://www.retrovicio.com/foro/showthread.php?t=9258 (http://www.retrovicio.com/foro/showthread.php?t=9258)

As you can see from my livecd my settings are more or less so.

Samba shares /home/retrovicio with full permissions to read/write so you can manage the roms from windows, and even go switchres updated suckle and just copying the executable.

/Home/retrovicio/mame symbolic link to .Mame
/ Home/retrovicio/advmame symbolic link to .Advmame
/ Home/samba/smb.conf This is the actual file, and in /etc/samba/smb.conf is the symbolic link to smb.conf
/Home/retrovicio/.mame/mame (actual executable) and a symbolic link to /usr/game/mame
And so, etc. ..

 I'm thinking it would not make sense to put on or Xorg Red Samba home as these parameters would not be changed, especially Xorg, maybe the only thing left would be Red because if we need to change the ip is as easy as editing with notepad, Samba and would remove him because I do not share anything else that is home / arcade, and if so I think I would know the user.

You could also put an image loading plymounth or something.

With regard to your live update, this function now? I mean I have it installed the update as I can in debian with apt-get update, and I cojeria your improvements?

As for what the git I have not understood what you wanted to say.

I will keep this tournament very closely to be able to help as much as possible.


Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 24, 2011, 06:21:54 pm
Hi VeS, it's nice to see you here! :)

This is the GIT:

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=summary (http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=summary)

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Haggar on January 25, 2011, 05:42:06 am
Mame settings I'll use (I hope to try it this evening at home): ddraw, nohwstretch, triplebuffer, nothrottle, soundsync
Thanks.

ddraw, nohwstretch, syncrefresh, notriplebuffer, nothrottle, soundsync

Try syncrefresh instead of triplebuffer, the purpose is to check if syncrefresh actually removes input lag compared to triplebuffer or if it's a myth:
I've tried it quickly and it seems very good! No lag and no audio hiccups!

To activate soundsync I have to add "soundsync   1" into mame.ini, right?

This evening I'll try it in depth.
Is there any other useful test I can do?

Thanks
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 25, 2011, 07:14:01 am
Mame settings I'll use (I hope to try it this evening at home): ddraw, nohwstretch, triplebuffer, nothrottle, soundsync
Thanks.

ddraw, nohwstretch, syncrefresh, notriplebuffer, nothrottle, soundsync

Try syncrefresh instead of triplebuffer, the purpose is to check if syncrefresh actually removes input lag compared to triplebuffer or if it's a myth:
I've tried it quickly and it seems very good! No lag and no audio hiccups!

To activate soundsync I have to add "soundsync   1" into mame.ini, right?

This evening I'll try it in depth.
Is there any other useful test I can do?

Thanks

Oh that's great! So you mean it's better that way (notriplebuffer) than with triplebuffer on, less lag, isn't it? You could test with/without triplebuffer to see if you actually notice a difference with your spinner, so we make sure triplebuffer (page flipping) is actually the problem.
For what I've seen, soundsync is automatically set on, you shouldn't need to add it in Mame.ini
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Haggar on January 25, 2011, 09:02:41 am
Ok.
I'll test it this evening and let you know  :)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on January 25, 2011, 09:40:06 am
Hello, here I put the configuration advmenu.rc
To select the video mode you can play with this option will change to 640 1024 etc. ..
device_video_overlaysize 320

I can not remember if mame runs either directly or through switchres if so you'll have to configure emulator advmenu.rc as generic and remove the lines suck, remember to protect the file so you will not reinstate the configuration of mame, and that mame default if found includes it.

http://advancemame.sourceforge.net/doc-advmenu.html#4.1 (http://advancemame.sourceforge.net/doc-advmenu.html#4.1)

If I can watch tonight, if I have created advmenu.rc switchres configuradon with another hd.


Code: [Select]
config save_at_exit

device_color_bgr15 yes

device_color_bgr16 yes

device_color_bgr24 yes

device_color_bgr32 yes

device_color_bgr8 yes

device_color_palette8 yes

device_color_yuy2 yes

device_joystick none

device_keyboard auto

device_mouse none

device_sound sdl

device_video sdl

device_video_cursor auto

device_video_doublescan yes

device_video_fastchange no

device_video_interlace yes

device_video_output fullscreen

device_video_overlaysize 320

device_video_singlescan yes

difficulty none
display_brightness 1

display_gamma 1

display_orientation
display_restoreatexit yes

display_restoreatgame no

display_size 320

emulator "MAME" mame "/usr/games/mame"

emulator_roms "MAME" "/home/retro/mame/roms:/media/usb/roms"

emulator_flyers "MAME" "/home/retro/mame/flyers"

emulator_altss "MAME" "/home/retro/mame/snap"

emulator_cabinets "MAME" "/home/retro/mame/cabinets"

emulator_titles "MAME" "/home/retro/mame/titles"

emulator "ADvMAME" advmame "/usr/local/bin/advmame"

emulator_roms "ADvMAME" "/home/retro/mame/roms"

emulator_flyers "ADvMAME" "/home/retro/mame/flyers"

emulator_altss "ADvMAME" "/home/retro/mame/snap"

emulator_cabinets "ADvMAME" "/home/retro/mame/cabinets"

emulator_titles "ADvMAME" "/home/retro/mame/titles"

event_alpha no

event_assign up up or 8_pad

event_assign down down or 2_pad

event_assign left left or 4_pad

event_assign right right or 6_pad

event_assign enter enter or enter_pad or 1

event_assign esc esc or w

event_assign space space

event_assign home home

event_assign end end

event_assign pgup pgup

event_assign pgdn pgdn

event_assign del del

event_assign ins insert

event_assign shutdown 2 or lcontrol esc

event_assign mode tab or z

event_assign help f1

event_assign group f2

event_assign type f3

event_assign exclude f4

event_assign sort f5

event_assign setgroup f9

event_assign settype f10

event_assign runclone f12 or a

event_assign command f8

event_assign menu backquote or backslash

event_assign emulator f6 or s

event_assign rotate 0_pad

event_assign lock scrlock

event_assign preview space

event_mode fast

event_repeat 500 50

icon_space 43

idle_screensaver 60 10

idle_screensaver_preview snap

idle_start 0 0

include
input_hotkey yes

#Para no poder salir a consola

lock no

menu_base 3199
menu_rel 5
merge differential

misc_exit all

misc_quiet no

mode list_mixed
mode_skip
mouse_delta 100

preview snap
preview_default none

preview_default_cabinet yes

preview_default_flyer yes

preview_default_icon none

preview_default_marquee yes

preview_default_snap none

preview_default_title yes

preview_expand 1.15

sort parent
sound_background_begin none

sound_background_end none

sound_background_loop sloop.mp3

sound_background_loop_dir "mp3"

sound_background_start none

sound_background_stop none

sound_buffer 0.1

sound_foreground_begin default

sound_foreground_end default

sound_foreground_key default

sound_foreground_start sstart.mp3

sound_foreground_stop default

sound_latency 0.1

sound_samplerate 44100

sound_volume -3

ui_background
ui_bottombar yes

ui_clip single

ui_color help 000000 ffffff

ui_color help_tag 247ef0 ffffff

ui_color submenu_bar 247ef0 ffffff

ui_color submenu_item 000000 ffffff

ui_color submenu_item_select 000000 afffff

ui_color submenu_hidden 808080 ffffff

ui_color submenu_hidden_select 808080 afffff

ui_color menu_item 000000 ffffff

ui_color menu_hidden 808080 ffffff

ui_color menu_tag 247ef0 ffffff

ui_color menu_item_select 000000 afffff

ui_color menu_hidden_select 808080 afffff

ui_color menu_tag_select 247ef0 afffff

ui_color bar 000000 ffffff

ui_color bar_tag 247ef0 ffffff

ui_color bar_hidden 808080 ffffff

ui_color grid 247ef0 ffffff

ui_color backdrop 000000 808080

ui_color icon ffffff ffffff

ui_color cursor 808080 ffffff

ui_command_error Error running the command

ui_command_menu Command...

ui_console no

ui_exit none

ui_font auto

ui_fontsize auto

ui_game snap

ui_gamemsg "Cargando Juego.."

ui_help none

ui_menukey yes

ui_skipbottom 0

ui_skipleft 0

ui_skipright 0

ui_skiptop 0

ui_startup none

ui_topbar yes

ui_translucency 0.6

MAME/mode list_mixed

MAME/preview snap

mame/preview snap
mame/mode list_mixed
group_include "<undefined>"
group_include "Bad"
group_include "Good"
group_include "Very Good"
type_include "<undefined>"
type_include "Application"
type_include "Arcade"
type_include "Bet 'em Up"
type_include "Breakout"
type_include "Computer"
type_include "Console"
type_include "Fight"
type_include "Filler"
type_include "Flipper"
type_include "Gun"
type_include "Puzzle"
type_include "RPG"
type_include "Racing"
type_include "Shot 'em Up"
type_include "Sport"
emulator_include "MAME"
group "<undefined>"
group "Bad"
group "Good"
group "Very Good"
type "<undefined>"
type "Application"
type "Arcade"
type "Bet 'em Up"
type "Breakout"
type "Computer"
type "Console"
type "Fight"
type "Filler"
type "Flipper"
type "Gun"
type "Puzzle"
type "Racing"
type "RPG"
type "Shot 'em Up"
type "Sport"
emulator_attrib "MAME" missing exclude
emulator_attrib "MAME" clone exclude
emulator_attrib "MAME" bad exclude
emulator_attrib "MAME" vector include
emulator_attrib "MAME" vertical include
emulator_attrib "MAME" neogeo include
emulator_attrib "MAME" deco exclude
emulator_attrib "MAME" playchoice exclude
emulator_attrib "ADvMAME" missing exclude
emulator_attrib "ADvMAME" clone exclude
emulator_attrib "ADvMAME" bad exclude
emulator_attrib "ADvMAME" vector include
emulator_attrib "ADvMAME" vertical include
emulator_attrib "ADvMAME" neogeo include
emulator_attrib "ADvMAME" deco exclude
emulator_attrib "ADvMAME" playchoice exclude


Also I put here the smb.conf file if it's more like you


Code: [Select]
#
# Sample configuration file for the Samba suite for Debian GNU/Linux.
#
#
# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options most of which
# are not shown in this example
#
# Some options that are often worth tuning have been included as
# commented-out examples in this file.
#  - When such options are commented with ";", the proposed setting
#    differs from the default Samba behaviour
#  - When commented with "#", the proposed setting is the default
#    behaviour of Samba but the option is considered important
#    enough to be mentioned here
#
# NOTE: Whenever you modify this file you should run the command
# "testparm" to check that you have not made any basic syntactic
# errors.
# A well-established practice is to name the original file
# "smb.conf.master" and create the "real" config file with
# testparm -s smb.conf.master >smb.conf
# This minimizes the size of the really used smb.conf file
# which, according to the Samba Team, impacts performance
# However, use this with caution if your smb.conf file contains nested
# "include" statements. See Debian bug #483187 for a case
# where using a master file is not a good idea.
#

#======================= Global Settings =======================

[global]

## Browsing/Identification ###

# Change this to the workgroup/NT-domain name your Samba server will part of
   workgroup = WORKGROUP

# server string is the equivalent of the NT Description field
   server string = %h server (Samba, Ubuntu)

# Windows Internet Name Serving Support Section:
# WINS Support - Tells the NMBD component of Samba to enable its WINS Server
#   wins support = no

# WINS Server - Tells the NMBD components of Samba to be a WINS Client
# Note: Samba can be either a WINS Server, or a WINS Client, but NOT both
;   wins server = w.x.y.z

# This will prevent nmbd to search for NetBIOS names through DNS.
   dns proxy = no

# What naming service and in what order should we use to resolve host names
# to IP addresses
;   name resolve order = lmhosts host wins bcast

#### Networking ####

# The specific set of interfaces / networks to bind to
# This can be either the interface name or an IP address/netmask;
# interface names are normally preferred
;   interfaces = 127.0.0.0/8 eth0

# Only bind to the named interfaces and/or networks; you must use the
# 'interfaces' option above to use this.
# It is recommended that you enable this feature if your Samba machine is
# not protected by a firewall or is a firewall itself.  However, this
# option cannot handle dynamic or non-broadcast interfaces correctly.
;   bind interfaces only = yes



#### Debugging/Accounting ####

# This tells Samba to use a separate log file for each machine
# that connects
   log file = /var/log/samba/log.%m

# Cap the size of the individual log files (in KiB).
   max log size = 1000

# If you want Samba to only log through syslog then set the following
# parameter to 'yes'.
#   syslog only = no

# We want Samba to log a minimum amount of information to syslog. Everything
# should go to /var/log/samba/log.{smbd,nmbd} instead. If you want to log
# through syslog you should set the following parameter to something higher.
   syslog = 0

# Do something sensible when Samba crashes: mail the admin a backtrace
   panic action = /usr/share/samba/panic-action %d


####### Authentication #######

# "security = user" is always a good idea. This will require a Unix account
# in this server for every user accessing the server. See
# /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html
# in the samba-doc package for details.
#   security = user

# You may wish to use password encryption.  See the section on
# 'encrypt passwords' in the smb.conf(5) manpage before enabling.
   encrypt passwords = true

# If you are using encrypted passwords, Samba will need to know what
# password database type you are using.  
   passdb backend = tdbsam

   obey pam restrictions = yes

# This boolean parameter controls whether Samba attempts to sync the Unix
# password with the SMB password when the encrypted SMB password in the
# passdb is changed.
   unix password sync = yes

# For Unix password sync to work on a Debian GNU/Linux system, the following
# parameters must be set (thanks to Ian Kahan <<kahan@informatik.tu-muenchen.de> for
# sending the correct chat script for the passwd program in Debian Sarge).
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .

# This boolean controls whether PAM will be used for password changes
# when requested by an SMB client instead of the program listed in
# 'passwd program'. The default is 'no'.
   pam password change = yes

# This option controls how unsuccessful authentication attempts are mapped
# to anonymous connections
   map to guest = bad user

########## Domains ###########

# Is this machine able to authenticate users. Both PDC and BDC
# must have this setting enabled. If you are the BDC you must
# change the 'domain master' setting to no
#
;   domain logons = yes
#
# The following setting only takes effect if 'domain logons' is set
# It specifies the location of the user's profile directory
# from the client point of view)
# The following required a [profiles] share to be setup on the
# samba server (see below)
;   logon path = \\%N\profiles\%U
# Another common choice is storing the profile in the user's home directory
# (this is Samba's default)
#   logon path = \\%N\%U\profile

# The following setting only takes effect if 'domain logons' is set
# It specifies the location of a user's home directory (from the client
# point of view)
;   logon drive = H:
#   logon home = \\%N\%U

# The following setting only takes effect if 'domain logons' is set
# It specifies the script to run during logon. The script must be stored
# in the [netlogon] share
# NOTE: Must be store in 'DOS' file format convention
;   logon script = logon.cmd

# This allows Unix users to be created on the domain controller via the SAMR
# RPC pipe.  The example command creates a user account with a disabled Unix
# password; please adapt to your needs
; add user script = /usr/sbin/adduser --quiet --disabled-password --gecos "" %u

# This allows machine accounts to be created on the domain controller via the
# SAMR RPC pipe.  
# The following assumes a "machines" group exists on the system
; add machine script  = /usr/sbin/useradd -g machines -c "%u machine account" -d /var/lib/samba -s /bin/false %u

# This allows Unix groups to be created on the domain controller via the SAMR
# RPC pipe.  
; add group script = /usr/sbin/addgroup --force-badname %g

########## Printing ##########

# If you want to automatically load your printer list rather
# than setting them up individually then you'll need this
#   load printers = yes

# lpr(ng) printing. You may wish to override the location of the
# printcap file
;   printing = bsd
;   printcap name = /etc/printcap

# CUPS printing.  See also the cupsaddsmb(8) manpage in the
# cupsys-client package.
;   printing = cups
;   printcap name = cups

############ Misc ############

# Using the following line enables you to customise your configuration
# on a per machine basis. The %m gets replaced with the netbios name
# of the machine that is connecting
;   include = /home/samba/etc/smb.conf.%m

# Most people will find that this option gives better performance.
# See smb.conf(5) and /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/speed.html
# for details
# You may want to add the following on a Linux system:
#         SO_RCVBUF=8192 SO_SNDBUF=8192
#   socket options = TCP_NODELAY

# The following parameter is useful only if you have the linpopup package
# installed. The samba maintainer and the linpopup maintainer are
# working to ease installation and configuration of linpopup and samba.
;   message command = /bin/sh -c '/usr/bin/linpopup "%f" "%m" %s; rm %s' &

# Domain Master specifies Samba to be the Domain Master Browser. If this
# machine will be configured as a BDC (a secondary logon server), you
# must set this to 'no'; otherwise, the default behavior is recommended.
#   domain master = auto

# Some defaults for winbind (make sure you're not using the ranges
# for something else.)
;   idmap uid = 10000-20000
;   idmap gid = 10000-20000
;   template shell = /bin/bash

# The following was the default behaviour in sarge,
# but samba upstream reverted the default because it might induce
# performance issues in large organizations.
# See Debian bug #368251 for some of the consequences of *not*
# having this setting and smb.conf(5) for details.
;   winbind enum groups = yes
;   winbind enum users = yes

# Setup usershare options to enable non-root users to share folders
# with the net usershare command.

# Maximum number of usershare. 0 (default) means that usershare is disabled.
;   usershare max shares = 100

# Allow users who've been granted usershare privileges to create
# public shares, not just authenticated ones
   usershare allow guests = yes

#======================= Share Definitions =======================

# Un-comment the following (and tweak the other settings below to suit)
# to enable the default home directory shares.  This will share each
# user's home directory as \\server\username
;[homes]
;   comment = Home Directories
;   browseable = no

# By default, the home directories are exported read-only. Change the
# next parameter to 'no' if you want to be able to write to them.
;   read only = yes

# File creation mask is set to 0700 for security reasons. If you want to
# create files with group=rw permissions, set next parameter to 0775.
;   create mask = 0700

# Directory creation mask is set to 0700 for security reasons. If you want to
# create dirs. with group=rw permissions, set next parameter to 0775.
;   directory mask = 0700

# By default, \\server\username shares can be connected to by anyone
# with access to the samba server.  Un-comment the following parameter
# to make sure that only "username" can connect to \\server\username
# This might need tweaking when using external authentication schemes
#   valid users = %S

# Un-comment the following and create the netlogon directory for Domain Logons
# (you need to configure Samba to act as a domain controller too.)
;[netlogon]
;   comment = Network Logon Service
;   path = /home/samba/netlogon
;   guest ok = yes
;   read only = yes
;   share modes = no

# Un-comment the following and create the profiles directory to store
# users profiles (see the "logon path" option above)
# (you need to configure Samba to act as a domain controller too.)
# The path below should be writable by all users so that their
# profile directory may be created the first time they log on
;[profiles]
;   comment = Users profiles
;   path = /home/samba/profiles
;   guest ok = no
;   browseable = no
;   create mask = 0600
;   directory mask = 0700

#[printers]
 #  comment = All Printers
 #  browseable = no
 #  path = /var/spool/samba
 #  printable = yes
 #  guest ok = no
 #  read only = yes
 #  create mask = 0700

# Windows clients look for this share name as a source of downloadable
# printer drivers
#[print$]
 #  comment = Printer Drivers
 #  path = /var/lib/samba/printers
 #  browseable = yes
 #  read only = yes
 #  guest ok = no
# Uncomment to allow remote administration of Windows print drivers.
# You may need to replace 'lpadmin' with the name of the group your
# admin users are members of.
# Please note that you also need to set appropriate Unix permissions
# to the drivers directory for these users to have write rights in it
;   write list = root, @lpadmin

# A sample share for sharing your CD-ROM with others.
[RetroVicio]
   comment = Samba server's RetroVicio
   read only = no
   locking = no
   path = /home/retro
   guest ok = yes
   create mask = 0777
   browseable = yes
   #hide dot files = yes
# The next two parameters show how to auto-mount a CD-ROM when the
# cdrom share is accesed. For this to work /etc/fstab must contain
# an entry like this:
#
#       /dev/scd0   /cdrom  iso9660 defaults,noauto,ro,user   0 0
#
# The CD-ROM gets unmounted automatically after the connection to the
#
# If you don't want to use auto-mounting/unmounting make sure the CD
# is mounted on /cdrom
#
;   preexec = /bin/mount /cdrom
;   postexec = /bin/umount /cdrom

I think this enough, do not remember if something else changed

Code: [Select]
[RetroVicio]
   comment = Samba server's RetroVicio
   read only = no
   locking = no
   path = /home/retro
   guest ok = yes
   create mask = 0777
   browseable = yes
   #hide dot files = yes


Quote
Hi VeS, it's nice to see you here! Smiley

Thanks Calamity when I have time to pour me some day everything you are doing, which in English I can hardly catch a few things.
Because you do not know what bitbytebit to do with git, no really it is, seems a sort of svn, right?

Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on January 25, 2011, 09:55:00 am
Hello, here I put the configuration advmenu.rc
To select the video mode you can play with this option will change to 640 1024 etc. ..
device_video_overlaysize 320

I can not remember if mame runs either directly or through switchres if so you'll have to configure emulator advmenu.rc as generic and remove the lines suck, remember to protect the file so you will not reinstate the configuration of mame, and that mame default if found includes it.

http://advancemame.sourceforge.net/doc-advmenu.html#4.1 (http://advancemame.sourceforge.net/doc-advmenu.html#4.1)

If I can watch tonight, if I have created advmenu.rc switchres configuradon with another hd.


Code: [Select]
config save_at_exit

device_color_bgr15 yes

device_color_bgr16 yes

device_color_bgr24 yes

device_color_bgr32 yes

device_color_bgr8 yes

device_color_palette8 yes

device_color_yuy2 yes

device_joystick none

device_keyboard auto

device_mouse none

device_sound sdl

device_video sdl

device_video_cursor auto

device_video_doublescan yes

device_video_fastchange no

device_video_interlace yes

device_video_output fullscreen

device_video_overlaysize 320

device_video_singlescan yes

difficulty none
display_brightness 1

display_gamma 1

display_orientation
display_restoreatexit yes

display_restoreatgame no

display_size 320

emulator "MAME" mame "/usr/games/mame"

emulator_roms "MAME" "/home/retro/mame/roms:/media/usb/roms"

emulator_flyers "MAME" "/home/retro/mame/flyers"

emulator_altss "MAME" "/home/retro/mame/snap"

emulator_cabinets "MAME" "/home/retro/mame/cabinets"

emulator_titles "MAME" "/home/retro/mame/titles"

emulator "ADvMAME" advmame "/usr/local/bin/advmame"

emulator_roms "ADvMAME" "/home/retro/mame/roms"

emulator_flyers "ADvMAME" "/home/retro/mame/flyers"

emulator_altss "ADvMAME" "/home/retro/mame/snap"

emulator_cabinets "ADvMAME" "/home/retro/mame/cabinets"

emulator_titles "ADvMAME" "/home/retro/mame/titles"

event_alpha no

event_assign up up or 8_pad

event_assign down down or 2_pad

event_assign left left or 4_pad

event_assign right right or 6_pad

event_assign enter enter or enter_pad or 1

event_assign esc esc or w

event_assign space space

event_assign home home

event_assign end end

event_assign pgup pgup

event_assign pgdn pgdn

event_assign del del

event_assign ins insert

event_assign shutdown 2 or lcontrol esc

event_assign mode tab or z

event_assign help f1

event_assign group f2

event_assign type f3

event_assign exclude f4

event_assign sort f5

event_assign setgroup f9

event_assign settype f10

event_assign runclone f12 or a

event_assign command f8

event_assign menu backquote or backslash

event_assign emulator f6 or s

event_assign rotate 0_pad

event_assign lock scrlock

event_assign preview space

event_mode fast

event_repeat 500 50

icon_space 43

idle_screensaver 60 10

idle_screensaver_preview snap

idle_start 0 0

include
input_hotkey yes

#Para no poder salir a consola

lock no

menu_base 3199
menu_rel 5
merge differential

misc_exit all

misc_quiet no

mode list_mixed
mode_skip
mouse_delta 100

preview snap
preview_default none

preview_default_cabinet yes

preview_default_flyer yes

preview_default_icon none

preview_default_marquee yes

preview_default_snap none

preview_default_title yes

preview_expand 1.15

sort parent
sound_background_begin none

sound_background_end none

sound_background_loop sloop.mp3

sound_background_loop_dir "mp3"

sound_background_start none

sound_background_stop none

sound_buffer 0.1

sound_foreground_begin default

sound_foreground_end default

sound_foreground_key default

sound_foreground_start sstart.mp3

sound_foreground_stop default

sound_latency 0.1

sound_samplerate 44100

sound_volume -3

ui_background
ui_bottombar yes

ui_clip single

ui_color help 000000 ffffff

ui_color help_tag 247ef0 ffffff

ui_color submenu_bar 247ef0 ffffff

ui_color submenu_item 000000 ffffff

ui_color submenu_item_select 000000 afffff

ui_color submenu_hidden 808080 ffffff

ui_color submenu_hidden_select 808080 afffff

ui_color menu_item 000000 ffffff

ui_color menu_hidden 808080 ffffff

ui_color menu_tag 247ef0 ffffff

ui_color menu_item_select 000000 afffff

ui_color menu_hidden_select 808080 afffff

ui_color menu_tag_select 247ef0 afffff

ui_color bar 000000 ffffff

ui_color bar_tag 247ef0 ffffff

ui_color bar_hidden 808080 ffffff

ui_color grid 247ef0 ffffff

ui_color backdrop 000000 808080

ui_color icon ffffff ffffff

ui_color cursor 808080 ffffff

ui_command_error Error running the command

ui_command_menu Command...

ui_console no

ui_exit none

ui_font auto

ui_fontsize auto

ui_game snap

ui_gamemsg "Cargando Juego.."

ui_help none

ui_menukey yes

ui_skipbottom 0

ui_skipleft 0

ui_skipright 0

ui_skiptop 0

ui_startup none

ui_topbar yes

ui_translucency 0.6

MAME/mode list_mixed

MAME/preview snap

mame/preview snap
mame/mode list_mixed
group_include "<undefined>"
group_include "Bad"
group_include "Good"
group_include "Very Good"
type_include "<undefined>"
type_include "Application"
type_include "Arcade"
type_include "Bet 'em Up"
type_include "Breakout"
type_include "Computer"
type_include "Console"
type_include "Fight"
type_include "Filler"
type_include "Flipper"
type_include "Gun"
type_include "Puzzle"
type_include "RPG"
type_include "Racing"
type_include "Shot 'em Up"
type_include "Sport"
emulator_include "MAME"
group "<undefined>"
group "Bad"
group "Good"
group "Very Good"
type "<undefined>"
type "Application"
type "Arcade"
type "Bet 'em Up"
type "Breakout"
type "Computer"
type "Console"
type "Fight"
type "Filler"
type "Flipper"
type "Gun"
type "Puzzle"
type "Racing"
type "RPG"
type "Shot 'em Up"
type "Sport"
emulator_attrib "MAME" missing exclude
emulator_attrib "MAME" clone exclude
emulator_attrib "MAME" bad exclude
emulator_attrib "MAME" vector include
emulator_attrib "MAME" vertical include
emulator_attrib "MAME" neogeo include
emulator_attrib "MAME" deco exclude
emulator_attrib "MAME" playchoice exclude
emulator_attrib "ADvMAME" missing exclude
emulator_attrib "ADvMAME" clone exclude
emulator_attrib "ADvMAME" bad exclude
emulator_attrib "ADvMAME" vector include
emulator_attrib "ADvMAME" vertical include
emulator_attrib "ADvMAME" neogeo include
emulator_attrib "ADvMAME" deco exclude
emulator_attrib "ADvMAME" playchoice exclude


Also I put here the smb.conf file if it's more like you


Code: [Select]
#
# Sample configuration file for the Samba suite for Debian GNU/Linux.
#
#
# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options most of which
# are not shown in this example
#
# Some options that are often worth tuning have been included as
# commented-out examples in this file.
#  - When such options are commented with ";", the proposed setting
#    differs from the default Samba behaviour
#  - When commented with "#", the proposed setting is the default
#    behaviour of Samba but the option is considered important
#    enough to be mentioned here
#
# NOTE: Whenever you modify this file you should run the command
# "testparm" to check that you have not made any basic syntactic
# errors.
# A well-established practice is to name the original file
# "smb.conf.master" and create the "real" config file with
# testparm -s smb.conf.master >smb.conf
# This minimizes the size of the really used smb.conf file
# which, according to the Samba Team, impacts performance
# However, use this with caution if your smb.conf file contains nested
# "include" statements. See Debian bug #483187 for a case
# where using a master file is not a good idea.
#

#======================= Global Settings =======================

[global]

## Browsing/Identification ###

# Change this to the workgroup/NT-domain name your Samba server will part of
   workgroup = WORKGROUP

# server string is the equivalent of the NT Description field
   server string = %h server (Samba, Ubuntu)

# Windows Internet Name Serving Support Section:
# WINS Support - Tells the NMBD component of Samba to enable its WINS Server
#   wins support = no

# WINS Server - Tells the NMBD components of Samba to be a WINS Client
# Note: Samba can be either a WINS Server, or a WINS Client, but NOT both
;   wins server = w.x.y.z

# This will prevent nmbd to search for NetBIOS names through DNS.
   dns proxy = no

# What naming service and in what order should we use to resolve host names
# to IP addresses
;   name resolve order = lmhosts host wins bcast

#### Networking ####

# The specific set of interfaces / networks to bind to
# This can be either the interface name or an IP address/netmask;
# interface names are normally preferred
;   interfaces = 127.0.0.0/8 eth0

# Only bind to the named interfaces and/or networks; you must use the
# 'interfaces' option above to use this.
# It is recommended that you enable this feature if your Samba machine is
# not protected by a firewall or is a firewall itself.  However, this
# option cannot handle dynamic or non-broadcast interfaces correctly.
;   bind interfaces only = yes



#### Debugging/Accounting ####

# This tells Samba to use a separate log file for each machine
# that connects
   log file = /var/log/samba/log.%m

# Cap the size of the individual log files (in KiB).
   max log size = 1000

# If you want Samba to only log through syslog then set the following
# parameter to 'yes'.
#   syslog only = no

# We want Samba to log a minimum amount of information to syslog. Everything
# should go to /var/log/samba/log.{smbd,nmbd} instead. If you want to log
# through syslog you should set the following parameter to something higher.
   syslog = 0

# Do something sensible when Samba crashes: mail the admin a backtrace
   panic action = /usr/share/samba/panic-action %d


####### Authentication #######

# "security = user" is always a good idea. This will require a Unix account
# in this server for every user accessing the server. See
# /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html
# in the samba-doc package for details.
#   security = user

# You may wish to use password encryption.  See the section on
# 'encrypt passwords' in the smb.conf(5) manpage before enabling.
   encrypt passwords = true

# If you are using encrypted passwords, Samba will need to know what
# password database type you are using.  
   passdb backend = tdbsam

   obey pam restrictions = yes

# This boolean parameter controls whether Samba attempts to sync the Unix
# password with the SMB password when the encrypted SMB password in the
# passdb is changed.
   unix password sync = yes

# For Unix password sync to work on a Debian GNU/Linux system, the following
# parameters must be set (thanks to Ian Kahan <<kahan@informatik.tu-muenchen.de> for
# sending the correct chat script for the passwd program in Debian Sarge).
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .

# This boolean controls whether PAM will be used for password changes
# when requested by an SMB client instead of the program listed in
# 'passwd program'. The default is 'no'.
   pam password change = yes

# This option controls how unsuccessful authentication attempts are mapped
# to anonymous connections
   map to guest = bad user

########## Domains ###########

# Is this machine able to authenticate users. Both PDC and BDC
# must have this setting enabled. If you are the BDC you must
# change the 'domain master' setting to no
#
;   domain logons = yes
#
# The following setting only takes effect if 'domain logons' is set
# It specifies the location of the user's profile directory
# from the client point of view)
# The following required a [profiles] share to be setup on the
# samba server (see below)
;   logon path = \\%N\profiles\%U
# Another common choice is storing the profile in the user's home directory
# (this is Samba's default)
#   logon path = \\%N\%U\profile

# The following setting only takes effect if 'domain logons' is set
# It specifies the location of a user's home directory (from the client
# point of view)
;   logon drive = H:
#   logon home = \\%N\%U

# The following setting only takes effect if 'domain logons' is set
# It specifies the script to run during logon. The script must be stored
# in the [netlogon] share
# NOTE: Must be store in 'DOS' file format convention
;   logon script = logon.cmd

# This allows Unix users to be created on the domain controller via the SAMR
# RPC pipe.  The example command creates a user account with a disabled Unix
# password; please adapt to your needs
; add user script = /usr/sbin/adduser --quiet --disabled-password --gecos "" %u

# This allows machine accounts to be created on the domain controller via the
# SAMR RPC pipe.  
# The following assumes a "machines" group exists on the system
; add machine script  = /usr/sbin/useradd -g machines -c "%u machine account" -d /var/lib/samba -s /bin/false %u

# This allows Unix groups to be created on the domain controller via the SAMR
# RPC pipe.  
; add group script = /usr/sbin/addgroup --force-badname %g

########## Printing ##########

# If you want to automatically load your printer list rather
# than setting them up individually then you'll need this
#   load printers = yes

# lpr(ng) printing. You may wish to override the location of the
# printcap file
;   printing = bsd
;   printcap name = /etc/printcap

# CUPS printing.  See also the cupsaddsmb(8) manpage in the
# cupsys-client package.
;   printing = cups
;   printcap name = cups

############ Misc ############

# Using the following line enables you to customise your configuration
# on a per machine basis. The %m gets replaced with the netbios name
# of the machine that is connecting
;   include = /home/samba/etc/smb.conf.%m

# Most people will find that this option gives better performance.
# See smb.conf(5) and /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/speed.html
# for details
# You may want to add the following on a Linux system:
#         SO_RCVBUF=8192 SO_SNDBUF=8192
#   socket options = TCP_NODELAY

# The following parameter is useful only if you have the linpopup package
# installed. The samba maintainer and the linpopup maintainer are
# working to ease installation and configuration of linpopup and samba.
;   message command = /bin/sh -c '/usr/bin/linpopup "%f" "%m" %s; rm %s' &

# Domain Master specifies Samba to be the Domain Master Browser. If this
# machine will be configured as a BDC (a secondary logon server), you
# must set this to 'no'; otherwise, the default behavior is recommended.
#   domain master = auto

# Some defaults for winbind (make sure you're not using the ranges
# for something else.)
;   idmap uid = 10000-20000
;   idmap gid = 10000-20000
;   template shell = /bin/bash

# The following was the default behaviour in sarge,
# but samba upstream reverted the default because it might induce
# performance issues in large organizations.
# See Debian bug #368251 for some of the consequences of *not*
# having this setting and smb.conf(5) for details.
;   winbind enum groups = yes
;   winbind enum users = yes

# Setup usershare options to enable non-root users to share folders
# with the net usershare command.

# Maximum number of usershare. 0 (default) means that usershare is disabled.
;   usershare max shares = 100

# Allow users who've been granted usershare privileges to create
# public shares, not just authenticated ones
   usershare allow guests = yes

#======================= Share Definitions =======================

# Un-comment the following (and tweak the other settings below to suit)
# to enable the default home directory shares.  This will share each
# user's home directory as \\server\username
;[homes]
;   comment = Home Directories
;   browseable = no

# By default, the home directories are exported read-only. Change the
# next parameter to 'no' if you want to be able to write to them.
;   read only = yes

# File creation mask is set to 0700 for security reasons. If you want to
# create files with group=rw permissions, set next parameter to 0775.
;   create mask = 0700

# Directory creation mask is set to 0700 for security reasons. If you want to
# create dirs. with group=rw permissions, set next parameter to 0775.
;   directory mask = 0700

# By default, \\server\username shares can be connected to by anyone
# with access to the samba server.  Un-comment the following parameter
# to make sure that only "username" can connect to \\server\username
# This might need tweaking when using external authentication schemes
#   valid users = %S

# Un-comment the following and create the netlogon directory for Domain Logons
# (you need to configure Samba to act as a domain controller too.)
;[netlogon]
;   comment = Network Logon Service
;   path = /home/samba/netlogon
;   guest ok = yes
;   read only = yes
;   share modes = no

# Un-comment the following and create the profiles directory to store
# users profiles (see the "logon path" option above)
# (you need to configure Samba to act as a domain controller too.)
# The path below should be writable by all users so that their
# profile directory may be created the first time they log on
;[profiles]
;   comment = Users profiles
;   path = /home/samba/profiles
;   guest ok = no
;   browseable = no
;   create mask = 0600
;   directory mask = 0700

#[printers]
 #  comment = All Printers
 #  browseable = no
 #  path = /var/spool/samba
 #  printable = yes
 #  guest ok = no
 #  read only = yes
 #  create mask = 0700

# Windows clients look for this share name as a source of downloadable
# printer drivers
#[print$]
 #  comment = Printer Drivers
 #  path = /var/lib/samba/printers
 #  browseable = yes
 #  read only = yes
 #  guest ok = no
# Uncomment to allow remote administration of Windows print drivers.
# You may need to replace 'lpadmin' with the name of the group your
# admin users are members of.
# Please note that you also need to set appropriate Unix permissions
# to the drivers directory for these users to have write rights in it
;   write list = root, @lpadmin

# A sample share for sharing your CD-ROM with others.
[RetroVicio]
   comment = Samba server's RetroVicio
   read only = no
   locking = no
   path = /home/retro
   guest ok = yes
   create mask = 0777
   browseable = yes
   #hide dot files = yes
# The next two parameters show how to auto-mount a CD-ROM when the
# cdrom share is accesed. For this to work /etc/fstab must contain
# an entry like this:
#
#       /dev/scd0   /cdrom  iso9660 defaults,noauto,ro,user   0 0
#
# The CD-ROM gets unmounted automatically after the connection to the
#
# If you don't want to use auto-mounting/unmounting make sure the CD
# is mounted on /cdrom
#
;   preexec = /bin/mount /cdrom
;   postexec = /bin/umount /cdrom

I think this enough, do not remember if something else changed

Code: [Select]
[RetroVicio]
   comment = Samba server's RetroVicio
   read only = no
   locking = no
   path = /home/retro
   guest ok = yes
   create mask = 0777
   browseable = yes
   #hide dot files = yes


Quote
Hi VeS, it's nice to see you here! Smiley

Thanks Calamity when I have time to pour me some day everything you are doing, which in English I can hardly catch a few things.
Because you do not know what bitbytebit to do with git, no really it is, seems a sort of svn, right?

I just remembered that you could create advmenu skin to make it more beautiful as this in this picture.

http://img402.imageshack.us/img402/3152/encabezadoa4e.jpg (http://img402.imageshack.us/img402/3152/encabezadoa4e.jpg)

http://img338.imageshack.us/img338/6136/skinplus.png (http://img338.imageshack.us/img338/6136/skinplus.png)

If like me get in touch with the creator for what we pass or create a new one



Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 25, 2011, 10:20:01 am
Thanks Ves, those will help a lot.  Good news is I have gotten a pretty basic but good setup of AdvanceMenu running last night that I already like better than wahcade :).  So that's good, it's quite amazing how simple yet nice it is, and very easy to setup.  I can use those configs of yours to help improve it even more now.  Also I have started working on getting samba enabled, it's on there so I'm just going to have it broadcast out shares for the home directory and /data/ or roms/snaps locations for now.  Will customize it more when I do some testing to allow it to hopefully let a person access it remotely to put roms on the system.  I'm still focusing on having the gdm run things but I'm having the config setup option with fvwm startup advmenu or run advmenu itself if a person chooses on startup/config.  Mainly because this new Linux DRM framebuffer isn't always stable and it's best to stay inside of X Windows since on some cards/systems the framebuffer actually breaks after X is started once.  Also hopefully it allows booting straight into advmenu, yet they can if using fvwm exit out of advmenu and then be able to do system administration from there easier (unless they choose to just use advmenu itself alone). 

I'm working on a new ISO image, updated quite a few things, new kernel version which I'm testing and these changes with advmenu.  Will hopefully have it up today or tomorrow.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 25, 2011, 11:31:56 am
Thanks Ves, those will help a lot.  Good news is I have gotten a pretty basic but good setup of AdvanceMenu running last night that I already like better than wahcade :).  So that's good, it's quite amazing how simple yet nice it is, and very easy to setup.  I can use those configs of yours to help improve it even more now.  Also I have started working on getting samba enabled, it's on there so I'm just going to have it broadcast out shares for the home directory and /data/ or roms/snaps locations for now.  Will customize it more when I do some testing to allow it to hopefully let a person access it remotely to put roms on the system.  I'm still focusing on having the gdm run things but I'm having the config setup option with fvwm startup advmenu or run advmenu itself if a person chooses on startup/config.  Mainly because this new Linux DRM framebuffer isn't always stable and it's best to stay inside of X Windows since on some cards/systems the framebuffer actually breaks after X is started once.  Also hopefully it allows booting straight into advmenu, yet they can if using fvwm exit out of advmenu and then be able to do system administration from there easier (unless they choose to just use advmenu itself alone).  

I'm working on a new ISO image, updated quite a few things, new kernel version which I'm testing and these changes with advmenu.  Will hopefully have it up today or tomorrow.

 Nice, i like advancemame options, much simple as wahcade setup ..

 Regarding to rom directory, why not put them directly on $home of arcade user ?

 Correct me if i'm wrong but this distribution is mainly intended to be installed on arcade cabs so by definition only one user will be used.

 And in the setup process i've only seen a partition choice for $home and /root ..
so if you want to keep the current rom directory layout, it may be cool to ask for a /rom partition instead of using /root or $HOME who may be reinstalled.

 For exemple here is my smb.conf (NO authentification at all, rights are for user arcade, mame stuff is IN home directory)
Code: [Select]
[global]
workgroup = ARCADE
server string = %h server
dns proxy = no
security=share

[ARCADE]
create mask = 0770
writable = yes
directory mode = 0770
path = /home/arcade
public = yes
force user = arcade
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 25, 2011, 11:44:05 am
Thanks Ves, those will help a lot.  Good news is I have gotten a pretty basic but good setup of AdvanceMenu running last night that I already like better than wahcade :).  So that's good, it's quite amazing how simple yet nice it is, and very easy to setup.  I can use those configs of yours to help improve it even more now.  Also I have started working on getting samba enabled, it's on there so I'm just going to have it broadcast out shares for the home directory and /data/ or roms/snaps locations for now.  Will customize it more when I do some testing to allow it to hopefully let a person access it remotely to put roms on the system.  I'm still focusing on having the gdm run things but I'm having the config setup option with fvwm startup advmenu or run advmenu itself if a person chooses on startup/config.  Mainly because this new Linux DRM framebuffer isn't always stable and it's best to stay inside of X Windows since on some cards/systems the framebuffer actually breaks after X is started once.  Also hopefully it allows booting straight into advmenu, yet they can if using fvwm exit out of advmenu and then be able to do system administration from there easier (unless they choose to just use advmenu itself alone).  

I'm working on a new ISO image, updated quite a few things, new kernel version which I'm testing and these changes with advmenu.  Will hopefully have it up today or tomorrow.

 Nice, i like advancemame options, much simple as wahcade setup ..

 Regarding to rom directory, why not put them directly on $home of arcade user ?

 Correct me if i'm wrong but this distribution is mainly intended to be installed on arcade cabs so by definition only one user will be used.

 And in the setup process i've only seen a partition choice for $home and /root ..
so if you want to keep the current rom directory layout, it may be cool to ask for a /rom partition instead of using /root or $HOME who may be reinstalled.

 For exemple here is my smb.conf (NO authentification at all, rights are for user arcade, mame stuff is IN home directory)
Code: [Select]
[global]
workgroup = ARCADE
server string = %h server
dns proxy = no
security=share

[ARCADE]
create mask = 0770
writable = yes
directory mode = 0770
path = /home/arcade
public = yes
force user = arcade

Thanks, I'm actually just about done having it so that the home directory and /data/ or roms/snaps directory are now pretty much like that, actually the force user part above helped complete the allowance to login with out passwords. 

Basically it'll be just like your saying, except it'll have the roms/snaps in /data/ by default although now it'll be possible for a user to just edit the advance menu config and choose anywhere they want.  They should be able to do all that from the Samba sharing now too, so it's looking quite nice and seems to work really well now in testing.  There's probably going to be plenty of extra things to smooth the edges of it with, but overall it's very much like you and Ves have setup.  I'm looking at the /data/ drive as being possible to be removable usb media so that's why it's separate from /home and /home to of course be possibly the same way, so it give the most flexible options hopefully, and /data/ and /home/ can be the same drive or with a little advance menu changing /data/ can be totally ignored and just use /home/  for stuff.

Yeah I'm amazed I didn't realize Advanced Menu was so great, I've been living in the dark it seems with WahCade :/.  WahCade is nice, but of course anything in C is going to be much more efficient and it's just amazing how flexible and easy to run the Advance Menu is, the Python programming of WahCade really scares me :) (surprisingly I can do about anything in C, and absolutely *nothing* in Python, go figure).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 25, 2011, 11:59:36 am
bitbytebit,

Have you managed to setup AdvMenu for launching Switchres while still showing the rom's full name on the left column? I can only see the bare zip name, not the real long name here.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 25, 2011, 12:06:53 pm
bitbytebit,

Have you managed to setup AdvMenu for launching Switchres while still showing the rom's full name on the left column? I can only see the bare zip name, not the real long name here.

Yep, mine shows the full rom name.  My config for switchres looks like this...
Code: [Select]
emulator "mame" sdlmame "switchres" ""

That seems to do it for me, was amazed actually on how painless that was to setup and seems to like switchres just fine as a replacement for mame. 

I'll have this new ISO image of the LiveCD hopefully later today, so that'll have advmenu able to be used.



Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 25, 2011, 12:37:04 pm
bitbytebit,

Have you managed to setup AdvMenu for launching Switchres while still showing the rom's full name on the left column? I can only see the bare zip name, not the real long name here.

Yep, mine shows the full rom name.  My config for switchres looks like this...
Code: [Select]
emulator "mame" sdlmame "switchres" ""

That seems to do it for me, was amazed actually on how painless that was to setup and seems to like switchres just fine as a replacement for mame. 

I'll have this new ISO image of the LiveCD hopefully later today, so that'll have advmenu able to be used.


Ah that's great!

Just one thing, AdvMenu tries tro retrieve mame.xml from Mame executable, so it would be nice to have Switchres accepting the -listxml param so AdvMenu is happy with it (don't know if it's already done).



Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 25, 2011, 12:46:24 pm
bitbytebit,

Have you managed to setup AdvMenu for launching Switchres while still showing the rom's full name on the left column? I can only see the bare zip name, not the real long name here.

Yep, mine shows the full rom name.  My config for switchres looks like this...
Code: [Select]
emulator "mame" sdlmame "switchres" ""

That seems to do it for me, was amazed actually on how painless that was to setup and seems to like switchres just fine as a replacement for mame. 

I'll have this new ISO image of the LiveCD hopefully later today, so that'll have advmenu able to be used.


Ah that's great!

Just one thing, AdvMenu tries tro retrieve mame.xml from Mame executable, so it would be nice to have Switchres accepting the -listxml param so AdvMenu is happy with it (don't know if it's already done).





Yep :) WahCade did the same thing and basically if switchres is given only arguments that fit mame, it passes them straight to mame instead.  So it should work for frontends that think it is mame that way.  I have it creating the xml file and seems to be really nice.  Next step is to figure out how to fit all the different emulators into the config using switchres, right now switchres does that with...

switchres <system_name> --emulator <executable> --rom <romfile>

Basically taking mess system names, like n64, and so I need to figure out how to get the --rom <romfile> to work on that but still for some emulators pass --args <string of args> at the end?  Other option is maybe end the string of args with -- or --argend I guess and then the --rom at the end of the command line might pick up what advmenu passes it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 25, 2011, 04:08:57 pm
Yep :) WahCade did the same thing and basically if switchres is given only arguments that fit mame, it passes them straight to mame instead.  So it should work for frontends that think it is mame that way.  I have it creating the xml file and seems to be really nice.  Next step is to figure out how to fit all the different emulators into the config using switchres, right now switchres does that with...

switchres <system_name> --emulator <executable> --rom <romfile>

Basically taking mess system names, like n64, and so I need to figure out how to get the --rom <romfile> to work on that but still for some emulators pass --args <string of args> at the end?  Other option is maybe end the string of args with -- or --argend I guess and then the --rom at the end of the command line might pick up what advmenu passes it.

Good to know that, I'll test it in Windows.

These links are from Nixie, the creator of Winmodelines, have a lot of useful information for setting up different emulators:

http://geocities.ws/podernixie/htpc/modeline-en.html (http://geocities.ws/podernixie/htpc/modeline-en.html)
http://geocities.ws/podernixie/htpc/modes-en.html (http://geocities.ws/podernixie/htpc/modes-en.html)

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 25, 2011, 04:59:29 pm
Yep :) WahCade did the same thing and basically if switchres is given only arguments that fit mame, it passes them straight to mame instead.  So it should work for frontends that think it is mame that way.  I have it creating the xml file and seems to be really nice.  Next step is to figure out how to fit all the different emulators into the config using switchres, right now switchres does that with...

switchres <system_name> --emulator <executable> --rom <romfile>

Basically taking mess system names, like n64, and so I need to figure out how to get the --rom <romfile> to work on that but still for some emulators pass --args <string of args> at the end?  Other option is maybe end the string of args with -- or --argend I guess and then the --rom at the end of the command line might pick up what advmenu passes it.

Good to know that, I'll test it in Windows.

These links are from Nixie, the creator of Winmodelines, have a lot of useful information for setting up different emulators:

http://geocities.ws/podernixie/htpc/modeline-en.html (http://geocities.ws/podernixie/htpc/modeline-en.html)
http://geocities.ws/podernixie/htpc/modes-en.html (http://geocities.ws/podernixie/htpc/modes-en.html)



Ah I found a bug, or the bug, that was always giving me issues launching the other emulators with switchres.  Worked on most but wasn't perfect and some hung.  Turns out I wasn't checking and only running the emulator -h arg if it was mame, otherwise that explains why the NES ones would pop up GUI screens :).  I've gotten them all running now full screen from advance Menu and working pretty nice, amazing because in Wahcade that was hard and it always was hard to recreate.  Now I know I don't have to do all that work again because Advance Menu is a basic single config file setup.

I'm building the ISO's now, and will upload soon, and replace the switchres too in Windows to fix that bug. 

So basically now I've got it where you can access through the SMB shares from windows to the home and /data/ directories, all the emulators working from AdvanceMenu, plus it seems a lot more seamless now using fvwm since it will launch advmenu directly on startup (but still have a Window manager which is important to have the proper window managing functions of the application and also to exit out to for administration tasks).  Also I have the newest 2.6.38-rc2 Linux kernel release with my 15khz patch reworked so now it is probably better too for those people wanting to hook up an extra display LCD for setting things up, any other outputs should be normal again like they were originally before I hacked the patch more than it needed.  Of course with my upload speeds may be a day before the ISO's are up :/, so I'm making sure they are as best I can check before starting the upload so to keep the uploads at a minimum.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 25, 2011, 05:52:35 pm
Good news! That new iso will be a big step forward for sure, at least will make things easier.

I'm thinking is some cases we are going to need more info than the one provided by Mess. For instance, many console emulators use more than a resolution. Sometimes both PAL/NTSC modes are needed. One possibility could be grabbing some info from the rom name itself "(J)" "(U)" "(E)" to make decisions. Anyway it seems it could be useful at some moment to be able to create more than one video mode before launching a game, for some emulators that are capable of switching modes or even CabMame with -changeres on. In fact I think I've found the issue with some Mame games (segac2.c), Mame is trying to switch from 256x224 to 320x224 (the actual machine should switch modes) but as the first  is the only one reported by Mame, we use it as the -resolution param, and that seems to be preventing -changeres to work. If run without params, it's actually switching modes and the game is not chopped any more. I need to have a look. So for these cases where Mame/Mess info is incomplete, I can't figure out how to deal with unless we have some kind of help from an external file with patches/info.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 25, 2011, 10:59:44 pm
The 32bit ISO is uploaded, and the 64bit one should be there in a few hours...
 
Version 1.311-e925891
http://sourceforge.net/projects/groovyarcade/files/LiveCD/ (http://sourceforge.net/projects/groovyarcade/files/LiveCD/)

If you have a previous created home directory, you may want to let it redo that, since there's a lot of config files for advmenu and also the emulators which have changed.  I still need to figure out the way I had setup the input options for a few of the emulators before to match mame, mainly mupen64plus and gens.  Also gens probably can't do true resolution full screen, it seems to be one of those emulators either lacking that or it's really a trick to setup.  I also see tearing on the SNES zsnes emulator, but otherwise it seems to be  good.  Everything should be accessible by samba now too in the GROOVY workgroup as GroovyArcade with ROM and HOME shares.  picking fvwm as the window manager is probably your best bet at really having it just go straight into the frontend for advmenu.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Haggar on January 26, 2011, 04:49:21 am
Mame settings I'll use (I hope to try it this evening at home): ddraw, nohwstretch, triplebuffer, nothrottle, soundsync
Thanks.

ddraw, nohwstretch, syncrefresh, notriplebuffer, nothrottle, soundsync

Try syncrefresh instead of triplebuffer, the purpose is to check if syncrefresh actually removes input lag compared to triplebuffer or if it's a myth:
I've tried it quickly and it seems very good! No lag and no audio hiccups!

To activate soundsync I have to add "soundsync   1" into mame.ini, right?

This evening I'll try it in depth.
Is there any other useful test I can do?

Thanks

Oh that's great! So you mean it's better that way (notriplebuffer) than with triplebuffer on, less lag, isn't it? You could test with/without triplebuffer to see if you actually notice a difference with your spinner, so we make sure triplebuffer (page flipping) is actually the problem.
For what I've seen, soundsync is automatically set on, you shouldn't need to add it in Mame.ini


Test done.

NO Syncrefresh + Triple buffer => heavy lag
Syncrefresh + Triple buffer => little lag
Syncrefresh + NO Triple buffer => little lag
Throttle + NO Triple buffer + NO Syncrefresh  => NO lag but scrolling problems

Little lag => same lag I get with "normal" mame versions with "NO Triplebuffer & syncrefresh".

Using v-sync instead of syncrefresh I get same results.

The great thing is that I can run games at 108% with perfect sound (I've tryed r-type @60Hz).

To amplify lag problems you can use a 50Hz resolution with Arkanoid. Lag it's noticeable also with a mouse.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 26, 2011, 05:28:54 am
Test done.

NO Syncrefresh + Triple buffer => heavy lag
Syncrefresh + Triple buffer => little lag
Syncrefresh + NO Triple buffer => little lag
Throttle + NO Triple buffer + NO Syncrefresh  => NO lag but scrolling problems

Using v-sync instead of syncrefresh I get same results.

The great thing is that I can run games at 108% with perfect sound (I've tryed r-type @60Hz).

To amplify lag problems you can use a 50Hz resolution with Arkanoid. Lag it's noticeable also with a mouse.

Haggar, thank you very much for the tests! So the myth is confirmed, triple buffer produces more lag than syncrefresh. But there's still a residual lag there that is missing with normal throttle without syncrefresh, very interesting.

This is interesting for this reason: both methods (syncrefresh and throttle) need to wait, but it seems that throttle allows the input events to be processed while waiting, and syncrefresh somehow blocks the input for an instant, so input events are queued until we exit wait. One would think it would be imposible to notice that but it seems it actually affects gameplay.

Good news are that after all, both methods are simple wait loops so we could manage to get the same lagless behaviour for syncrefresh at least in theory. Thanks for pointing that Arkanoid 50Hz test, I'll try it.

Quote
Little lag => same lag I get with "normal" mame versions with "NO Triplebuffer & syncrefresh".

Yes, actually must be the same as the only change is that now you can disable throttle and still allow syncrefresh (to avois hiccups), while with "normal" Mame that would make it run fullspeed.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Haggar on January 26, 2011, 06:24:35 am
Good news are that after all, both methods are simple wait loops so we could manage to get the same lagless behaviour for syncrefresh at least in theory.
This would be great!

Thanks for pointing that Arkanoid 50Hz test, I'll try it.
You are welcome. If you want to try the same method (without spinner), i've noticed heavy lag also on Galaga @50Hz. I hope that you can confirm my feels.

Quote
Little lag => same lag I get with "normal" mame versions with "NO Triplebuffer & syncrefresh".

Yes, actually must be the same as the only change is that now you can disable throttle and still allow syncrefresh (to avois hiccups), while with "normal" Mame that would make it run fullspeed.
Yeah, this is a wonderful thing.
Thank you!! :)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on January 26, 2011, 09:50:19 am
Hello bitbytebit, I can not download the new version, I've tried from different places and always low iso with a size of 400 to 600 kb, you know if sourceforge problem or your file?

Because iso grown so much that you included?
Another thing I do not know if you will have already been made would be the usbmount, putting advmenu mame and a second path and snap roms, it would be easier for many people, one would have to put a usb and snap roms folder.



Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 26, 2011, 10:20:05 am
Hello bitbytebit, I can not download the new version, I've tried from different places and always low iso with a size of 400 to 600 kb, you know if sourceforge problem or your file?

Because iso grown so much that you included?
Another thing I do not know if you will have already been made would be the usbmount, putting advmenu mame and a second path and snap roms, it would be easier for many people, one would have to put a usb and snap roms folder.



Thanks.

Ah it's an issue with the sourceforge site, I've opened a trouble ticket with them, hopefully I don't have to re-upload and they'll fix it.  I'll let you know when they work again.

The /data/ directory essentially can be a USB drive, it can be anything mountable like that.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 26, 2011, 11:19:25 am
Hello bitbytebit, I can not download the new version, I've tried from different places and always low iso with a size of 400 to 600 kb, you know if sourceforge problem or your file?

Because iso grown so much that you included?
Another thing I do not know if you will have already been made would be the usbmount, putting advmenu mame and a second path and snap roms, it would be easier for many people, one would have to put a usb and snap roms folder.



Thanks.

Ah it's an issue with the sourceforge site, I've opened a trouble ticket with them, hopefully I don't have to re-upload and they'll fix it.  I'll let you know when they work again.

The /data/ directory essentially can be a USB drive, it can be anything mountable like that.

 I hope they will fix it quickly
i really want to test your new kernel with my "Anti-Linux Laptop" and i'ts afwull rs690 ati card (no sync or out of sync even in ubuntu livecd on a standard lcd monitor)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 26, 2011, 12:13:51 pm
Hello bitbytebit, I can not download the new version, I've tried from different places and always low iso with a size of 400 to 600 kb, you know if sourceforge problem or your file?

Because iso grown so much that you included?
Another thing I do not know if you will have already been made would be the usbmount, putting advmenu mame and a second path and snap roms, it would be easier for many people, one would have to put a usb and snap roms folder.



Thanks.

Ah it's an issue with the sourceforge site, I've opened a trouble ticket with them, hopefully I don't have to re-upload and they'll fix it.  I'll let you know when they work again.

The /data/ directory essentially can be a USB drive, it can be anything mountable like that.

 I hope they will fix it quickly
i really want to test your new kernel with my "Anti-Linux Laptop" and i'ts afwull rs690 ati card (no sync or out of sync even in ubuntu livecd on a standard lcd monitor)

Yeah I'm getting a new place to host the files from the place I have doing my email now, so will have a new download site here in a bit hopefully, guessing it'll be a few hours for them to setup then I'll start uploading there (and that may be a few more hours, but hopefully this time the files will work afterwards and I won't have to do it again). 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 26, 2011, 02:17:12 pm
hehe ...

I've got a question regarding the display management ...

 Do you rely on kms for make xorg work at 15khz or can it be desactivated ?

 I ask this because it seems that kms is the culprit for my out of sync on my damn laptop.

 If Xorg can work without kms it will permit me to use more driver options to try to solve my problem.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 26, 2011, 02:41:30 pm
hehe ...

I've got a question regarding the display management ...

 Do you rely on kms for make xorg work at 15khz or can it be desactivated ?

 I ask this because it seems that kms is the culprit for my out of sync on my damn laptop.

 If Xorg can work without kms it will permit me to use more driver options to try to solve my problem.
For the console support, yes it's the KMS part that allows that, it can be disabled through a command line to the kernel.  I think it's adding radeon.modeset=0 that would disable it.  I'm not sure what that will fully do on this setup but definitely interesting to try.  I do know though it'll not allow vsync to work, that only works with KMS unfortunately and also the Xorg userspace driver for the radeon is being depreciated and so they are trying to move everything newer to KMS now.  It's interesting, the main thing KMS does is work directly with the radeon Atom BIOS on the radeon, so essentially really uses the card GPU instead of the older ways they sort of hacked at the card through the X driver in userspace.  So this is an rs690 ATI card, I'd be interested in more details on it lik lspci -v output, Xorg.0.log files from it working / not working, dmesg logs of what it says about it for the drm messages.  Seems like it in theory should work, but then again KMS does have some oddities I've seen with certain ATI cards still like this x850 crossfire one I have seems to not like KMS (really doesn't like anything, I don't even use it and wonder if it even would work in Windows since it has the freaky breakout cable requirement that I don't have and no one sells anymore).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 26, 2011, 03:07:44 pm
hehe ...

I've got a question regarding the display management ...

 Do you rely on kms for make xorg work at 15khz or can it be desactivated ?

 I ask this because it seems that kms is the culprit for my out of sync on my damn laptop.

 If Xorg can work without kms it will permit me to use more driver options to try to solve my problem.
For the console support, yes it's the KMS part that allows that, it can be disabled through a command line to the kernel.  I think it's adding radeon.modeset=0 that would disable it.  I'm not sure what that will fully do on this setup but definitely interesting to try.  I do know though it'll not allow vsync to work, that only works with KMS unfortunately and also the Xorg userspace driver for the radeon is being depreciated and so they are trying to move everything newer to KMS now.  It's interesting, the main thing KMS does is work directly with the radeon Atom BIOS on the radeon, so essentially really uses the card GPU instead of the older ways they sort of hacked at the card through the X driver in userspace.  So this is an rs690 ATI card, I'd be interested in more details on it lik lspci -v output, Xorg.0.log files from it working / not working, dmesg logs of what it says about it for the drm messages.  Seems like it in theory should work, but then again KMS does have some oddities I've seen with certain ATI cards still like this x850 crossfire one I have seems to not like KMS (really doesn't like anything, I don't even use it and wonder if it even would work in Windows since it has the freaky breakout cable requirement that I don't have and no one sells anymore).

 I will check tomorrow without KMS but if i remember Xorg was out of sync too, it seems that it may be a "hardware feature" from Toshiba ^^

 For the cable breakout .... a vga to scart homemade did the job (it works under windows so i hope that the cable is not the culprit regarding to this out of sync problem)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 26, 2011, 05:28:17 pm
All the files are moving to http://mario.groovy.org/GroovyArcade/ (http://mario.groovy.org/GroovyArcade/) and all are uploaded (new version of Switchres is up) except the ISO images which are uploading now and should be there in a few hours hopefully.  Sourceforge is being weird, I can't even access the ssh/sftp there now, I guess they did some upgrade a few days ago and I am guessing that is what caused all the issues.  Hopefully now the files when uploaded will all be downloadable and not the first 128k or so :/.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 26, 2011, 06:25:25 pm
I'm testing this new patch to see if it helps reducing input lag while fixing the multithreading + vsync issue.

Code: [Select]
diff -Nru a/src/osd/windows/drawdd.c b/src/osd/windows/drawdd.c
--- a/src/osd/windows/drawdd.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/drawdd.c 2011-01-26 23:04:27.000000000 +0100
@@ -457,7 +457,7 @@
  if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X unlocking blit surface\n", (int)result);
 
  // sync to VBLANK
- if ((video_config.waitvsync || video_config.syncrefresh) && window->machine->video().throttled() && (!window->fullscreen || dd->back == NULL))
+ if ((video_config.waitvsync || video_config.syncrefresh) && (!window->fullscreen || dd->back == NULL))
  {
  result = IDirectDraw7_WaitForVerticalBlank(dd->ddraw, DDWAITVB_BLOCKBEGIN, NULL);
  if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X waiting for VBLANK\n", (int)result);
diff -Nru a/src/osd/windows/window.c b/src/osd/windows/window.c
--- a/src/osd/windows/window.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/window.c 2011-01-26 23:04:27.000000000 +0100
@@ -775,7 +775,15 @@
  last_update_time = timeGetTime();
  mtlog_add("winwindow_video_window_update: PostMessage start");
  if (multithreading_enabled)
- PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ {
+ if ((video_config.waitvsync || video_config.syncrefresh) && video_config.mode != VIDEO_MODE_GDI)
+ {
+ window->primlist = primlist;
+ draw_video_contents(window, NULL, FALSE);
+ }
+ else
+ PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ }
  else
  SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
  mtlog_add("winwindow_video_window_update: PostMessage end");

It is intended to be run with syncrefresh, nothrottle, notriplebuffer, multithreading.

Basically it tries to prove if doing the blit in the main thread helps at all to reduce input lag by leaving the window thread free to process input events. So in theory this should be the same that only using throttle (from lag point of view).

I'm testing it here and well... it feels good but not sure if it makes any difference. Tomorrow I'll upload a binary and hopefully your more experienced eyes can judge.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 26, 2011, 11:34:40 pm
All the files are moving to http://mario.groovy.org/GroovyArcade/ (http://mario.groovy.org/GroovyArcade/) and all are uploaded (new version of Switchres is up) except the ISO images which are uploading now and should be there in a few hours hopefully.  Sourceforge is being weird, I can't even access the ssh/sftp there now, I guess they did some upgrade a few days ago and I am guessing that is what caused all the issues.  Hopefully now the files when uploaded will all be downloadable and not the first 128k or so :/.
These are all uploaded to the new site now, all should be back to normal.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 27, 2011, 01:24:52 pm
Thanks

 i trying it now, it's really better for me to download from this new mirror because i've got 2 really slowwww connections in load balancing mode, sourceforge was awfull , no resume, no segmented downloads :/


 I've seen that World Rally seems free, do you think that you can include it  = http://www.gaelco.com/english/pages/hablando/frhablan.htm (http://www.gaelco.com/english/pages/hablando/frhablan.htm)  (ok, it's not really a new feature but it could be cool ^^)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 27, 2011, 01:34:44 pm
Thanks

 i trying it now, it's really better for me to download from this new mirror because i've got 2 really slowwww connections in load balancing mode, sourceforge was awfull , no resume, no segmented downloads :/


 I've seen that World Rally seems free, do you think that you can include it  = http://www.gaelco.com/english/pages/hablando/frhablan.htm (http://www.gaelco.com/english/pages/hablando/frhablan.htm)  (ok, it's not really a new feature but it could be cool ^^)

Sure, I put wrally.zip from their website in the roms folder so will be on the future ISO images. 

Yeah I think uploading to the new website even seems better to me, didn't break the connection and was more consistent speedwise.  I used the same place I have my domain hosted from, was cheap and unlimited bandwidth with 10Gig for a four dollars a month.  Can't beat that, especially when it is a lot nicer service now that's guaranteed.   Sourceforge GIT is good, still working, but currently I still can't upload to the sourceforge site and they are still busy trying to fix things.  I guess the actual issue was they had their servers hacked/exploited and so they have everything halfway taken down and are trying to figure things out.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 27, 2011, 01:41:09 pm
Cool for wrally

 Sadly, the new kernel didn't solve my "Toshiba bug" .... it's really disturbing to see that windows can do something that linux can't ....

 I wonder if you have modified grub or you use standard functionnality for boot in 15khz and if yes, where is the modified source code (if you provide it of course), juste for see if there is any options regarding the RS690 .

 Thanks for all
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 27, 2011, 01:46:06 pm
Cool for wrally

 Sadly, the new kernel didn't solve my "Toshiba bug" .... it's really disturbing to see that windows can do something that linux can't ....

 I wonder if you have modified grub or you use standard functionnality for boot in 15khz and if yes, where is the modified source code (if you provide it of course), juste for see if there is any options regarding the RS690 .

 Thanks for all

Actually grub isn't patched, but the linux kernel is and on the GIT repository I have the entire patches and files to build the actual ISO/Linux system from scratch.  I think you might be in luck soon, seems they recently submitted a patch in the Linux kernel from the AMD guy to fix your chipset...

http://www.spinics.net/lists/dri-devel/msg06906.html (http://www.spinics.net/lists/dri-devel/msg06906.html)

It's a hope at least, and seems really interesting that they are saying how your chipset specifically is picky about the clock references and pll dividers.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 27, 2011, 02:00:08 pm
I've uploaded a Mame 0.141u1 + CabMame + Groovy Arcade + Test Input hacks (the patch I posted above). I would appreciate that Haggar or some of the other guys tested this one to see if it actually helps reducing input lag. The correct options for this test are: syncrefresh, nothrottle, notriplebuffer, multithreading

http://www.megaupload.com/?d=XSGPDLAQ (http://www.megaupload.com/?d=XSGPDLAQ)

It should be compared against:

- Itself, with nosyncrefresh, throttle
- Current CabMame binary with latest patches, using the same options (syncrefresh, nothrottle, notriplebuffer, multithreading)

In case it helped (too good to be true) we could add it to other patches (I've tried to build 0141u1.diff + groovyarcade_0141u1.diff but I gives some errors when applying patches).

EDIT: I managed to build it with all the patches on.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 27, 2011, 02:23:42 pm
In case it helped (too good to be true) we could add it to other patches (I've tried to build 0141u1.diff + groovyarcade_0141u1.diff but I gives some errors when applying patches).


Did you apply the hiscore one before the groovyarcade one?  That might be the problem with the patch, or else maybe the -p option needs to be different.  Also I'm thinking perhaps it's a whitespace/end of line issue since I'm creating them in Linux so they don't have the ^M windows stuff at the ends.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 27, 2011, 02:56:21 pm
Wouhouuuu..

 It's nice to see that i'm not alone with this problem, it would be really great if this damned laptop could work with your distro  :P
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 27, 2011, 03:05:32 pm
Did you apply the hiscore one before the groovyarcade one?  That might be the problem with the patch, or else maybe the -p option needs to be different.  Also I'm thinking perhaps it's a whitespace/end of line issue since I'm creating them in Linux so they don't have the ^M windows stuff at the ends.

No, I didn't apply the hiscore one, must be that, I'll try again.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 27, 2011, 05:44:20 pm
Wouhouuuu..

 It's nice to see that i'm not alone with this problem, it would be really great if this damned laptop could work with your distro  :P
I'll build a test ISO using that patch, should have it up later tonight or tomorrow, definitely interesting to try it and see if it fixes your card too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on January 27, 2011, 06:24:03 pm
Hi, I installed the new version, the tests are installation, configuration and testing some games.

Installation, it is the same as before with the file grub.conf, fstab and files are in /

You could save somewhere in the livecd, several configuration files fstab and grub.conf to when installing, copy the file with the correct user unit.

fstab-sda1
fstab-sdb1
etc. ..
sda1 grub-......

Not copied. Xclients in /home/arcade, with the error of not loading automatically advmenu etc ....

I think that is a very important point to be repaired, so the end user does not have problems.


That is the folder /data_ro? since it is not created when you install, but if symbolic links inside /data/

Because mount /dev/sd .. in /home/arcade in fstab and in live?


Are really needed, hidden files / ? or only have been created to mount /dev/sd ... in /home/arcade??


With regard to the games I've tried going really well (toki, Rygar, wonderboy etc ...), but I'm noticing the rise and fall of sound among other plays, including what I have seen using a advmenu sound, which if you put a normal sound when you load a game this is a lot higher, I tried a little ossmixed but still remains the same, I'll have to check more thoroughly.

I noticed that in some vertical games (those who do not go pantallacompleta) if you take away the option of fulls the game is stretched across the screen, but not about all that because it?
There are also games that you can not read the info on mame for errors when loading graphics, is to change the resolution?

Acpi now works fine.




fstab
Code: [Select]
/dev/sda1 /               ext4            noatime 0 1
shm /dev/shm tmpfs nodev,nosuid,noexec     0 0

/dev/sda1 /home/arcade ext4 rw 0 2
/dev/sda2 none swap sw 0 0

grub.conf
Code: [Select]
default 0
timeout 5

title Groovy Linux
root (hd0,0)
kernel /vmlinuz root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda1 real_root=/dev/loop0 looptype=squashfs loop=/livecd.squashfs initrd udev nodevfs cdroot CGAVGA video=VGA-1:640x480ec
initrd /initrd

Files /
Code: [Select]
total 148
drwxr-xr-x  30 arcade arcade  4096 Jan 27 14:42 .
drwxr-xr-x  30 arcade arcade  4096 Jan 27 14:42 ..
-rwxr-xr-x   1 arcade arcade    64 Jan 27 14:19 .Xclients
-rw-r--r--   1 arcade arcade  6369 Dec  1 05:42 .Xdefaults
drwxr-xr-x   2 arcade arcade  4096 Jan 25 14:36 .advance
-rw-r--r--   1 arcade arcade    65 Jan 27 14:19 .asoundrc
drwxr-xr-x   3 arcade arcade  4096 Dec  1 05:42 .config
drwxr-xr-x   2 arcade arcade  4096 Dec  1 05:42 .fvwm
-rw-r--r--   1 arcade arcade 18446 Jan 25 03:33 .fvwm2rc
drwxr-xr-x   2 arcade arcade  4096 Dec  1 05:42 .gens
drwxr-xr-x   2 arcade arcade  4096 Jan 27 14:19 .groovyarcade
drwxr-xr-x   2 arcade arcade  4096 Dec  1 05:42 .mame
drwxr-xr-x   2 arcade arcade  4096 Dec  1 05:42 .mess
drwxr-xr-x   2 arcade arcade  4096 Jan 25 13:53 .nestopia
drwxr-xr-x   2 arcade arcade  4096 Dec  1 05:42 .stella
drwxr-xr-x   6 arcade arcade  4096 Dec 10 00:18 .wahcade
-rwxr-xr-x   1 arcade arcade    64 Jan 27 14:19 .xinitrc
drwxr-xr-x   2 arcade arcade  4096 Dec  1 05:42 .zsnes
drwxr-xr-x   2 root   root    4096 Jan 27 14:33 bin
drwxr-xr-x   4 root   root    4096 Jan 27 14:34 boot
drwxr-xr-x   6 root   root    4096 Jan 27 14:34 data
drwxr-xr-x  17 root   root    4040 Jan 27 16:33 dev
drwxr-xr-x  74 root   root    4096 Jan 27 16:34 etc
drwxr-xr-x   3 root   root    4096 Jan 25 15:23 home
drwxr-xr-x  13 root   root    4096 Dec 21 23:49 lib
drwxr-xr-x   2 root   root    4096 Dec 22 02:45 media
drwxr-xr-x   6 root   root    4096 Jan 27 16:33 mnt
drwxr-xr-x   5 root   root    4096 Dec 10 00:37 opt
dr-xr-xr-x 117 root   root       0 Jan 27 16:16 proc
drwxr-xr-x   2 root   root    4096 Jan 27 16:33 root
drwxr-xr-x   2 root   root    4096 Jan 27 14:33 sbin
drwxr-xr-x  12 root   root       0 Jan 27 16:16 sys
drwxrwxrwt   7 root   root    4096 Jan 27 16:19 tmp
drwxr-xr-x  13 root   root    4096 Nov 29 00:51 usr
drwxr-xr-x  13 root   root    4096 Dec 21 01:11 var

Files /data/
Code: [Select]
total 24
drwxr-xr-x  6 root   root   4096 Jan 27 14:34 .
drwxr-xr-x 30 arcade arcade 4096 Jan 27 14:42 ..
drwxr-xr-x  2 arcade arcade 4096 Jan 27 14:16 Games
lrwxrwxrwx  1 arcade arcade   20 Jan 27 14:16 artwork_all -> /data_ro/artwork_all
lrwxrwxrwx  1 arcade arcade   17 Jan 27 14:16 biosroms -> /data_ro/biosroms
lrwxrwxrwx  1 arcade arcade   12 Jan 27 14:16 cabinet -> /data_ro/cab
drwxr-xr-x  2 arcade arcade 4096 Jan 25 02:17 cat
lrwxrwxrwx  1 arcade arcade   12 Jan 27 14:16 ctl -> /data_ro/ctl
lrwxrwxrwx  1 arcade arcade   12 Jan 27 14:16 flyers -> /data_ro/fly
lrwxrwxrwx  1 arcade arcade   12 Jan 27 14:16 mrq -> /data_ro/mrq
lrwxrwxrwx  1 arcade arcade   12 Jan 27 14:16 pcb -> /data_ro/pcb
lrwxrwxrwx  1 arcade arcade   12 Jan 27 14:16 prv -> /data_ro/prv
drwxr-xr-x  2 arcade arcade 4096 Dec  1 16:44 roms
lrwxrwxrwx  1 arcade arcade   16 Jan 27 14:16 samples -> /data_ro/samples
drwxr-xr-x  9 arcade arcade 4096 Jan 27 14:16 screen_shots
lrwxrwxrwx  1 arcade arcade   12 Jan 27 14:16 ttl -> /data_ro/ttl





Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 27, 2011, 11:02:40 pm
Ves, I think the issue mostly is that I can see there being a bug when you don't use a separate partition for /home/arcade and to install to.  It seems  that your setup is using / as the /home/arcade directory on install so it ends up not getting things like .XClients setup properly.  Does the liveCD setup right when just running it?

The audio might be OSS4 and your specific sound card, have you tried choosing to use Alsa instead, it might work better on your machine.  

I'm not fully understanding the setup you are talking about with the system files from /etc/, are you saying to put them somewhere else to edit through the samba share?  I'm hoping it'd not be necessary to do that, just seems tricky and not sure if possibly there'd be a better way to configure those kind of things like through a web interface possibly with PHP.  I could see something like that being an interesting way to administer, there might even be some programs available I will look into for doing remote administration like that.  

I'm looking now to try to make the setup adapt when the home directory is the same as the future / one.  Actually what might be the issue is you probably don't want to choose a /home/arcade directory on install, and instead don't pick one at all.  In the case where your just using a single partition for everything, that is way it should be done, choosing a home directory in that case as the partition you are installing to is definitely not going to work very well at all (and probably results in some of the things your seeing).


Also the /data_ro directory basically is where it would mount an extra partition for roms/snaps, and it makes links from the actual locations to /data/ which by default are the ones I have setup that it creates.  You can just ignore all that though and use the advance Menu config and choose new locations all together, and alter them in mame.ini too.  Otherwise I do the best at making it somewhat transparent to the user by in the setup it asks to give the actual locations for each type of rom/snap for each emulator and links them from the drive mounted as '/data' which is actually /data_ro/ to the real /data/ directory. 

I need to re-evaluate the whole setup method though, I definitely can see it's probably more complex than needed and would like to make this simpler.  I need to figure out how to overhaul it without totally breaking it too, since it's quite complex in how it runs to setup the system but can do it for the liveCD well and the install works decent.  So I need to rewrite it or redo how it's done, but try to also keep things working since it definitely is a big task to setup the system like this.  I also see advance menu as possibly taking over a lot of this perhaps, there's been a lot of building it as going along and sure there's plenty of cruft now that could be removed I am guessing and refactoring. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 28, 2011, 02:01:40 am
Wouhouuuu..

 It's nice to see that i'm not alone with this problem, it would be really great if this damned laptop could work with your distro  :P
Test ISO, only change is it has the kernel patch for your video card and that extra ROM on it...

http://mario.groovy.org/Test/LiveCD32-Mini-NMO-1.313-b598cf6.iso (http://mario.groovy.org/Test/LiveCD32-Mini-NMO-1.313-b598cf6.iso)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 28, 2011, 04:17:45 am
Thanks for this iso,

 damn ... my connection get lost again , need to restart from 0 ..
do you think that you can make your server supporting resume downloads ?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 28, 2011, 04:22:05 am
Thanks for this iso,

 damn ... my connection get lost again , need to restart from 0 ..
do you think that you can make your server supporting resume downloads ?
I wish I could, but of course I'm at the mercy of the provider on that one :/.   I wish I could resume uploads when they break, sometimes I get 500 Meg uploaded after 2 hours and then it breaks, which really is frustrating, since my uploads are on a 3G sprint connection and very very slow.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 28, 2011, 04:38:12 am
Sorry for you, it's strange to see a provider in 2011 that don't support resume  :angry:
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 28, 2011, 04:47:48 am
Humm .. why not install webmin for standard maintenance operations ?  ..
it may be a little over-powered but it can do the job
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 28, 2011, 04:54:54 am
Humm .. why not install webmin for standard maintenance operations ?  ..
it may be a little over-powered but it can do the job
Yeah I was looking at it actually tonight, looks interesting for sure.  It might be a good addition it seems, have to look into how much extra overhead/space is required by installing the webserver it'll require.  Also have been digging into the Arch Linux installer some, which seems to have an extensive shell script library/setup system to do all the setup tasks for their installation.  I wish it was easier to just have a simple ubuntu style setup or RedHat, unfortunately those are somewhat hard to use since there's a the combination of normal linux setup and having to make sure the system has the little changes that make 15khz operation work properly.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 28, 2011, 05:02:47 am
Ok .. but webmin has it's own webserver who is light (don't remember the size but not hugue as apache and it's dependencies).

 I must admit that i'm happy with Gentoo, it is my main distro so i'ts not a problem for me ... but it is not the case for everyone ^^
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 28, 2011, 05:13:26 am
Its way much better now, i can get a stable picture .. not centered and sort of stretched but i can read console text ^^

 i will continue to play with this livecd for trying to get a perfect picture (for now i get only 1/4 of the upper left screen stretched).

 Thanks man, you're really amazing and made my day ^^

(http://img209.imageshack.us/img209/4619/img20110128111152.jpg)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on January 28, 2011, 05:45:55 am
Thanks for this iso,

 damn ... my connection get lost again , need to restart from 0 ..
do you think that you can make your server supporting resume downloads ?
I wish I could, but of course I'm at the mercy of the provider on that one :/.   I wish I could resume uploads when they break, sometimes I get 500 Meg uploaded after 2 hours and then it breaks, which really is frustrating, since my uploads are on a 3G sprint connection and very very slow.

That's some ---That which is odiferous and causeth plants to grow--- right there. Send me a message and I'll help you out.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 28, 2011, 05:51:55 am
Its way much better now, i can get a stable picture .. not centered and sort of stretched but i can read console text ^^

 i will continue to play with this livecd for trying to get a perfect picture (for now i get only 1/4 of the upper left screen stretched).

 Thanks man, you're really amazing and made my day ^^


That's the interlace + doublescan issue, I've seen it before. Which grub option are you choosing on startup?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 28, 2011, 05:56:09 am
Its way much better now, i can get a stable picture .. not centered and sort of stretched but i can read console text ^^

 i will continue to play with this livecd for trying to get a perfect picture (for now i get only 1/4 of the upper left screen stretched).

 Thanks man, you're really amazing and made my day ^^


That's the interlace + doublescan issue, I've seen it before. Which grub option are you choosing on startup?

 I use default boot :

title=Groovy Arcade LiveCD [CGA Arcade Monitor First VGA Output]
        kernel /boot/vmlinuz real_root=/dev/loop0 looptype=squashfs loop=/livecd.squashfs initrd udev nodevfs cdroot CGAVGA video=VGA-1:640x480ec
        initrd /boot/initrd


 But it seems that i cannot get stable picture at boot with this livecd on my other cab who works with the older iso ...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 28, 2011, 06:10:32 am

 I use default boot :

title=Groovy Arcade LiveCD [CGA Arcade Monitor First VGA Output]
        kernel /boot/vmlinuz real_root=/dev/loop0 looptype=squashfs loop=/livecd.squashfs initrd udev nodevfs cdroot CGAVGA video=VGA-1:640x480ec
        initrd /boot/initrd


 But it seems that i cannot get stable picture at boot with this livecd on my other cab who works with the older iso ...

I remind bitbytebit saying that problem happened when more than one output was enabled. It could be your laptop is not disabling its lcd screen so both are being used, not sure. You could try one of the other grub options to see if they help (Second VGA?). On the other cab problem I have no clue.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Haggar on January 28, 2011, 06:26:08 am
I've uploaded a Mame 0.141 binary (normal Mame, no CabMame hacks) with the patch I posted above. I would appreciate that Haggar or some of the other guys tested this one to see if it actually helps reducing input lag. The correct options for this test are: syncrefresh, nothrottle, notriplebuffer, multithreading

http://www.megaupload.com/?d=KO10C2GO (http://www.megaupload.com/?d=KO10C2GO)

It should be compared against:

- Itself, with nosyncrefresh, throttle
I'll try it this evening or tomorrow.

- Current CabMame binary with latest patches, using the same options (syncrefresh, nothrottle, notriplebuffer, multithreading)
You mean cabmame 0.141 right? http://community.arcadeinfo.de/showthread.php?t=9555 (http://community.arcadeinfo.de/showthread.php?t=9555)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 28, 2011, 06:34:13 am

 I use default boot :

title=Groovy Arcade LiveCD [CGA Arcade Monitor First VGA Output]
        kernel /boot/vmlinuz real_root=/dev/loop0 looptype=squashfs loop=/livecd.squashfs initrd udev nodevfs cdroot CGAVGA video=VGA-1:640x480ec
        initrd /boot/initrd


 But it seems that i cannot get stable picture at boot with this livecd on my other cab who works with the older iso ...

I remind bitbytebit saying that problem happened when more than one output was enabled. It could be your laptop is not disabling its lcd screen so both are being used, not sure. You could try one of the other grub options to see if they help (Second VGA?). On the other cab problem I have no clue.


 I've tried with vga=2 and i get a doubled picture but with the good hight (like a 31khz boot on a jpac setup) ...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 28, 2011, 06:38:09 am
Yes, you can use SailorSat's build or groovyarcade one, they must be the same on that aspect. Thanks a lot for testing that, I can't notice the subtle difference myself but if there's any you'd be able to do. Anyway the main test is to see if my build responds the same (with no lag) either with syncrefresh or throttle.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 28, 2011, 11:09:35 am

 I use default boot :

title=Groovy Arcade LiveCD [CGA Arcade Monitor First VGA Output]
        kernel /boot/vmlinuz real_root=/dev/loop0 looptype=squashfs loop=/livecd.squashfs initrd udev nodevfs cdroot CGAVGA video=VGA-1:640x480ec
        initrd /boot/initrd


 But it seems that i cannot get stable picture at boot with this livecd on my other cab who works with the older iso ...

I remind bitbytebit saying that problem happened when more than one output was enabled. It could be your laptop is not disabling its lcd screen so both are being used, not sure. You could try one of the other grub options to see if they help (Second VGA?). On the other cab problem I have no clue.


 I've tried with vga=2 and i get a doubled picture but with the good hight (like a 31khz boot on a jpac setup) ...

I'm not sure but sounds like the fix they have doesn't fully work completely or might not work with interlacing, perhaps that card can't even properly do interlacing.  Try to change the boot line to...

kernel /boot/vmlinuz real_root=/dev/loop0 looptype=squashfs loop=/livecd.squashfs initrd udev nodevfs cdroot CGAVGA video=VGA-1:320x240ec

Also to try the second VGA, make sure it's video=VGA-2:320x240ec also you can add video=LVDS-1:d  to disable the LCD output

Does the other cab have the same card, what kind of Radeon is it?  Does it work with the newer boot CD and not the Test, or neither of them?  Not sure why it would become unstable, definitely concerning if it's changed from possibly either the new 2.6.38-rc2 kernel or changes in the kernel patch.  Also make sure on it the right output is selected, since one possible change is now you really have to tell it exactly the right interface as VGA/DVI and the right number, else it will treat them like a non-arcade output.  Otherwise it wasn't possible to easily hook up normal monitors for working on things or having it work on normal monitors, basically the new patch is a lot less intrusive and doesn't break the normal kernel DRM and just enhances it when that 'c' is on the end of the video= part.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 28, 2011, 12:51:45 pm

I'll try it this evening or tomorrow.

Haggar,

I've updated the link for my Mame test build, please make sure you use the new one for testing as it has all the CabMame hacks in it:

http://www.megaupload.com/?d=XSGPDLAQ (http://www.megaupload.com/?d=XSGPDLAQ)

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Haggar on January 29, 2011, 08:43:52 am
The correct options for this test are: syncrefresh, nothrottle, notriplebuffer, multithreading
It should be compared against:
1 - Itself, with nosyncrefresh, throttle
2 - Current CabMame binary with latest patches, using the same options (syncrefresh, nothrottle, notriplebuffer, multithreading)
Tested:
1 - I feel the same "no lag"  :applaud:
2 - With cabmame and that cfg, frames go at 1000x, so I cannot test it.

Hope someone else can confirm my feelings.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 29, 2011, 11:35:24 am
Tested:
1 - I feel the same "no lag"  :applaud:

Great news, so good to hear that!  ;D
Thanks a lot for testing.

2 - With cabmame and that cfg, frames go at 1000x, so I cannot test it.

Hope someone else can confirm my feelings.

Then probably the CabMame you're testing doesn't have the multithreading patch for vsync added, that's why it runs full speed. The binary from groovyarcade has that patch already, in case you wanted to compare.

I want to believe you're right and finally it turned out that the legendary vsync input lag problem could be removed by slightly changing the way multithreading is used in Mame like this patch does.

I've attached the current groovyarcade patch modified.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 29, 2011, 11:54:56 am
Tested:
1 - I feel the same "no lag"  :applaud:

Great news, so good to hear that!  ;D
Thanks a lot for testing.

2 - With cabmame and that cfg, frames go at 1000x, so I cannot test it.

Hope someone else can confirm my feelings.

Then probably the CabMame you're testing doesn't have the multithreading patch for vsync added, that's why it runs full speed. The binary from groovyarcade has that patch already, in case you wanted to compare.

I want to believe you're right and finally it turned out that the legendary vsync input lag problem could be removed by slightly changing the way multithreading is used in Mame like this patch does.

I've attached the current groovyarcade patch modified.


Very cool, this is great, I wonder if we need to do something similar on the SDL side of things?  I'll move those changes into the current builds and patches in the GIT repository soon.  I *think* I experience some input lag, compared to what I had done in the SDL side of things before compared to what in in the current Mame SDL code now (in reference to the waitvsync/multithreading fixes they put in).  I'll have to look into this more again too. 

On the Linux ISO side of things...
Right now am rewriting the entire setup/manage stuff of the ISO hopefully to have a nice blue menu setup screen, hoping to use the information Ves (thanks) is giving to have a cleaner setup method and running method.  Now that I've gotten advanced menu working and see the way it does things, I think I can really clean a lot of cruft away and do like Ves says and just boot straight into advmenu/fvwm (or perhaps eventually drop fvwm too, not sure about that yet).  I'm wanting to hopefully get the setup menu on the console again at first, then launch from there into X and advmenu, which definitely sounds way less tricky than what currently is done. I am basing this off of the Arch Linux Installation Framework system, it's nice because I can utilize the console based disk partition/format menu they have and maybe network setup, and also adding all the needed custom things we need to do for setting up the system for the arcade monitor.  I figured the working yet really painfully tricky startup.pl script I have needs to go now that things have advanced to where they are at, and refactoring the entire setup is in order.  This also should make it much easier to go back and change system settings too.  I'm not totally sure yet about webmin, but I might install it eventually and it does look nice, but first need to refactor basic first time setup and possibly see how much space it will take up extra and if I need to purge something else to put it in.  I am leaning towards ripping out a lot of the more desktop stuff I put in, and aiming at a system where you really only see advmenu and emulator full screen output, possibly have advmenu scripts launch xterms if necessary.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 29, 2011, 12:43:15 pm
Very cool, this is great, I wonder if we need to do something similar on the SDL side of things?  I'll move those changes into the current builds and patches in the GIT repository soon.  I *think* I experience some input lag, compared to what I had done in the SDL side of things before compared to what in in the current Mame SDL code now (in reference to the waitvsync/multithreading fixes they put in).  I'll have to look into this more again too. 

Honestly I don't know how the Linux os logic works for receiving input. In Windows the issue seems to be caused because the blitting (with the wait involved) is the done in the same thread that receives the input (the window thread). This not a problem if you do the wait in the main thread, as throttle option does, so the window thread remains free to process input messages.

By the way there's something really cool that could eventually be done in AdvanceMenu, having the source code. You know this program has a wait mode where you basically are shown snapshots of the games at fullscreen. Of course, as the screen resolution is fixed, the pics have to be stretched, so the quality sucks as expected. Now, being able to do any resolution on the fly... it could be nice to see the snapshots on their right resolution. It can even be useful as a Switchres demo.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 29, 2011, 03:25:28 pm
Very cool, this is great, I wonder if we need to do something similar on the SDL side of things?  I'll move those changes into the current builds and patches in the GIT repository soon.  I *think* I experience some input lag, compared to what I had done in the SDL side of things before compared to what in in the current Mame SDL code now (in reference to the waitvsync/multithreading fixes they put in).  I'll have to look into this more again too.  

Honestly I don't know how the Linux os logic works for receiving input. In Windows the issue seems to be caused because the blitting (with the wait involved) is the done in the same thread that receives the input (the window thread). This not a problem if you do the wait in the main thread, as throttle option does, so the window thread remains free to process input messages.

By the way there's something really cool that could eventually be done in AdvanceMenu, having the source code. You know this program has a wait mode where you basically are shown snapshots of the games at fullscreen. Of course, as the screen resolution is fixed, the pics have to be stretched, so the quality sucks as expected. Now, being able to do any resolution on the fly... it could be nice to see the snapshots on their right resolution. It can even be useful as a Switchres demo.


 Hummm .. i'm not really sure that our old school (tm) monitors will appreciate to switch too quickly between resolutions ...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 29, 2011, 03:49:39 pm
Quote
Hummm .. i'm not really sure that our old school (tm) monitors will appreciate to switch too quickly the resolutions ...

Resolution switch would be only in wait/attract mode, that would do a switch maybe each 5 seconds, your monitor will be happy.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 29, 2011, 03:50:32 pm
I will no try ^^ for sure ..
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 29, 2011, 04:16:18 pm

...SNIP.....

I'm not sure but sounds like the fix they have doesn't fully work completely or might not work with interlacing, perhaps that card can't even properly do interlacing.  Try to change the boot line to...

kernel /boot/vmlinuz real_root=/dev/loop0 looptype=squashfs loop=/livecd.squashfs initrd udev nodevfs cdroot CGAVGA video=VGA-1:320x240ec

Also to try the second VGA, make sure it's video=VGA-2:320x240ec also you can add video=LVDS-1:d  to disable the LCD output

Does the other cab have the same card, what kind of Radeon is it?  Does it work with the newer boot CD and not the Test, or neither of them?  Not sure why it would become unstable, definitely concerning if it's changed from possibly either the new 2.6.38-rc2 kernel or changes in the kernel patch.  Also make sure on it the right output is selected, since one possible change is now you really have to tell it exactly the right interface as VGA/DVI and the right number, else it will treat them like a non-arcade output.  Otherwise it wasn't possible to easily hook up normal monitors for working on things or having it work on normal monitors, basically the new patch is a lot less intrusive and doesn't break the normal kernel DRM and just enhances it when that 'c' is on the end of the video= part.

 I can boot with vga-1 at 320x240ec .. not with vga-2 and in any case  LCDS-1:d does not seems to work, xrandr tell me that lvds is connected ..

 Please excuse me regarding the other cab, i've made some mistakes in my test process, forget this part all is ok ^^

 I'm installing mini iso on hdd, it will be better for tests.

--------------------

I can use 640x480 or 320x240 at boot result is the same =
Wahcade gui is in fullscreen and picture is centered and good so it seems that resolution is ok,
when i launch game the resolution is ok but i can see a noticeable blanking effect (epileptic mode on)

http://img248.imageshack.us/i/vln.mp4/ (http://img248.imageshack.us/i/vln.mp4/)

 Don't worry about the missing red component, i need to resolder my vga connector (damn Great Dane .....)

arcade@GroovyArcade /root $ xrandr
Screen 0: minimum 320 x 200, current 648 x 480, maximum 8192 x 8192
VGA-0 connected 648x480+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   648x480x60.00   30.0*
LVDS connected (normal left inverted right x axis y axis)
   1280x800       60.0 +
   1280x720       59.9
   1152x768       59.8
   1024x768       60.0     59.9
   800x600        60.3     59.9
   848x480        59.7
   720x480        59.7
   640x480        59.9     59.4
   512x384       120.0
   400x300       120.6
   320x240       120.1
HDMI-0 disconnected (normal left inverted right x axis y axis)

Grub commandline =
kernel /boot/vmlinuz root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda1 initrd udev nodevfs CGAVGA video=VGA-1:640x480ec VIDEO=LVDS-1:d
initrd /boot/initrd


Do you think that this patch may be helpfull regarding my problem ?
 http://lists.freedesktop.org/archives/dri-devel/2010-November/005901.html (http://lists.freedesktop.org/archives/dri-devel/2010-November/005901.html)

Edit =

my syslog is full of

Code: [Select]
[ 1301.085956] radeon 0000:01:05.0: HDMI-A-1: EDID block 0 invalid.
[ 1301.085966] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID
[ 1311.154002] [drm:drm_edid_block_valid] *ERROR* Raw EDID:

 ...hdmi ?? ... i only have a vga output and a lvds internal connector ..
[/s]
 I think that this laptop will learn to fly soon  :angry:    :laugh:
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 29, 2011, 07:09:20 pm
Humm ....

 Much better with

kernel /boot/vmlinuz root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda1 initrd udev nodevfs CGAVGA video=VGA-1:640x480ec video=LVDS-1:d video=HDMI-A-1:d

 Now i can get a 640x480 boot without artifacts BUT i get the blanking problem described in the previous video ...

[  253.283307] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id


 I see the end of the tunnel but ..... ^^
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 29, 2011, 08:05:37 pm
Humm ....

 Much better with

kernel /boot/vmlinuz root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda1 initrd udev nodevfs CGAVGA video=VGA-1:640x480ec video=LVDS-1:d video=HDMI-A-1:d

 Now i can get a 640x480 boot without artifacts BUT i get the blanking problem described in the previous video ...

[  253.283307] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id


 I see the end of the tunnel but ..... ^^
Yeah that patch is in the kernel already, they put that in around last December, I remember it.  Definitely looks promising, the invalid framebuffer id thing seems to happen to everybody actually so it's a whole other thing and maybe not more than a warning from what I can tell.  I wonder if it's something to do with the same basic issue of that chip, that the original patch and bug report is about.  Actually you probably should post information to that original bug report I posted, and give Alex the information about what is going on.  He's very helpful, and this will probably spark his interest in testing that patch and seeing it helps you but also the video and information about what is still going wrong.  Any more patches he produces about it, I can apply and we can test. Very encouraging that it's closer than it was, seems like he'd be the only one who would know what kernel tricks to do to fix it all the way.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on January 30, 2011, 03:42:27 am
You're right, my problem is not related to your software, i will try to give as much informations as i can to Alex.

 I've posted a thread on a french forum about your software, seems that you will see more froggies around near  ::)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 31, 2011, 10:04:57 am
Hi! I'm testing LiveCD32-Full-O-1.311-e925891.iso, AdvanceMenu is not included with this one yet, only Wahcade, right?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 31, 2011, 10:25:54 am
Hi! I'm testing LiveCD32-Full-O-1.311-e925891.iso, AdvanceMenu is not included with this one yet, only Wahcade, right?

If it's the ones on the site right now, yes it does have advmenu actually.  it's under /usr/games/bin/advmenu and should be available as an option in setup or possibly use fvwm and it'll launch it now automatically.

I'm getting pretty close with my reworking of the system to setup things, it's looking really promising :).  I think this should lead into something very user friendly, I have gotten the webmin interface so now you can completely configure the system later just by going to port 80 on it in a web browser.  The setup interface allows for easy administration even after setup has been done, probably plenty of extra functionality now that I can put in there easier than before.  Basically it's the whole blue background console type menu/graphics like in DOS or something now.  Hopefully with the new setup/install system things will be amazingly simple to configure and it'll probably be very close to more of what Ves has envisioned with having just advmenu on startup and a very trimmed down system to just do the emulation stuff.  Also I think I've fixed that pesky bug that caused the X Windows startup to kill the frame buffer console output, which is what I had went to the gdm graphical login for.  So hopefully now it'll be easy to base the initial setup and startup to the console and have startup of X Windows really just startup advmenu and really start simplifying the whole setup of that.

So hopefully in a day or less I'll have a new ISO that will go into testing that, but curious how advmenu runs there so I can possibly fix anything with it for the next ISO while waiting for the rebuild of the X Windows system I'm doing.  In the new way I'm doing things, it'll be more of the idea of just putting the roms in /data/ somewhere or /home/arcade/ or anywhere else and easily changing the advmenu config file to point to them.  So all that linking and translation stuff won't be necessary, which definitely is confusing probably for anyone but me who just happens to have setup mine that way already.  Now they are just the defaults in the advmenu config, easy to change. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on January 31, 2011, 11:06:54 am
Sounds great, that web administration thing will help us a lot! Definitely good to have that. So, if I'm getting it right, one should eventually be able to map the win ntfs partition in case the roms are there, in order to avoid having two copies of the same thing in different partitions? (I think it was actually possible right know, though I didn't try it seriously since we were testing the other stuff)

The iso I'm testing seems to be old then, I downloaded it some days ago, just tested today.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 31, 2011, 11:26:28 am
Sounds great, that web administration thing will help us a lot! Definitely good to have that. So, if I'm getting it right, one should eventually be able to map the win ntfs partition in case the roms are there, in order to avoid having two copies of the same thing in different partitions? (I think it was actually possible right know, though I didn't try it seriously since we were testing the other stuff)

The iso I'm testing seems to be old then, I downloaded it some days ago, just tested today.

Yeah in theory, actually the webmin interface will allow you to mount new partitions to the system too, but also it should be possible to choose an ntfs partition for the rom/snap drive or /data/.  I actually need to go through that and make it partition type independent, one thing I did notice was it might right now center around the linux ext4 fs somewhat. 

One thing for sure is that with the this new setup system it's a whole lot easier to add things, alter things, which is what I needed because the startup.pl perl script just has become a nasty mess of code.  Basically I took the Arch Linux Installation Framework or AIF, and used that as the UI API, and now have all these great ways to create menus and stuff in the blue graphical console way using the bash/unix shell scripting.  So it's definitely looking more like a normal Linux installation/setup interface, at least one like the Slackware system used or Arch Linux uses, not graphical but console/DOS menu oriented.

Also Gentoo seems to have moved the 1.9 X Windows versions into stable and so I'm updating everything and dropping the bleeding edge GIT versions of X for the more stable 1.9 version.  That should be better in general, now that they use a version which can remove the default modes and do xrandr  properly.  So I'm going through a complete system update too with that, and it seems to have solved the broken console issue, I think.  I'm still going to have to do more testing with that after done rebuilding/recompiling the updates, see how it acts on the radeon card, and make sure everything is properly functioning. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on January 31, 2011, 06:01:20 pm
Hi bitbytebit , I believe that these changes may be of interest to leave as hidden as possible the system

Hide mouse on advmenu.

change:
Code: [Select]
auto device_video_outputby:
Code: [Select]
device_video_output fullscreen
For loading the game does not go to X and display the snap of the game to load.

change:
Code: [Select]
display_restoreatgame yesby:
Code: [Select]
display_restoreatgame no
ui_game  snap

Hide mouse in Xorg

Create file emptycursor /home/arcade/.emptycursor ,these data
Code: [Select]
#define nn1_width 16
#define nn1_height 16
static unsigned char nn1_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

And put in xinitrc or Xsession to run at startup.
Code: [Select]
xsetroot -cursor /home/arcade/.emptycursor /home/arcade/.emptycursor

That way you can make the kernel load Groovy faster, or carry things in the background as ubuntu?
One could make the driver loaded first hard disk, video, sound and strip the X leaving the other loading processes in the background? (I do not know is that gentoo)
Or I can do to not load both modules?


Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on January 31, 2011, 07:02:42 pm
Hi bitbytebit , I believe that these changes may be of interest to leave as hidden as possible the system

Hide mouse on advmenu.

change:
Code: [Select]
auto device_video_outputby:
Code: [Select]
device_video_output fullscreen
For loading the game does not go to X and display the snap of the game to load.

change:
Code: [Select]
display_restoreatgame yesby:
Code: [Select]
display_restoreatgame no
ui_game  snap

Hide mouse in Xorg

Create file emptycursor /home/arcade/.emptycursor ,these data
Code: [Select]
#define nn1_width 16
#define nn1_height 16
static unsigned char nn1_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

And put in xinitrc or Xsession to run at startup.
Code: [Select]
xsetroot -cursor /home/arcade/.emptycursor /home/arcade/.emptycursor

That way you can make the kernel load Groovy faster, or carry things in the background as ubuntu?
One could make the driver loaded first hard disk, video, sound and strip the X leaving the other loading processes in the background? (I do not know is that gentoo)
Or I can do to not load both modules?


Thanks.

Sounds great, I"m testing this right now.  One thing I see though is when setting device_video_output fullscreen for some reason I get a black screen, I'm wondering if it's not working with the display I'm testing on.  Wondering if this option may be a bit device dependent or else I'm doing something wrong or it needs some other option or check too?

I'm not sure if I can do that in Gentoo with getting it to load faster, I'm figuring it for the most part hopefully is decent at loading speed, trying not to do too much that would make it hard to keep updating and utilize the Gentoo emerge/ebuild system for packages.  Sounds like that would be really altering things to make it tricker to maintain, but interesting sounding and would be interested in examples of what the process is to do that.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 01, 2011, 03:09:59 am
32 and 64 bit ISO images are up for version 1.368-33e345e ...

http://mario.groovy.org (http://mario.groovy.org)

Quote
   - Completely new Menu Installation and Setup application gasetup
    - More stable X Windows version used now, default Gentoo 1.9.2 Xorg
    - Fixed 32bit CPU usage issues, now same as 64bit version
    - Minimized ISO image size by removing most extra software not needed
    - AdvanceMENU improvements with display and setup
    - No longer use GDM and basically just go straight into advmenu from the console
    - Console used for setup now
    - Now should be able to reconfigure the system very easily at any time though gasetup
    - WebMin interface added, runs on port 80 and accessible through a webbrowser.  Now
      you can setup just about everything on the system through it after you do a disk install.
    - Disk installation should be greatly improved, partioning and formatting done nicer, setup
      in general is much more flexable now.
    - Updated Gentoo system to newest versions of packages for it.
    - For now the ISO doesn't contain much extra, just emulators and what is necessary to run
      them.
    - No longer have a complex setup for /data/ and Rom/Snap locations, it's now up to you to
      simply drop them into /data/ or whereever and point advmenu to them.
    - Grub installation of the MBR for the disk install should be very easy to do now
    - Audio setup should be easy to switch between Alsa and OSS4 now
    - New Xorg version no longer hangs console display, so can go back to the frame buffer
      console now and back into X Windows without issues.

Example of how setup/installer looks.

(http://[url=http://mario.groovy.org/IMG_0200.jpg]http://mario.groovy.org/IMG_0200.jpg[/url])

So now you should be able to copy files through Windows shares easily, setup things through the console setup menu easily, and when installed (or even from LiveCD, but doesn't seem as useful) use webmin by going to http://servername (http://servername) and do just about any modification of the system from there.  


Basically the way to work the menu is that you boot the live CD, setup things the way you like them going through the menu items, the the install to disk is done after that if you want to save it to a hard drive and boot into it after that.  Also if you setup a /home directory it'll save all your changes and boot straight into the system on boots from the liveCD after that.  If you want to alter settings, you just run 'gasetup' as root (sudo -s) and you can change anything you want to, it's not like the old system that didn't allow that to be as easy.  Think of the /data directory as the Roms/Snaps directory which can be a separate partition or not, and you can dump things into there from  the Windows ROMS share accessible in the GROOVY workgroup as the GroovyArcade server.  The webmin interface can go into quite a bit of detailed administration, of course changes are not saved from that for the liveCD, only once installed.  You can do about anything with webmin, should have full control of the advanceMENU config and /home/arcade/ and /data directories through samba.  Hopefully this is really user friendly now, looking for feedback about any bugs or things that could be better, it's a complete rewrite of things so of course I expect there to be a few issues or more.

Look for bugs, post feature requests, now I have a lot of possibilities in the menu system that weren't there before in the old setup method.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 01, 2011, 09:01:08 am
Hi bit, I put my configuration file here, I think I have not touched anything else, I use AVGA 92250 and does not stay black screen, try it and tell me how it went.
advmenu.rc
Code: [Select]
config save_at_exit
#device_alsa_device default
#device_alsa_mixer channel
device_color_bgr15 yes
device_color_bgr16 yes
device_color_bgr24 yes
device_color_bgr32 yes
device_color_bgr8 yes
device_color_palette8 yes
device_color_yuy2 yes
device_joystick none
device_keyboard auto
device_mouse none
device_raw_firstkeyhack no
device_sdl_samples 512
device_sound auto
device_video auto
device_video_cursor auto
device_video_doublescan yes
device_video_fastchange no
device_video_interlace yes
device_video_output fullscreen
device_video_overlaysize auto
device_video_singlescan yes
difficulty none
display_brightness 1
display_gamma 1
display_orientation
display_restoreatexit yes
display_restoreatgame no
display_size 640
emulator "mame" sdlmame "switchres" ""
emulator_roms "mame" "/data/roms;/mnt/hd/mame/roms"
emulator_flyers "mame" "/data/fly;/mnt/hd/mame/snap"
emulator_cabinets "mame" "/data/cab;/mnt/hd/mame/cabinets"
emulator_marquees "mame" "/data/mrq;/mnt/hd/mame/marquees"
emulator_icons "mame" "/data/ico"
emulator_titles "mame" "/data/ttl;/mnt/hd/mame/titles"
emulator_altss "mame" "/mnt/hd/mame/snap"
#
emulator "N64" generic "switchres" "n64 --xrandr --emulator mupen64plus --rom %p --args --fullscreen"
emulator_altss "N64" "/data/screen_shots/N64/snaps"
emulator_roms "N64" "/data/Games/N64"
#
emulator "NES" generic "switchres" "nes --emulator nestopia --rom %p"
emulator_altss "NES" "/data/screen_shots/NES/snaps"
emulator_roms "NES" "/data/Games/NES"
#
emulator "SNES" generic "switchres" "snes --emulator zsnes --args -m %p"
emulator_altss "SNES" "/data/screen_shots/SNES/snaps"
emulator_roms "SNES" "/data/Games/SNES"
#
emulator "SegaGenesis" generic "switchres" "genesis --xrandr --emulator gens --rom %p --args --fs --quickexit"
emulator_altss "SegaGenesis" "/data/screen_shots/SegaGenesis/snaps"
emulator_roms "SegaGenesis" "/data/Games/SegaGenesis"
#
emulator "Coleco" generic "switchres" "coleco --emulator mess --rom %p"
emulator_altss "Coleco" "/data/screen_shots/Coleco/snaps"
emulator_roms "Coleco" "/data/Games/Coleco"
#
emulator "Atari2600" generic "switchres" "a2600 --xrandr --emulator stella --rom %p --args -fullscreen 1"
emulator_altss "Atari2600" "/data/screen_shots/Atari2600/snaps"
emulator_roms "Atari2600" "/data/Games/Atari2600"
#
event_alpha no
event_assign up up or 8_pad
event_assign down down or 2_pad
event_assign left left or 4_pad
event_assign right right or 6_pad
event_assign enter enter or enter_pad or 1
event_assign esc esc
event_assign space space
event_assign home home
event_assign end end
event_assign pgup pgup
event_assign pgdn pgdn
event_assign del del
event_assign ins insert
event_assign shutdown 2 or lcontrol esc
event_assign mode tab
event_assign help f1
event_assign group f2
event_assign type f3
event_assign exclude f4
event_assign sort f5
event_assign setgroup f9
event_assign settype f10
event_assign runclone f12
event_assign command f8
event_assign menu backquote or backslash
event_assign emulator f6 or 5
event_assign rotate 0_pad
event_assign lock scrlock
event_assign preview space
event_assign mute period_pad or p
event_mode fast
event_repeat 500 50
icon_space 43
idle_screensaver 60 10
idle_screensaver_preview snap
idle_start 0 0
include
input_hotkey yes
lock yes
menu_base 121
menu_rel 25
merge differential
misc_exit shutdown
#normal
misc_quiet no
mode list
mode_skip
mouse_delta 100
preview snap
preview_default none
preview_default_cabinet none
preview_default_flyer none
preview_default_icon none
preview_default_marquee none
preview_default_snap none
preview_default_title none
preview_expand 1.15
sort parent
sound_background_begin none
sound_background_end none
sound_background_loop sloop.mp3
sound_background_loop_dir "mp3"
sound_background_start none
sound_background_stop none
sound_buffer 0.1
sound_foreground_begin none
sound_foreground_end none
sound_foreground_key none
sound_foreground_start sstart.mp3
sound_foreground_stop none
sound_latency 0.1
sound_samplerate 44100
sound_volume -0  
ui_background none  
ui_bottombar yes
ui_clip single
ui_color help ffffff 000000
ui_color help_tag 00ff00 000000
ui_color submenu_bar 00ff00 000000
ui_color submenu_item ffffff 000000
ui_color submenu_item_select 808080 ffffff
ui_color submenu_hidden 808080 000000
ui_color submenu_hidden_select 000000 808080
ui_color menu_item ffffff 000000
ui_color menu_hidden 808080 000000
ui_color menu_tag 00ff00 000000
ui_color menu_item_select 000000 00ff00
ui_color menu_hidden_select 808080 00ff00
ui_color menu_tag_select ffffff 00ff00
ui_color bar ffffff 000000
ui_color bar_tag 00ff00 000000
ui_color bar_hidden 808080 000000
ui_color grid 00ff00 000000
ui_color backdrop 000000 808080
ui_color icon ffffff 000000
ui_color cursor ffffff 000000
ui_command_error Error running the command
ui_command_menu Command...
ui_console no
ui_exit none
ui_font auto
ui_fontsize 35
#ui_fontsize auto
ui_game snap
ui_gamemsg "Loading"
ui_help none
ui_menukey yes
ui_skipbottom 0
ui_skipleft 0
ui_skipright 0
ui_skiptop 0
ui_startup yes
ui_topbar yes
ui_translucency 0.6
mame/mode list
group_include "<undefined>"
group_include "Bad"
group_include "Good"
group_include "Very Good"
type_include "<undefined>"
type_include "Application"
type_include "Arcade"
type_include "Bet 'em Up"
type_include "Breakout"
type_include "Computer"
type_include "Console"
type_include "Fight"
type_include "Filler"
type_include "Flipper"
type_include "Gun"
type_include "Puzzle"
type_include "RPG"
type_include "Racing"
type_include "Shot 'em Up"
type_include "Sport"
emulator_include "mame"
group "<undefined>"
group "Bad"
group "Good"
group "Very Good"
type "<undefined>"
type "Application"
type "Arcade"
type "Bet 'em Up"
type "Breakout"
type "Computer"
type "Console"
type "Fight"
type "Filler"
type "Flipper"
type "Gun"
type "Puzzle"
type "Racing"
type "RPG"
type "Shot 'em Up"
type "Sport"
emulator_attrib "mame" missing exclude
emulator_attrib "mame" clone exclude
emulator_attrib "mame" bad exclude
emulator_attrib "mame" vector include
emulator_attrib "mame" vertical include
emulator_attrib "mame" neogeo include
emulator_attrib "mame" deco exclude
emulator_attrib "mame" playchoice exclude
emulator_attrib "N64" missing exclude
emulator_attrib "NES" missing exclude
emulator_attrib "SNES" missing exclude
emulator_attrib "SegaGenesis" missing exclude
emulator_attrib "Coleco" missing exclude
emulator_attrib "Atari2600" missing exclude

With regard to not show X when loading a game, with the option ui_game snap in fucnionaba msdo better, here you still see a little X, but much less than without this option, tonight will try to test your latest version and tell you how it went .

You could try the option to hide the mouse in X with xsetroot? has worked for you?

Another option that should be included in the serious advmenu.rc
Code: [Select]
lock yesso they can not leave the advmenu if you just want to play.

I see you've removed gdm, and load the graphical environment now?

Could make a small howto where are the config files as you need to run, where they are, for they are etc ...? is to get an idea of all that has


Thank

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dapsaille on February 01, 2011, 09:44:31 am
Hi, thanks for the new iso, installation is much better now but ....

 I've found the following problems  ;D

 grub by default use /vmlinuz instead of /boot/vmlinux

 I cannot select /home or / partition to store roms un the install menu

 eth0 is not set up at boot (maybee i've missed the network config menu)



after boot X fail to start = no screen found [   384.969] (EE) No devices detected. ... it may be related to my special ati crap card ^^

 BusID was not good, now it works ^^
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 01, 2011, 11:34:00 am
Hi, thanks for the new iso, installation is much better now but ....

 I've found the following problems  ;D

 grub by default use /vmlinuz instead of /boot/vmlinux

 I cannot select /home or / partition to store roms un the install menu

 eth0 is not set up at boot (maybee i've missed the network config menu)



after boot X fail to start = no screen found [   384.969] (EE) No devices detected. ... it may be related to my special ati crap card ^^

 BusID was not good, now it works ^^

Thanks, yeah the grub setup was about the only routine I pulled from the Arch Linux installer functions so that figures, I'll have to go through that and fix it.

Actually in the top Disk Setup menu option goes into a menu with the  option to mount a Home drive under /home/arcade and/or a Rom/Snap drive under /data/ which are both writable through the samba share and you should then be able to edit the advancemenu configuration to point under those directories somewhere (default is /data/roms, but can move that to anywhere under /data/ or /home/arcade/).

Yeah the main menu has the Network Setup menu, use it, and you'll be able to setup eth0 through it.

Basically going from menu item 1, and working from there, just not partitioning disks if you don't want to install to or redo partitions, not going into the Install to disk if not wanting to do that.  So basically covering all menu items should be done to setup everything first then last the install, then things will be setup when it installs and it'll use your settings plus the system can be tested first on the liveCD before running the last install menu item.

Update:

Hmm, I don't see that the /vmlinuz or /boot/vmlinux are used in the setup script part anywhere, where are you seeing that?  I'm not sure but should be just /boot/vmlinuz used after install to a partition. 

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 01, 2011, 11:38:39 am
Hi bit, I put my configuration file here, I think I have not touched anything else, I use AVGA 92250 and does not stay black screen, try it and tell me how it went.
advmenu.rc
Code: [Select]
config save_at_exit
#device_alsa_device default
#device_alsa_mixer channel
device_color_bgr15 yes
device_color_bgr16 yes
device_color_bgr24 yes
device_color_bgr32 yes
device_color_bgr8 yes
device_color_palette8 yes
device_color_yuy2 yes
device_joystick none
device_keyboard auto
device_mouse none
device_raw_firstkeyhack no
device_sdl_samples 512
device_sound auto
device_video auto
device_video_cursor auto
device_video_doublescan yes
device_video_fastchange no
device_video_interlace yes
device_video_output fullscreen
device_video_overlaysize auto
device_video_singlescan yes
difficulty none
display_brightness 1
display_gamma 1
display_orientation
display_restoreatexit yes
display_restoreatgame no
display_size 640
emulator "mame" sdlmame "switchres" ""
emulator_roms "mame" "/data/roms;/mnt/hd/mame/roms"
emulator_flyers "mame" "/data/fly;/mnt/hd/mame/snap"
emulator_cabinets "mame" "/data/cab;/mnt/hd/mame/cabinets"
emulator_marquees "mame" "/data/mrq;/mnt/hd/mame/marquees"
emulator_icons "mame" "/data/ico"
emulator_titles "mame" "/data/ttl;/mnt/hd/mame/titles"
emulator_altss "mame" "/mnt/hd/mame/snap"
#
emulator "N64" generic "switchres" "n64 --xrandr --emulator mupen64plus --rom %p --args --fullscreen"
emulator_altss "N64" "/data/screen_shots/N64/snaps"
emulator_roms "N64" "/data/Games/N64"
#
emulator "NES" generic "switchres" "nes --emulator nestopia --rom %p"
emulator_altss "NES" "/data/screen_shots/NES/snaps"
emulator_roms "NES" "/data/Games/NES"
#
emulator "SNES" generic "switchres" "snes --emulator zsnes --args -m %p"
emulator_altss "SNES" "/data/screen_shots/SNES/snaps"
emulator_roms "SNES" "/data/Games/SNES"
#
emulator "SegaGenesis" generic "switchres" "genesis --xrandr --emulator gens --rom %p --args --fs --quickexit"
emulator_altss "SegaGenesis" "/data/screen_shots/SegaGenesis/snaps"
emulator_roms "SegaGenesis" "/data/Games/SegaGenesis"
#
emulator "Coleco" generic "switchres" "coleco --emulator mess --rom %p"
emulator_altss "Coleco" "/data/screen_shots/Coleco/snaps"
emulator_roms "Coleco" "/data/Games/Coleco"
#
emulator "Atari2600" generic "switchres" "a2600 --xrandr --emulator stella --rom %p --args -fullscreen 1"
emulator_altss "Atari2600" "/data/screen_shots/Atari2600/snaps"
emulator_roms "Atari2600" "/data/Games/Atari2600"
#
event_alpha no
event_assign up up or 8_pad
event_assign down down or 2_pad
event_assign left left or 4_pad
event_assign right right or 6_pad
event_assign enter enter or enter_pad or 1
event_assign esc esc
event_assign space space
event_assign home home
event_assign end end
event_assign pgup pgup
event_assign pgdn pgdn
event_assign del del
event_assign ins insert
event_assign shutdown 2 or lcontrol esc
event_assign mode tab
event_assign help f1
event_assign group f2
event_assign type f3
event_assign exclude f4
event_assign sort f5
event_assign setgroup f9
event_assign settype f10
event_assign runclone f12
event_assign command f8
event_assign menu backquote or backslash
event_assign emulator f6 or 5
event_assign rotate 0_pad
event_assign lock scrlock
event_assign preview space
event_assign mute period_pad or p
event_mode fast
event_repeat 500 50
icon_space 43
idle_screensaver 60 10
idle_screensaver_preview snap
idle_start 0 0
include
input_hotkey yes
lock yes
menu_base 121
menu_rel 25
merge differential
misc_exit shutdown
#normal
misc_quiet no
mode list
mode_skip
mouse_delta 100
preview snap
preview_default none
preview_default_cabinet none
preview_default_flyer none
preview_default_icon none
preview_default_marquee none
preview_default_snap none
preview_default_title none
preview_expand 1.15
sort parent
sound_background_begin none
sound_background_end none
sound_background_loop sloop.mp3
sound_background_loop_dir "mp3"
sound_background_start none
sound_background_stop none
sound_buffer 0.1
sound_foreground_begin none
sound_foreground_end none
sound_foreground_key none
sound_foreground_start sstart.mp3
sound_foreground_stop none
sound_latency 0.1
sound_samplerate 44100
sound_volume -0  
ui_background none  
ui_bottombar yes
ui_clip single
ui_color help ffffff 000000
ui_color help_tag 00ff00 000000
ui_color submenu_bar 00ff00 000000
ui_color submenu_item ffffff 000000
ui_color submenu_item_select 808080 ffffff
ui_color submenu_hidden 808080 000000
ui_color submenu_hidden_select 000000 808080
ui_color menu_item ffffff 000000
ui_color menu_hidden 808080 000000
ui_color menu_tag 00ff00 000000
ui_color menu_item_select 000000 00ff00
ui_color menu_hidden_select 808080 00ff00
ui_color menu_tag_select ffffff 00ff00
ui_color bar ffffff 000000
ui_color bar_tag 00ff00 000000
ui_color bar_hidden 808080 000000
ui_color grid 00ff00 000000
ui_color backdrop 000000 808080
ui_color icon ffffff 000000
ui_color cursor ffffff 000000
ui_command_error Error running the command
ui_command_menu Command...
ui_console no
ui_exit none
ui_font auto
ui_fontsize 35
#ui_fontsize auto
ui_game snap
ui_gamemsg "Loading"
ui_help none
ui_menukey yes
ui_skipbottom 0
ui_skipleft 0
ui_skipright 0
ui_skiptop 0
ui_startup yes
ui_topbar yes
ui_translucency 0.6
mame/mode list
group_include "<undefined>"
group_include "Bad"
group_include "Good"
group_include "Very Good"
type_include "<undefined>"
type_include "Application"
type_include "Arcade"
type_include "Bet 'em Up"
type_include "Breakout"
type_include "Computer"
type_include "Console"
type_include "Fight"
type_include "Filler"
type_include "Flipper"
type_include "Gun"
type_include "Puzzle"
type_include "RPG"
type_include "Racing"
type_include "Shot 'em Up"
type_include "Sport"
emulator_include "mame"
group "<undefined>"
group "Bad"
group "Good"
group "Very Good"
type "<undefined>"
type "Application"
type "Arcade"
type "Bet 'em Up"
type "Breakout"
type "Computer"
type "Console"
type "Fight"
type "Filler"
type "Flipper"
type "Gun"
type "Puzzle"
type "Racing"
type "RPG"
type "Shot 'em Up"
type "Sport"
emulator_attrib "mame" missing exclude
emulator_attrib "mame" clone exclude
emulator_attrib "mame" bad exclude
emulator_attrib "mame" vector include
emulator_attrib "mame" vertical include
emulator_attrib "mame" neogeo include
emulator_attrib "mame" deco exclude
emulator_attrib "mame" playchoice exclude
emulator_attrib "N64" missing exclude
emulator_attrib "NES" missing exclude
emulator_attrib "SNES" missing exclude
emulator_attrib "SegaGenesis" missing exclude
emulator_attrib "Coleco" missing exclude
emulator_attrib "Atari2600" missing exclude

With regard to not show X when loading a game, with the option ui_game snap in fucnionaba msdo better, here you still see a little X, but much less than without this option, tonight will try to test your latest version and tell you how it went .

You could try the option to hide the mouse in X with xsetroot? has worked for you?

Another option that should be included in the serious advmenu.rc
Code: [Select]
lock yesso they can not leave the advmenu if you just want to play.

I see you've removed gdm, and load the graphical environment now?

Could make a small howto where are the config files as you need to run, where they are, for they are etc ...? is to get an idea of all that has


Thank



Thanks for the config, yeah I included the full screen option on the ISO and it works on my cab, just didn't on my laptop.  I don't think it works on all video cards especially an LCD with an intel on a laptop :).  

I have the cursor setup also in the new ISO, so it's there and it works good.  

I'll go through and do more experimenting and adding options for advancemenu from this, thanks for showing me all these, nice and they are very obscure to find tons of information on these options so great that your bringing them to my attention.

Update:

Yeah gdm is gone, definitely nicer now just running advmenu basically.  There's definitely a lot more possibilities now, and hopefully can build up some documentation from the experiences of people using it and see what needs to be improved to help it be easier. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: emphatic on February 01, 2011, 01:40:59 pm
Noob question: If I download, burn and boot from this CD, will I be able to do all the install steps using a VGA screen? So if I choose to install a 15kHz setup, this resolution won't be activated until I reboot?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 01, 2011, 01:50:23 pm
Noob question: If I download, burn and boot from this CD, will I be able to do all the install steps using a VGA screen? So if I choose to install a 15kHz setup, this resolution won't be activated until I reboot?
Yeah you should be able to install using a VGA screen.  When your in the grub menu, the choice you pick with be 15khz, like DVI-1 for example, but all others will work normal as VGA 31.5khz.  So basically if you hook up a monitor to the other output, like VGA-1 but choose DVI-1 to be 15khz at the grub menu.  Then you can install from VGA, choose monitor type as CGA 15khz in the setup menu still, and when you reboot the system the installation should output 15khz on the DVI-1 interface you picked at the grub menu originally.  Also you can edit the grub config to use another interface for 15khz too or even install as SVGA, and then edit grub and reconfigure the monitor type in gasetup later. 

Sounds like a good menu option in setup would be to change that 15khz output to whatever a user wanted and have a menu of available ones.  Right now it can be done through the above by taking advantage of the fact that the grub menu option chosen is the only output at 15khz and the rest will always be normal outputs to VGA/SVGA frequencies.  Also the installer looks at which one you picked and puts that into the /boot/grub/grub.conf file, so it could be edited after that too (install is done to /groovyarcade/ chroot directory, so after running install you can always go in there and fiddle with things before rebooting or go into webmin at the system after reboot and edit stuff there too, even without the monitor working).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 01, 2011, 02:45:05 pm
I've been testing the new iso and the setup with those dos-like menus windows is really cool :) Everything is so easy to do now, and you can go back and forth if you make some mistake, the reboot option helps also. Video, sound, etc is working perfect as with the last versions (sound still is very low compared to Windows even if I choose level 25, suppose it's something with my card, not important anyway). Still haven't tested the network. Just noticed that the snaps in Advancemu are not showing for some reason.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 01, 2011, 07:06:56 pm
Hello bitbytebit tests with LiveCD32-Full-1.368-33e345e.iso

Grub still fails, you can make a solution a bit sloppy as to create initrd vmlinuz symlinks in /

I think you should warn for newbies to choose the home directory is to put it on a partition other than the installation because it can not be installed, as well as data.

Here I have my doubts if you choose a partition to install the live and another to take home, which creates data?
Do not think it is best to default data within the home? Sorry for insisting on this, but I think it would be as easy for any newbies.

For xterm loads. xinitrc? If you hide the mouse, remove gdm etc. .. is to make it look as possible to the system, no? to me it has worked well without putting advmenu xterm.

After installation, the boot does not directly load X, it waits console login.
What application do you use to autologin? mingetty ...?

I tried mame and mess, but I can not always run the libraries fail with Alsa, but alsa or oss configure the installation, always the same error of libraries alsa, and I can not run any game.
I do not think that imaging can be corrupt, and I set advmenu to sound a mp3 while you're on the list of games working well, so it can be a bad compilation, right?

Another thing that would be interesting is that the arcade user can use the shutdown command to turn off the machine from a key or key combination, I was wearing with 2 +5 key in msdos, but in linux I have not been able to do not function to run shutdown from regular user.



Thank you and Goodnight today.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 01, 2011, 07:24:48 pm
Hello bitbytebit tests with LiveCD32-Full-1.368-33e345e.iso

Grub still fails, you can make a solution a bit sloppy as to create initrd vmlinuz symlinks in /

I think you should warn for newbies to choose the home directory is to put it on a partition other than the installation because it can not be installed, as well as data.

Here I have my doubts if you choose a partition to install the live and another to take home, which creates data?
Do not think it is best to default data within the home? Sorry for insisting on this, but I think it would be as easy for any newbies.

For xterm loads. xinitrc? If you hide the mouse, remove gdm etc. .. is to make it look as possible to the system, no? to me it has worked well without putting advmenu xterm.

After installation, the boot does not directly load X, it waits console login.
What application do you use to autologin? mingetty ...?

I tried mame and mess, but I can not always run the libraries fail with Alsa, but alsa or oss configure the installation, always the same error of libraries alsa, and I can not run any game.
I do not think that imaging can be corrupt, and I set advmenu to sound a mp3 while you're on the list of games working well, so it can be a bad compilation, right?

Another thing that would be interesting is that the arcade user can use the shutdown command to turn off the machine from a key or key combination, I was wearing with 2 +5 key in msdos, but in linux I have not been able to do not function to run shutdown from regular user.



Thank you and Goodnight today.

Ah, I'll have to look closer at grub still, so it really wants things in / I guess.  Else might be a way to force it to look at /boot/ too.

It won't let people choose /home and the install to be the same, I put in checks which block that and tell the user it can't work that way.

The data partition would be on the install drive just as a folder /data/ if they don't choose a separate partition for /data, same too for /home.  So they don't really need to pick either of those, or they can pick one or both of them, and just should have  a directory structure with possible separate mounts as...
/
/data/
/home/arcade/

Are you thinking it might be better to have /home/ as the partition?  The trick with that, is that for the LiveCD to use a drive but also always boot into the liveCD, it checks for /.config/ga.conf on each partition on the system and if that exists it can save the state of the liveCD and reboot directly into the previous setup.  So having /home/arcade/ as an actual separate partition is the easiest way to do that and have it basically be a users home directory entirely.  I guess it could be done though as /home/ and just have arcade/.config/ga.conf checked too, and probably simplify the need for any /data/ directory and use /home/ itself.  Although then you might have people with separate partitions with ROMS or even want to have /data/ be a USB drive or DVD/CDROM mount too.  So definitely plenty to think about there, this should be an interesting thing to restructure perhaps but will need to think about it more.

The xterm -> advmenu launch is mostly because of an issue with X Windows for some reason not exiting clean directly from advmenu.  I'm not sure why, but the only way it will exit back to the console is through launching from an xterm.  I think it might be some issue with the newer frame buffer and/or X Windows version and advmenu doing something kind of messy on exit (it segfaults otherwise).  So seems like it gets by the issue for now, but I agree I wish it didn't show an xterm there although it does help the user know what's going on too and allows some system admin from the xterm on exit.

I was wondering about Alsa setup, I am sure there might be a few bugs still in switching to it from OSS4, I'll have to work on that.  I'm not sure why the sound is odd there, it's great here but then again in Linux we have seen the sound cards do totally different things and what works well for OSS4 on one might not on another and Alsa might do the same on one but not an other.

Do you have error logs at all about what they say when trying Alsa, might help me figure out more, I need to test it too but any output logs of the games and Alsa would help too (the errors they spit out during OSS4 are just a side effect of them expecting Alsa and trying it first, but most things work just switch to try directly on the /dev/dsp interface after first trying Alsa).

I would like the shutdown command to work from advmenu, but it's going to have to probably run shutdown with sudo which would work but I guess it's not doing that.  It seems to check if your the root user and won't allow shutdown otherwise.  Maybe that's a code change that could be done in advmenu directly I am guessing.

Thanks for the feedback, definitely interesting, sounds like grub setup is needing work for sure, and possibly simplifying how /home/arcade and /data/ are done.  The xterm thing is tricky and I have to do some testing with it.  Alsa/OSS4 switching probably aren't working right yet, and maybe altering advmenu source to allow shutdown if we sudo to root privileges.


Update: Found the fix for grub, realized I was doing that in putting it as /vmlinuz :) so fixed that.  Also might have figured out an Alsa issue which might have chosen the wrong interface to unmute the mixer, check you mixer, but sounds like there might be another issue there with Alsa.  I'm still wondering why OSS4 does odd Volume sounds there though, seems like there's something else going on causing that, not sure what though. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 01, 2011, 11:06:10 pm
figured out the advmenu hang issue, patched it to fix that, turned out the terminal check was hanging for some reason and that's why the xterm launch worked (so I don't enable the terminal reset call on exit and it works fine now).  I tested Alsa changing from OSS4 with my fix, and I could do it here so that should work now.  Fixed the grub issue, so that should work correctly now too.  I now know why advmenu won't shutdown the machine, since it can't run the halt command.  I like the menu allowing it to shutdown though since exiting out to the menu is nice, but probably the fix to allow that to work if configured is setting the halt command setuid or some group membership possibly for the arcade user.  I'll look at that here in a bit. 

So should have a new set os ISO's up by tomorrow with those fixes, also now in the Video menu config you can go through and change the 15khz output port used in Grub.  So can go in after install and enable 15khz, (this only works after the install and requires a reboot to activate the change in output), can even enable 15khz on all output interfaces if you want or have one be a TV, other VGA, other CGA 15khz if you really wanted.  It's pretty flexible and hopefully works correctly :), but seems to be a pretty nice option that I had not thought of which really makes it easier to setup the system and change output ports and monitors without knowing grub.conf editing skills (and can do it remotely too).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 02, 2011, 02:40:32 pm
New ISO with many fixes

LiveCD32-Full-MMD-1.393-14b54d6.iso (64 bit one uploading now, should be available too in a few hours)

* This also updates to the 2.6.38-rc3 kernel, to get some interesting fixes they made there
* It's now the Multimedia/Desktop build which includes the web browser and window managers in case one wants to make it a desktop    system too, it's an option in the configuration menu but by default it's just the stripped down AdvanceMenu interface.
* Hopefully makes it easy to switch each output to a different KHz setting or even turn off certain video outputs (that broken laptop may be interesting with this option? can easily turn off the LVDS display for it).  Of course you have to install first and then reboot to enable the changes made.
* Auto login of arcade user after install and reboot, it uses either GDM to do that or a similar method the LiveCD uses for that.
* Hopefully have gotten the grub thing fixed, issue has been that I have to test this on my already setup systems with an extra partition so I don't have a safe way to test grub installation (yet, hopefully I will soon).

Test and send feedback, I think it's getting better :) At least I'm enjoying testing setup/install more than the painful previous methods I was using before the menu system.  I am really curious how the output configuration stuff works for people, seems like an interesting thing that's been missing being able to have a setup menu for all video cards and outputs on the system.  I'm looking at probably redoing a lot of the X setup for the config file it uses next, I'm thinking from the way I did the video output enumerating and stuff it could benefit X setup a lot.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 03, 2011, 02:43:17 am
I'm testing this new patch to see if it helps reducing input lag while fixing the multithreading + vsync issue.

Code: [Select]
diff -Nru a/src/osd/windows/drawdd.c b/src/osd/windows/drawdd.c
--- a/src/osd/windows/drawdd.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/drawdd.c 2011-01-26 23:04:27.000000000 +0100
@@ -457,7 +457,7 @@
  if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X unlocking blit surface\n", (int)result);
 
  // sync to VBLANK
- if ((video_config.waitvsync || video_config.syncrefresh) && window->machine->video().throttled() && (!window->fullscreen || dd->back == NULL))
+ if ((video_config.waitvsync || video_config.syncrefresh) && (!window->fullscreen || dd->back == NULL))
  {
  result = IDirectDraw7_WaitForVerticalBlank(dd->ddraw, DDWAITVB_BLOCKBEGIN, NULL);
  if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X waiting for VBLANK\n", (int)result);
diff -Nru a/src/osd/windows/window.c b/src/osd/windows/window.c
--- a/src/osd/windows/window.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/window.c 2011-01-26 23:04:27.000000000 +0100
@@ -775,7 +775,15 @@
  last_update_time = timeGetTime();
  mtlog_add("winwindow_video_window_update: PostMessage start");
  if (multithreading_enabled)
- PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ {
+ if ((video_config.waitvsync || video_config.syncrefresh) && video_config.mode != VIDEO_MODE_GDI)
+ {
+ window->primlist = primlist;
+ draw_video_contents(window, NULL, FALSE);
+ }
+ else
+ PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ }
  else
  SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
  mtlog_add("winwindow_video_window_update: PostMessage end");

It is intended to be run with syncrefresh, nothrottle, notriplebuffer, multithreading.

Basically it tries to prove if doing the blit in the main thread helps at all to reduce input lag by leaving the window thread free to process input events. So in theory this should be the same that only using throttle (from lag point of view).

I'm testing it here and well... it feels good but not sure if it makes any difference. Tomorrow I'll upload a binary and hopefully your more experienced eyes can judge.


Here's my take on this patch in the SDL side of Mame, not sure but seems like this is essentially the same idea.  I think it helps, but then again it's very subjective and I'm probably not the best person to judge input lag.  It's interesting how from what I can tell in SDL the input and OSD draw is done in a different way so it seems to really not be the same as the Windows OSD in how it can be done better than currently it's done.  At least from what I can tell, this looks like the best way in SDL, because it's essentially allowing any waiting for the Vblank to poll the input still so the OSD thread still effectively runs the input polling and the main thread runs through and then waits for the next Vblank.  Very much like my previous patch I had tried this with but a bit more like the current method they chose in Mame for SDL waitvsync and syncrefresh. 

Also I have done this in 0141, because 0141u1 has such terrible bugs with mario and dkong games in audio that I just can't stand it :).
Hopefully they fix that in the next update, definitely a big bummer.

Code: [Select]
index 02f6cc6..a3603fe 100644
--- a/src/osd/sdl/window.c
+++ b/src/osd/sdl/window.c
@@ -989,8 +989,30 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                        }
                }
 
+               int draw_it = 0;
+               if (video_config.waitvsync && multithreading_enabled) {
+                       osd_ticks_t             event_wait_ticks;
+                       event_wait_ticks = osd_ticks_per_second(); // block at most a second
+                       int count = 0;
+
+                       draw_it = 1;
+                       while (osd_event_wait(window->rendered_event, 1000)) {
+                               count++;
+                               if ((count*1000) >= event_wait_ticks) {
+                                       draw_it = 0;
+                                       break;
+                               }
+
+                               // poll the joystick values here
+                               sdlinput_poll(machine);
+                       }
+               } else {
+                       if (osd_event_wait(window->rendered_event, 0))
+                               draw_it = 1;
+               }
+
                // only render if we have been signalled
-               if (osd_event_wait(window->rendered_event, 0))
+               if (draw_it)
                {
                        worker_param wp;
                        render_primitive_list *primlist;

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 03, 2011, 03:45:29 pm
Hello bitbytebit.

The installation and set up good grub.

No charges directly advmenu, load X with xterm, ignores. xinitrc or. Xclients, where you set the boot? not that used to load files directly, please tell me where that option is configured.

Since ALSA is included in the live, there is no way that I have sound working mame advmenu with osstest etc. .. but when I run mame always the same error ALSA, I tested the card on-board sound and a sound blaster 128.

The user can not use arcade shutdown, no permits.

Because GDM has been reprogrammed?

use gdm? if not then inittab will loging arcade user to menu system
With this question, GroovyArcade is configured to boot in X and tty's advmenu asking logins, and if not out gasetup tty1 and cargo X advmenu, no (although advmenu not load, just X with xterm)?

logs:
Code: [Select]
ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default
OpenGL: PBO not supported
mame: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.
Aborted

arcade@GroovyArcade ~ $ mame robby
ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default
OpenGL: PBO not supported
mame: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.
Aborted

Thank
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 03, 2011, 04:04:14 pm
Hello bitbytebit.

The installation and set up good grub.

No charges directly advmenu, load X with xterm, ignores. xinitrc or. Xclients, where you set the boot? not that used to load files directly, please tell me where that option is configured.


Did you try to do the install without GDM?  It might be GDM, I tested the console boot option and it at least enters the menu on boot like the liveCD does, and can start up X Windows from there with the Start Front End/WM option fine.  It uses .xinitrc for that method, and should have .Xclients there for GDM.  GDM should autologin as the arcade user and start advmenu automatically.  The /bin/bashlogin file is what is launched on the first terminal if you don't choose the GDM startup option, and it launches /root/.bash_profile which contains the gasetup script command.  I think there's a way though to have that first console startup X as the arcade user instead of root, although I like the menu to fall back to and configure stuff, although need a setting to override that I guess to boot directly into everything without needing GDM.


Since ALSA is included in the live, there is no way that I have sound working mame advmenu with osstest etc. .. but when I run mame always the same error ALSA, I tested the card on-board sound and a sound blaster 128.

Where do you you change it to alsa at, during live install or after?  You should try either one, it might need to be done after install when rebooted, or it might be better before install, I'm not sure.  Also check alsamixer to make sure it is really working, you can't really go back from Alsa to OSS4 though, that's one limitation (at least need to reboot to unload the modules).



The user can not use arcade shutdown, no permits.

Because GDM has been reprogrammed?

I know how to fix that actually, it's doesn't work currently because the halt command isn't allowed to be ran by the arcade user.  I should have a way to work around that, will try to figure that out soon.



logs:
Code: [Select]
ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default
OpenGL: PBO not supported
mame: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.
Aborted

arcade@GroovyArcade ~ $ mame robby
ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default
OpenGL: PBO not supported
mame: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.
Aborted


what does the output of `aplay -l` show you on your system?  Some applications complain about alsa missing but still work, so it's not always a problem.  does alsamixer work, or ossmix? 



Thank

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 03, 2011, 04:36:16 pm
Quote
Did you try to do the install without GDM?  It might be GDM, I tested the console boot option and it at least enters the menu on boot like the liveCD does, and can start up X Windows from there with the Start Front End/WM option fine.  It uses .xinitrc for that method, and should have .Xclients there for GDM.  GDM should autologin as the arcade user and start advmenu automatically.  The /bin/bashlogin file is what is launched on the first terminal if you don't choose the GDM startup option, and it launches /root/.bash_profile which contains the gasetup script command.  I think there's a way though to have that first console startup X as the arcade user instead of root, although I like the menu to fall back to and configure stuff, although need a setting to override that I guess to boot directly into everything without needing GDM.

Where do you you change it to alsa at, during live install or after?  You should try either one, it might need to be done after install when rebooted, or it might be better before install, I'm not sure.  Also check alsamixer to make sure it is really working, you can't really go back from Alsa to OSS4 though, that's one limitation (at least need to reboot to unload the modules).

Yes, I tried to do and about 5 or 6 installations, but I always feel the same, I used gdm gdm and no, I left the section without setting up and configuring sound with alsa or oss, I configured after installing alsa oss frontend etc .. and always the same, errors and does not load ALSA advmenu, only X and xterm.

I've seen that in root or no files .bashr... arcade .... That would be correct?
Like I said before I have configured with oss sound and X advmenu do the osstest and works well, also works the ossxmix me, but still the same.
Now after many Cambion between alsa and oss, I could do duncionar alsamixer, but continues to suckle failures, does not run and gives this error.
Code: [Select]
OpenGL: PBO not supported
mame: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.

That may be happening? may be to include oss and alsa at the same time?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 03, 2011, 04:39:07 pm
Quote
Did you try to do the install without GDM?  It might be GDM, I tested the console boot option and it at least enters the menu on boot like the liveCD does, and can start up X Windows from there with the Start Front End/WM option fine.  It uses .xinitrc for that method, and should have .Xclients there for GDM.  GDM should autologin as the arcade user and start advmenu automatically.  The /bin/bashlogin file is what is launched on the first terminal if you don't choose the GDM startup option, and it launches /root/.bash_profile which contains the gasetup script command.  I think there's a way though to have that first console startup X as the arcade user instead of root, although I like the menu to fall back to and configure stuff, although need a setting to override that I guess to boot directly into everything without needing GDM.

Where do you you change it to alsa at, during live install or after?  You should try either one, it might need to be done after install when rebooted, or it might be better before install, I'm not sure.  Also check alsamixer to make sure it is really working, you can't really go back from Alsa to OSS4 though, that's one limitation (at least need to reboot to unload the modules).

Yes, I tried to do and about 5 or 6 installations, but I always feel the same, I used gdm gdm and no, I left the section without setting up and configuring sound with alsa or oss, I configured after installing alsa oss frontend etc .. and always the same, errors and does not load ALSA advmenu, only X and xterm.

I've seen that in root or no files .bashr... arcade .... That would be correct?
Like I said before I have configured with oss sound and X advmenu do the osstest and works well, also works the ossxmix me, but still the same.
Now after many Cambion between alsa and oss, I could do duncionar alsamixer, but continues to suckle failures, does not run and gives this error.
Code: [Select]
OpenGL: PBO not supported
mame: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.

That may be happening? may be to include oss and alsa at the same time?


How are you starting up X?   Are you launching it from the menu option #7 or from the command line?   
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 03, 2011, 04:42:27 pm
it now if I understand, X automatically runs xterm, if you want to use from the HD mounting procedures gasetup I can not run the option 7 as it is the X server running
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 03, 2011, 04:47:24 pm
I do not understand what you mean

Are you launching into advmenu from the menu option, or from the command line?  I'm wondering, because what your seeing sounds like what would happen if you were the root user instead of the arcade user.  It is just launching an xterm, and there's no .xinitrc for your user too. 

What does your /home/arcade/ directory look like with `ls -altr`

What does / look like with `ls -altr`

I'm thinking either the setup is getting confused and not setting up /home/arcade properly or your somehow launching X Windows as the root user.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 03, 2011, 04:55:19 pm
root
Code: [Select]
/root/:
total 44
-rw-r--r--  1 root root 18642 Dec 12 06:48 .fvwm2rc
-rwxr-xr-x  1 root root  1228 Jan 31 20:03 compile_kernel.sh
-rw-r--r--  1 root root  6369 Feb  2 06:15 .Xdefaults
drwxr-xr-x 20 root root  4096 Feb  3 16:04 ..
-rw-------  1 root root  1976 Feb  3 16:40 .viminfo
drwxr-xr-x  2 root root  4096 Feb  3 16:52 .

home/arcade
Code: [Select]
/home/arcade/:
total 132
drwxr-xr-x  2 arcade arcade  4096 Aug 18 17:23 fonts
drwxr-xr-x  2 arcade arcade  4096 Dec  1 05:42 .zsnes
drwxr-xr-x  2 arcade arcade  4096 Dec  1 05:42 .stella
drwxr-xr-x  2 arcade arcade  4096 Dec  1 05:42 .mess
drwxr-xr-x  2 arcade arcade  4096 Dec  1 05:42 .mame
drwxr-xr-x  2 arcade arcade  4096 Dec  1 05:42 .gens
drwxr-xr-x  2 arcade arcade  4096 Dec  1 05:42 .fvwm
-rw-r--r--  1 arcade arcade  6369 Dec  1 05:42 .Xdefaults
drwxr-xr-x  2 arcade arcade  4096 Dec  1 17:03 hi
drwxr-xr-x  6 arcade arcade  4096 Dec 10 00:18 .wahcade
drwxr-xr-x  4 arcade arcade  4096 Dec 28 22:23 emulators
drwxr-xr-x  2 arcade arcade  4096 Jan 25 13:53 .nestopia
drwxr-xr-x  2 arcade arcade  4096 Jan 25 14:35 ini
-rw-r--r--  1 arcade arcade   272 Jan 31 17:29 .emptycursor
drwxr-xr-x  2 arcade arcade  4096 Feb  1 22:00 .advance
-rw-r--r--  1 arcade arcade  6081 Feb  2 04:21 mame.ini
-rw-r--r--  1 arcade arcade  6038 Feb  2 04:22 mess.ini
-rw-r--r--  1 arcade arcade 18447 Feb  2 05:07 .fvwm2rc
drwxr-xr-x  3 root   root    4096 Feb  2 06:15 ..
lrwxrwxrwx  1 arcade arcade     8 Feb  3 15:58 .Xclients -> .xinitrc
-rw-r--r--  1 root   root      34 Feb  3 16:03 switchres.conf
-rw-r--r--  1 arcade arcade   107 Feb  3 16:03 .xinitrc
drwxr-xr-x  3 arcade arcade  4096 Feb  3 16:45 .config
-rw-------  1 arcade arcade   123 Feb  3 16:46 .Xauthority
-rw-------  1 arcade arcade    28 Feb  3 16:46 .dmrc
-rw-r--r--  1 arcade arcade    94 Feb  3 16:46 .xsession-errors
-rw-r--r--  1 root   root       0 Feb  3 16:52 logs
drwxr-xr-x 16 arcade arcade  4096 Feb  3 16:52 .
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 03, 2011, 05:05:30 pm
it now if I understand, X automatically runs xterm, if you want to use from the HD mounting procedures gasetup I can not run the option 7 as it is the X server running
How does it work from the liveCD running things, when not installing to hard drive?  You should be able to run the X Windows from the menu in the liveCD.  Once installed, if you use GDM, then you won't be able to.  If installed, and no GDM, then it should be using the menu to launch X Windows.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 03, 2011, 05:16:44 pm
With the LiveCD without installing and 7 of the menu option runs gasetup advmenu X but fails to load a game alsa etc ...
With the option installed and Livecd 7 runs and fails advmenu X mame.
It seems the arcade board is fine as is. xinitr. Xclient etc. .. but I see the bash and not if it takes, I copied all bash / etc / skel, but does not work.

How to do autologin? I used mingetty, here it is?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 03, 2011, 05:44:32 pm
I've noticed that if I kill the process gdm and X from the user terminal arcade run startx advmenu charge me directly, so the problem we have with gdm as it does not load the file that xinitrc, but still gives the same error with alsa and OpenGL: PBO not supported
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 03, 2011, 05:55:16 pm
I've noticed that if I kill the process gdm and X from the user terminal arcade run startx advmenu charge me directly, so the problem we have with gdm as it does not load the file that xinitrc, but still gives the same error with alsa and OpenGL: PBO not supported
Try without gdm since i suspect gdm to be non-working right now after an install, which is the only place it is used if chosen. 

the OpenGL message is not an error, it means your video card doesn't support the PBO stuff, should still be ok without that.  Also the alsa messages are probably just warnings I think, mame likes to try and use alsa first before going to oss.  Which possibly Alsa for some reason isn't installing right so probably breaks OSS but also Alsa doesn't get setup right.

I'm not sure why it's having the Alsa issue, I'll have to double check here again.  Also the gdm probably may be something I need to alter in how it's setup.  if you look in the /etc/inittab file at the bottom it'll show on console (c1) the agetty process and how it's used to startup the first console (only if you aren't using gdm, else gdm just starts).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 03, 2011, 06:09:48 pm
By using alsaconf recognize the modem, I created the file and start alsa.conf in modprobe to load the driver but it gives error
error failed to load necessary drivers.

Once after trying many times to configure sound from alsaconfig gasetup or I could use alsamixer but no mame, zsnes works but I have not tried games.

Hope you whistle for something.


Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 03, 2011, 06:21:45 pm
I'm testing the new one and works perfect here, only tested from live-cd, will probably install this eventually to get a better knowlegde of it. I'm using OSS all the time as ALSA never worked for me (not tested lately), but I remember seeing those ALSA errors VeS has when loading Mame even with OSS selected and fully working. Maybe VeS board only works with OSS as mine? Tomorrow I'll test the network stuff to see if I can put some roms there.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 03, 2011, 06:35:01 pm
Hi Calamity, are you saying that you can use the last 2 live versions without problems? I've tried to disable the sound card of the plate and put a sound blaster 128 but there is no way, tomorrow I'll try with 5.1.
Anyway the mounting procedures have you successfully loaded advmenu alone, without having to type in xterm?
That sound card and motherboard have?.

Bitetibe mingetty've tried to use instead of gdm or xdm etc. .. to do single user login and so charged the X from the bashrc? this could save you problems?

Greetings.


Code: [Select]
Hola Calamity, estas diciendo que puedes usar la ultimas 2 versiones de la live sin problemas? yo he probado a desactivar la tarjeta de sonido de la placa y poner una sound blaster 128 pero no hay manera, mańana lo intentare con una 5.1.
De todas formas las has instaldo, te carga correctamente advmenu solo, sin tener que escribirlo en el xterm?
Que tarjeta de sonido y placa tienes?.

Bitetibe has probado a usar mingetty en lugar de gdm o xdm etc.. para que haga login el usuario solo y asi carge las X desde el bashrc ? esto podria ahorrar problemas?

Saludos.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 03, 2011, 06:44:12 pm
Yes, these last versions work here flawlessly, but I only use OSS and always run from the live-cd. The audio card is an integrated one, motherboard is an Asrock, will give you the details.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 02:21:52 am
Okay, so oss and alsa not integrate well with my sound card, either because the driver missing or did not correctly identified.
You could try installing to see if you think the same thing to me, you do not load automatically advmenu.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 03:12:57 am
Okay, so oss and alsa not integrate well with my sound card, either because the driver missing or did not correctly identified.
You could try installing to see if you think the same thing to me, you do not load automatically advmenu.

I tested the GDM boot option tonight and yes I see the problem now.  I will fix that, does look like if fixed, it will boot into advmenu nicely.  At least I see it on the build I made, but still should work fine if you don't choose GDM login on install (will go to the setup menu still, but won't start only an xterm that way).  Are you seeing a login when booting, graphical one, and then an xterm and some other odd apps?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 03:19:55 am
Hi bi, when I boot I have not log in, start automatically, but only loads xterm.
What most worries me is the issue of alsa and oss, you could see something like that? you may be missing the kernel module? or detection fails?


Mingetty

http://dev.gentoo.org/~cardoe/mythtv/autostart.html (http://dev.gentoo.org/~cardoe/mythtv/autostart.html)



Thank
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 03:33:26 am
Hi bi, when I boot I have not log in, start automatically, but only loads xterm.
What most worries me is the issue of alsa and oss, you could see something like that? you may be missing the kernel module? or detection fails?



Thank

Yeah I have a much better way to login automatically now, like you used, I'm going to use mingetty and setup a test and it worked well.  I could in theory reboot after exit from advmenu too now.  Instead for now I launch gasetup with sudo as root, but that can be changed in the new /home/arcade/.bash_login very easily

Basically:

/etc/inittab: (change)
c1:12345:respawn:/sbin/agetty 38400 tty1 linux

to

c1:12345:respawn:/sbin/mingetty --autologin arcade --noclear tty1

and create a new file /home/arcade/.bash_profile:
#!/bin/bash
export PATH=/usr/games/bin:$PATH
startx
sudo gasetup # could change this to sudo /sbin/poweroff to halt system



So that seems to work here, oh and also run this...

/etc/init.d/xdm stop

and/or

rc-setup del xdm default



I'm not sure why the audio isn't working there, you did have OSS4 audio though before didn't you?  Possibly not touching any of the audio settings on install, see if it works that way.  It may be your setting up Alsa or OSS4 (you don't have to setup OSS4 at all unless you already setup Alsa and rebooted).

Thanks,
Chris

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 04:23:04 am
You're right, my problem is not related to your software, i will try to give as much informations as i can to Alex.

 I've posted a thread on a french forum about your software, seems that you will see more froggies around near  ::)

Something interesting, I have seen the same half screen issue finally.  Well I have a Radeon 5450 CEDAR model card I just got and am testing it.  Well it does the exact same thing in the console, and it's because it won't support interlace. A 320x240 console works and fits but of course the menu system doesn't fit on that at all.  So I suspect it's the same issue in both cards. 

Also it's interesting, since these cards don't work at all in Windows with Soft15khz.  They seem to even have probed modelines in Linux too that my methods for the default ones and framebuffer stuff doesn't get rid of.  So that's annoying of them, but besides that it does do 15khz modes so it isn't a dotclock limitation or anything.  Yet it seems they don't have the interrupt/vblank support yet so they don't do vsync and page flipping at all.  I'm sure it's just not been implemented yet by Alex, the ATI developer.  So at least I can recreate your issue, but I also suspect it may be either interlacing problems with both cards, else maybe they can't do interlacing.  I am digging into where these probed modes come from, so I can change the kernel to ignore them on a CGA 15khz output.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 04, 2011, 05:31:42 am
Something interesting, I have seen the same half screen issue finally.  Well I have a Radeon 5450 CEDAR model card I just got and am testing it.  Well it does the exact same thing in the console, and it's because it won't support interlace. A 320x240 console works and fits but of course the menu system doesn't fit on that at all.  So I suspect it's the same issue in both cards. 

So you are not seeing the usual interlace trembling there?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 05:45:44 am
Something interesting, I have seen the same half screen issue finally.  Well I have a Radeon 5450 CEDAR model card I just got and am testing it.  Well it does the exact same thing in the console, and it's because it won't support interlace. A 320x240 console works and fits but of course the menu system doesn't fit on that at all.  So I suspect it's the same issue in both cards. 

So you are not seeing the usual interlace trembling there?

Nope, it's weird because it's a 15khz display but half the screen is cut off for it at 640x480, yet with 320x240 progression it's perfect.  Also the 15khz modeline setting is perfect in X Windows for games, but they run 400+ percent speed of course because the vblank interrupt isn't working right.  Then you've got the probed modes all there just in the way, although mostly just are going to hit the 320x240 games and such.  So it seems these newer Radeon cards technically can do it, we just have to ignore these probed modes and possibly can't do interlace on them, or it's not implemented yet like the vblank isn't.  It is really new, Alex just got CEDAR chips working at all as of last November.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 09:45:49 am
Hello bitbytebit, unless you want to get out of X by mistake, you can include this option in the bashrc

Code: [Select]
while true
do
startx
done

As I can reinstall alsa without having to install the kernel?


Thank
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 10:17:21 am
Hello bitbytebit, unless you want to get out of X by mistake, you can include this option in the bashrc

Code: [Select]
while true
do
startx
done

As I can reinstall alsa without having to install the kernel?


Thank


Try this ISO LiveCD32-Full-1.400-44b3297.iso

This new version should boot straight into advmenu as the arcade user after install, I removed gdm completely.  Also a improved the way the menu of gasetup does the startup/quit and info messages.  Also I went back to the stripped down version for now, with just what we need for emulation, so not having to upload/download extra.

Do you know about the portage system, how to run emerge?  I have Alsa work when I run the install it option in the menu, so I'm guessing either your sound card isn't compatible or it's for some reason not finding it for the mixer unmute or similar. 

What does `aplay -l` show? 
what does `ossinfo` show?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 10:58:06 am
Hi, I have the solution for apgar the pc from the user advmenu arcade.

Code: [Select]
groupadd shutdown
Code: [Select]
add arcade to the group shutdown
check this created the user group and has arcade
Code: [Select]
shutdown:x:1002:arcade...
now with the command visudo, add the following lines

Code: [Select]
%shutdown ALL=(root) NOPASSWD: /sbin/reboot
%shutdown ALL=(root) NOPASSWD: /sbin/halt
%shutdown ALL=(root) NOPASSWD: /sbin/shutdown

And finally create the alias .bashrc

Code: [Select]
alias shutdown = ' sudo shutdown -h now'
alias shutdown = ' sudo halt '
alias halt = ' sudo halt'
alias halt = ' sudo shutdown -h now'


This all tested from the console, since I have done with a virtual machine, so I need to check that advmenu off the pc.


Thank



Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 04:03:35 pm

Livecd OSS
aplay -l
Code: [Select]

ossinfo
Code: [Select]
Version info: OSS 4.2 (b 2003/201101031428) (0x00040100) GPL
Platform: Linux/i686 2.6.38-rc3+ #1 SMP Thu Feb 3 19:09:24 CST 2011 (GroovyArcade)

Number of audio devices: 1
Number of audio engines: 6
Number of MIDI devices: 0
Number of mixer devices: 1


Device objects
 0: osscore0 OSS core services
 1: oss_ich0 SiS 7012 interrupts=3232 (3232)
 2: oss_usb0 USB audio core services

MIDI devices (/dev/midi*)

Mixer devices
 0: ICH AC97 Mixer (ALC655) (Mixer 0 of device object 1)

Audio devices
SiS 7012                          /dev/oss/oss_ich0/pcm0  (device index 0)

Nodes
  /dev/dsp -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_in -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_out -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_ac3 -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_mmap -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_multich -> /dev/oss/oss_ich0/pcm0

Livecd ALSA
aplay -l
Code: [Select]
**** List of PLAYBACK Hardware Devices ****
card 0: SI7012 [SiS SI7012], device 0: Intel ICH [SiS SI7012]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

ossinfo
Code: [Select]
Version info:   (0x00000000)
Platform: Linux/i686 2.6.38-rc3+ #1 SMP Thu Feb 3 19:09:24 CST 2011 (GroovyArcade)

Number of audio devices: 0
Number of audio engines: 0
Number of MIDI devices: 0
Number of mixer devices: 0


Device objects

MIDI devices (/dev/midi*)

Mixer devices

Audio devices

Nodes
  /dev/dsp_in -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_out -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_ac3 -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_mmap -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_multich -> /dev/oss/oss_ich0/pcm0

Install OSS
aplay -l
Code: [Select]

Install OSS
ossinfo
Code: [Select]
Version info: OSS 4.2 (b 2003/201101031428) (0x00040100) GPL
Platform: Linux/i686 2.6.38-rc3+ #1 SMP Thu Feb 3 19:09:24 CST 2011 (GroovyArcade)

Number of audio devices: 1
Number of audio engines: 6
Number of MIDI devices: 0
Number of mixer devices: 1


Device objects
 0: osscore0 OSS core services
 1: oss_ich0 SiS 7012 interrupts=2134 (2134)
 2: oss_usb0 USB audio core services

MIDI devices (/dev/midi*)

Mixer devices
 0: ICH AC97 Mixer (ALC655) (Mixer 0 of device object 1)

Audio devices
SiS 7012                          /dev/oss/oss_ich0/pcm0  (device index 0)

Nodes
  /dev/dsp -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_in -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_out -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_ac3 -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_mmap -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_multich -> /dev/oss/oss_ich0/pcm0

Install ALSA
aplay -l
Code: [Select]
**** List of PLAYBACK Hardware Devices ****
card 0: SI7012 [SiS SI7012], device 0: Intel ICH [SiS SI7012]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

ossinfo
Code: [Select]
Version info:   (0x00000000)
Platform: Linux/i686 2.6.38-rc3+ #1 SMP Thu Feb 3 19:09:24 CST 2011 (GroovyArcade)

Number of audio devices: 0
Number of audio engines: 0
Number of MIDI devices: 0
Number of mixer devices: 0


Device objects

MIDI devices (/dev/midi*)

Mixer devices

Audio devices

Nodes
  /dev/dsp_in -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_out -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_ac3 -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_mmap -> /dev/oss/oss_ich0/pcm0
  /dev/dsp_multich -> /dev/oss/oss_ich0/pcm0


Hello, here are the results of alsa and oss, I think as you say the sound is no problem, but the ArcadeVGA, refuses to acknowledge (actualizastes the kernel, right?) and therefore does not load the game, it is possible right? because I've tried other vga ati pci express in other pc's and if the games work.
I could not find the file or radeon.o radeon.ko, only a ati-agp.ko may be missing that module? which is actually charging for the AVGA?


By the way does not create the file bashrc bashr_profile nor with the start command, because you put it in path in bash? should not only recognize all routes?

On the subject of the pc off, advmenu not let you use the command says you need to be root, but if you put the command works fine, no error if this latest version or not, because when I think the aka I always put the leaves alone are eliminated.


Thank

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 04:34:02 pm
Hello, here are the results of alsa and oss, I think as you say the sound is no problem, but the ArcadeVGA, refuses to acknowledge (actualizastes the kernel, right?) and therefore does not load the game, it is possible right? because I've tried other vga ati pci express in other pc's and if the games work.
I could not find the file or radeon.o radeon.ko, only a ati-agp.ko may be missing that module? which is actually charging for the AVGA?


By the way does not create the file bashrc bashr_profile nor with the start command, because you put it in path in bash? should not only recognize all routes?

On the subject of the pc off, advmenu not let you use the command says you need to be root, but if you put the command works fine, no error if this latest version or not, because when I think the aka I always put the leaves alone are eliminated.


Thank



The radeon and drm are built into this kernel, they are not modules, that's how they load the 15khz frame buffer right after grub.

Which ArcadeVGA card version are you using?  In theory it should work, unless it's an AVGA 3000, those need to be flashed into a normal Radeon card in Linux for DRM/KMS and interrupts/vblank to work.

Do you have logs of /var/log/Xorg.0.log when it doesn't work? 

The audio looks like it should work, everything is configured right for Alsa and OSS it seems.

the .bash_profile is used in /home/arcade/ , the autologin ignores .bashrc and that isn't really executed.   
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 04:39:01 pm
Hello AVGA I use is 9250, with the kernel version 2.6.38-rc2+ ,but with the new rc +3 no way it will work, the X function but loading mame not think that's why the error was radeon .....
Code: [Select]
penGL: PBO not supported
mame: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.
Aborted

The bash_profile not believe it has to be done manually.


You could put the old kernel to install it myself, and so that it works or not?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 04:40:41 pm
Hello AVGA I use is 9250, with the kernel version 2.6.38-rc2+ ,but with the new rc +3 no way it will work, the X function but loading mame not think that's why the error was radeon .....
Code: [Select]
OpenGL: PBO not supported
mame: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.
Aborted

The bash_profile not believe it has to be done manually.


You could put the old kernel to install it myself, and so that it works or not?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 04:42:17 pm
Hello AVGA I use is 9250, with the kernel version 2.6.38-rc2+ ,but with the new rc +3 no way it will work, the X function but loading mame not think that's why the error was radeon .....
Code: [Select]
penGL: PBO not supported
mame: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.
Aborted

The bash_profile not believe it has to be done manually.


You could put the old kernel to install it myself, and so that it works or not?

Can you get the dmesg log, and also Xorg.0.log for it?  Those logs would be useful to see what is going on.

You can probably take the old installation and use the kernel from there, the /boot/ /lib/modules/ directories,
see if that alone fixes it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 04:43:00 pm
Ok, I'll try and take the logs to
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 04:54:32 pm
Ok, I'll try and take the logs to

Also output of glxinfo

Also run glxgears and have it go full screen, see if the same thing happens there.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 05:15:47 pm
Hi bit has not put the boot works and modulons new kernel loaded with g2 + but still the same, I put the logs.

Xorg.0.log 1 Part
Code: [Select]
[   361.720]
X.Org X Server 1.9.2
Release Date: 2010-10-30
[   361.732] X Protocol Version 11, Revision 0
[   361.735] Build Operating System: Linux 2.6.38-rc1 i686 Gentoo
[   361.739] Current Operating System: Linux GroovyArcade 2.6.38-rc2+ #1 SMP Mon Jan 24 22:01:58 CST 2011 i686
[   361.746] Kernel command line: root=/dev/sda1 init=/boot/linuxrc initrd udev nodevfs CGAVGA video=VGA-1:640x480ec
[   361.754] Build Date: 31 January 2011  12:08:30PM
[   361.758]  
[   361.762] Current version of pixman: 0.20.0
[   361.765] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   361.773] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   361.785] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb  4 17:08:24 2011
[   361.789] (==) Using config file: "/etc/X11/xorg.conf"
[   361.792] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   361.797] (**) Option "defaultserverlayout" "Arcade Cabinet"
[   361.797] (**) ServerLayout "Arcade Cabinet"
[   361.797] (**) |-->Screen "Screen0" (0)
[   361.797] (**) |   |-->Monitor "DVI-0"
[   361.797] (**) |   |-->Device "Card0"
[   361.797] (**) |-->Input Device "Mouse0"
[   361.797] (**) |-->Input Device "Keyboard0"
[   361.797] (**) Option "DontZap" "off"
[   361.797] (**) Option "DontZoom" "on"
[   361.797] (**) Option "AllowMouseOpenFail" "true"
[   361.797] (**) Option "BlankTime" "0"
[   361.797] (**) Option "StandbyTime" "0"
[   361.797] (**) Option "SuspendTime" "0"
[   361.797] (**) Option "OffTime" "0"
[   361.797] (**) Option "NoPM" "True"
[   361.797] (**) Option "AIGLX" "on"
[   361.797] (==) Automatically adding devices
[   361.797] (==) Automatically enabling devices
[   361.798] (==) FontPath set to:
/usr/share/fonts/misc/,
/usr/share/fonts/TTF/,
/usr/share/fonts/OTF/,
/usr/share/fonts/Type1/,
/usr/share/fonts/100dpi/,
/usr/share/fonts/75dpi/
[   361.798] (==) ModulePath set to "/usr/lib/xorg/modules"
[   361.798] (**) Extension "Composite" is enabled
[   361.798] (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[   361.798] (WW) Disabling Mouse0
[   361.798] (WW) Disabling Keyboard0
[   361.798] (II) Loader magic: 0x81f2d60
[   361.798] (II) Module ABI versions:
[   361.798] X.Org ANSI C Emulation: 0.4
[   361.798] X.Org Video Driver: 8.0
[   361.798] X.Org XInput driver : 11.0
[   361.798] X.Org Server Extension : 4.0
[   361.799] (--) PCI:*(0:1:0:0) 1002:5964:1787:5964 rev 1, Mem @ 0xd0000000/134217728, 0xe5000000/65536, I/O @ 0x00009000/256, BIOS @ 0x????????/131072
[   361.799] (--) PCI: (0:1:0:1) 1002:5d44:1787:5965 rev 1, Mem @ 0xd8000000/134217728, 0xe5010000/65536
[   361.799] (II) LoadModule: "extmod"
[   361.799] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[   361.800] (II) Module extmod: vendor="X.Org Foundation"
[   361.800] compiled for 1.9.2, module version = 1.0.0
[   361.800] Module class: X.Org Server Extension
[   361.800] ABI class: X.Org Server Extension, version 4.0
[   361.800] (II) Loading extension MIT-SCREEN-SAVER
[   361.800] (II) Loading extension XFree86-VidModeExtension
[   361.800] (II) Loading extension XFree86-DGA
[   361.800] (II) Loading extension DPMS
[   361.800] (II) Loading extension XVideo
[   361.800] (II) Loading extension XVideo-MotionCompensation
[   361.800] (II) Loading extension X-Resource
[   361.800] (II) LoadModule: "dbe"
[   361.800] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
[   361.800] (II) Module dbe: vendor="X.Org Foundation"
[   361.800] compiled for 1.9.2, module version = 1.0.0
[   361.800] Module class: X.Org Server Extension
[   361.800] ABI class: X.Org Server Extension, version 4.0
[   361.800] (II) Loading extension DOUBLE-BUFFER
[   361.800] (II) LoadModule: "glx"
[   361.800] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   361.800] (II) Module glx: vendor="X.Org Foundation"
[   361.800] compiled for 1.9.2, module version = 1.0.0
[   361.800] ABI class: X.Org Server Extension, version 4.0
[   361.800] (**) AIGLX enabled
[   361.800] (II) Loading extension GLX
[   361.801] (II) LoadModule: "record"
[   361.801] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so
[   361.801] (II) Module record: vendor="X.Org Foundation"
[   361.801] compiled for 1.9.2, module version = 1.13.0
[   361.801] Module class: X.Org Server Extension
[   361.801] ABI class: X.Org Server Extension, version 4.0
[   361.801] (II) Loading extension RECORD
[   361.801] (II) LoadModule: "dri"
[   361.801] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so
[   361.801] (II) Module dri: vendor="X.Org Foundation"
[   361.801] compiled for 1.9.2, module version = 1.0.0
[   361.801] ABI class: X.Org Server Extension, version 4.0
[   361.801] (II) Loading extension XFree86-DRI
[   361.801] (II) LoadModule: "dri2"
[   361.801] (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
[   361.802] (II) Module dri2: vendor="X.Org Foundation"
[   361.802] compiled for 1.9.2, module version = 1.2.0
[   361.802] ABI class: X.Org Server Extension, version 4.0
[   361.802] (II) Loading extension DRI2
[   361.802] (II) LoadModule: "radeon"
[   361.802] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[   361.802] (II) Module radeon: vendor="X.Org Foundation"
[   361.802] compiled for 1.9.2, module version = 6.13.99
[   361.802] Module class: X.Org Video Driver
[   361.802] ABI class: X.Org Video Driver, version 8.0
[   361.802] (II) RADEON: Driver for ATI Radeon chipsets:
ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI),
ATI Radeon Mobility X300 (M24) 3152 (PCIE),
ATI FireGL M24 GL 3154 (PCIE), ATI FireMV 2400 3155 (PCI),
ATI Radeon X600 (RV380) 3E50 (PCIE),
ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136,
ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP),
ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP),
ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP),
ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP),
ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP),
ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP),
ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650,
ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237,
ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP),
ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337,
ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI),
ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP),
ATI Radeon X800PRO (R420) JI (AGP),
ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP),
ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP),
ATI Radeon Mobility 9800 (M18) JN (AGP),
ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP),
ATI Radeon X800 VE (R420) JT (AGP), ATI Radeon X850 (R480) (AGP),
ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP),
ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP),
ATI Radeon Mobility M7 LW (AGP),
ATI Mobility FireGL 7800 M7 LX (AGP),
ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP),
ATI FireGL Mobility 9000 (M9) Ld (AGP),
ATI Radeon Mobility 9000 (M9) Lf (AGP),
ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9700 Pro ND (AGP),
ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP),
ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP),
ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP),
ATI Radeon 9800XT NJ (AGP),
ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP),
ATI Radeon Mobility 9600 (M10) NQ (AGP),
ATI Radeon Mobility 9600 (M11) NR (AGP),
ATI Radeon Mobility 9600 (M10) NS (AGP),
ATI FireGL Mobility T2 (M10) NT (AGP),
ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP),
ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP),
ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP),
ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI),
ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI),
ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI),
ATI Radeon Mobility X300 (M22) 5460 (PCIE),
ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE),
ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE),
ATI Radeon X800PRO (R423) UI (PCIE),
ATI Radeon X800LE (R423) UJ (PCIE),
ATI Radeon X800SE (R423) UK (PCIE),
ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE),
ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE),
ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE),
ATI FireGL unknown (R423) UR (PCIE),
ATI FireGL unknown (R423) UT (PCIE),
ATI Mobility FireGL V5000 (M26) (PCIE),
ATI Mobility FireGL V5000 (M26) (PCIE),
ATI Mobility Radeon X700 XL (M26) (PCIE),
ATI Mobility Radeon X700 (M26) (PCIE),
ATI Mobility Radeon X700 (M26) (PCIE),
ATI Radeon X550XTX 5657 (PCIE), ATI Radeon 9100 IGP (A5) 5834,
ATI Radeon Mobility 9100 IGP (U3) 5835,
ATI Radeon XPRESS 200 5954 (PCIE),
ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP),
ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP),
ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI),
ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE),
ATI Radeon XPRESS 200M 5975 (PCIE),
ATI Radeon XPRESS 200 5A41 (PCIE),
ATI Radeon XPRESS 200M 5A42 (PCIE),
ATI Radeon XPRESS 200 5A61 (PCIE),
ATI Radeon XPRESS 200M 5A62 (PCIE),
ATI Radeon X300 (RV370) 5B60 (PCIE),
ATI Radeon X600 (RV370) 5B62 (PCIE),
ATI Radeon X550 (RV370) 5B63 (PCIE),
ATI FireGL V3100 (RV370) 5B64 (PCIE),
ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE),
ATI Radeon Mobility 9200 (M9+) 5C61 (AGP),
ATI Radeon Mobility 9200 (M9+) 5C63 (AGP),
ATI Mobility Radeon X800 XT (M28) (PCIE),
ATI Mobility FireGL V5100 (M28) (PCIE),
ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE),
ATI Radeon X850 XT PE (R480) (PCIE),
ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE),
ATI unknown Radeon / FireGL (R480) 5D50 (PCIE),
ATI Radeon X850 XT (R480) (PCIE),
ATI Radeon X800XT (R423) 5D57 (PCIE),
ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE),
ATI Radeon X700 PRO (RV410) (PCIE),
ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE),
ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X1800,
ATI Mobility Radeon X1800 XT, ATI Mobility Radeon X1800,
ATI Mobility FireGL V7200, ATI FireGL V7200, ATI FireGL V5300,
ATI Mobility FireGL V7100, ATI Radeon X1800, ATI Radeon X1800,
ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800,
ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505,
ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL,
ATI Mobility Radeon X1400, ATI Radeon X1300/X1550,
ATI Radeon X1550 64-bit, ATI Mobility Radeon X1300,
ATI Mobility Radeon X1300, ATI Mobility Radeon X1300,
ATI Mobility Radeon X1300, ATI Radeon X1300, ATI Radeon X1300,
ATI RV505, ATI RV505, ATI FireGL V3300, ATI FireGL V3350,
ATI Radeon X1300, ATI Radeon X1550 64-bit, ATI Radeon X1300/X1550,
ATI Radeon X1600, ATI Radeon X1300/X1550, ATI Mobility Radeon X1450,
ATI Radeon X1300/X1550, ATI Mobility Radeon X2300,
ATI Mobility Radeon X2300, ATI Mobility Radeon X1350,
ATI Mobility Radeon X1350, ATI Mobility Radeon X1450,
ATI Radeon X1300, ATI Radeon X1550, ATI Mobility Radeon X1350,
ATI FireMV 2250, ATI Radeon X1550 64-bit, ATI Radeon X1600,
ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1600,
ATI Mobility FireGL V5200, ATI Mobility Radeon X1600,
ATI Radeon X1650, ATI Radeon X1650, ATI Radeon X1600,
ATI Radeon X1300 XT/X1600 Pro, ATI FireGL V3400,
ATI Mobility FireGL V5250, ATI Mobility Radeon X1700,
ATI Mobility Radeon X1700 XT, ATI FireGL V5200,
ATI Mobility Radeon X1700, ATI Radeon X2300HD,
ATI Mobility Radeon HD 2300, ATI Mobility Radeon HD 2300,
ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1950,
ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900,
ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900,
ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900,
ATI AMD Stream Processor, ATI Radeon X1900, ATI Radeon X1950,
ATI RV560, ATI RV560, ATI Mobility Radeon X1900, ATI RV560,
ATI Radeon X1950 GT, ATI RV570, ATI RV570, ATI FireGL V7400,
ATI RV560, ATI Radeon X1650, ATI Radeon X1650, ATI RV560,
ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835,
ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200,
ATI Radeon X1200, ATI Radeon X1200, ATI RS740, ATI RS740M, ATI RS740,
ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT,
ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro, ATI Radeon HD 2900 GT,
ATI FireGL V8650, ATI FireGL V8600, ATI FireGL V7600,
ATI Radeon 4800 Series, ATI Radeon HD 4870 x2,
ATI Radeon 4800 Series, ATI Radeon HD 4850 x2,
ATI FirePro V8750 (FireGL), ATI FirePro V7760 (FireGL),
ATI Mobility RADEON HD 4850, ATI Mobility RADEON HD 4850 X2,
ATI Radeon 4800 Series, ATI FirePro RV770, AMD FireStream 9270,
AMD FireStream 9250, ATI FirePro V8700 (FireGL),
ATI Mobility RADEON HD 4870, ATI Mobility RADEON M98,
ATI Mobility RADEON HD 4870, ATI Radeon 4800 Series,
ATI Radeon 4800 Series, ATI FirePro M7750, ATI M98, ATI M98, ATI M98,
ATI Mobility Radeon HD 4650, ATI Radeon RV730 (AGP),
ATI Mobility Radeon HD 4670, ATI FirePro M5750,
ATI Mobility Radeon HD 4670, ATI Radeon RV730 (AGP),
ATI RV730XT [Radeon HD 4670], ATI RADEON E4600,
ATI Radeon HD 4600 Series, ATI RV730 PRO [Radeon HD 4650],
ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL),
ATI FirePro V3750 (FireGL), ATI Mobility Radeon HD 4830,
ATI Mobility Radeon HD 4850, ATI FirePro M7740, ATI RV740,
ATI Radeon HD 4770, ATI Radeon HD 4700 Series, ATI Radeon HD 4770,
ATI FirePro M5750, ATI RV610, ATI Radeon HD 2400 XT,
ATI Radeon HD 2400 Pro, ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000,
ATI RV610, ATI Radeon HD 2350, ATI Mobility Radeon HD 2400 XT,
ATI Mobility Radeon HD 2400, ATI RADEON E2400, ATI RV610,
ATI FireMV 2260, ATI RV670, ATI Radeon HD3870,
ATI Mobility Radeon HD 3850, ATI Radeon HD3850,
ATI Mobility Radeon HD 3850 X2, ATI RV670,
ATI Mobility Radeon HD 3870, ATI Mobility Radeon HD 3870 X2,
ATI Radeon HD3870 X2, ATI FireGL V7700, ATI Radeon HD3850,
ATI Radeon HD3690, AMD Firestream 9170, ATI Radeon HD 4550,
ATI Radeon RV710, ATI Radeon RV710, ATI Radeon RV710,
ATI Radeon HD 4350, ATI Mobility Radeon 4300 Series,
ATI Mobility Radeon 4500 Series, ATI Mobility Radeon 4500 Series,
ATI FirePro RG220, ATI Mobility Radeon 4330, ATI RV630,
ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT,
ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP,
ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630,
ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600,
ATI FireGL V3600, ATI Radeon HD 2600 LE,
ATI Mobility FireGL Graphics Processor, ATI Radeon HD 3470,
ATI Mobility Radeon HD 3430, ATI Mobility Radeon HD 3400 Series,
ATI Radeon HD 3450, ATI Radeon HD 3450, ATI Radeon HD 3430,
ATI Radeon HD 3450, ATI FirePro V3700, ATI FireMV 2450,
ATI FireMV 2260, ATI FireMV 2260, ATI Radeon HD 3600 Series,
ATI Radeon HD 3650 AGP, ATI Radeon HD 3600 PRO,
ATI Radeon HD 3600 XT, ATI Radeon HD 3600 PRO,
ATI Mobility Radeon HD 3650, ATI Mobility Radeon HD 3670,
ATI Mobility FireGL V5700, ATI Mobility FireGL V5725,
ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics,
ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics,
ATI Radeon HD 3300 Graphics, ATI Radeon HD 3200 Graphics,
ATI Radeon 3000 Graphics, ATI Radeon HD 4200, ATI Radeon 4100,
ATI Mobility Radeon HD 4200, ATI Mobility Radeon 4100,
ATI Radeon HD 4290, ATI Radeon HD 4250, AMD Radeon HD 6310 Graphics,
AMD Radeon HD 6310 Graphics, AMD Radeon HD 6250 Graphics,
AMD Radeon HD 6250 Graphics, CYPRESS,
ATI FirePro (FireGL) Graphics Adapter,
ATI FirePro (FireGL) Graphics Adapter,
ATI FirePro (FireGL) Graphics Adapter, AMD Firestream 9370,
AMD Firestream 9350, ATI Radeon HD 5800 Series,
ATI Radeon HD 5800 Series, ATI Radeon HD 5800 Series,
ATI Radeon HD 5900 Series, ATI Radeon HD 5900 Series,
ATI Mobility Radeon HD 5800 Series,
ATI Mobility Radeon HD 5800 Series,
ATI FirePro (FireGL) Graphics Adapter,
ATI FirePro (FireGL) Graphics Adapter,
ATI Mobility Radeon HD 5800 Series, ATI Radeon HD 5700 Series,
ATI Radeon HD 5700 Series, ATI Radeon HD 5700 Series,
ATI Mobility Radeon HD 5000 Series,
ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5570,
ATI FirePro (FireGL) Graphics Adapter,
ATI FirePro (FireGL) Graphics Adapter, ATI Radeon HD 5670,
ATI Radeon HD 5570, ATI Radeon HD 5500 Series, REDWOOD,
ATI Mobility Radeon HD 5000 Series,
ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon Graphics,
ATI Mobility Radeon Graphics, CEDAR,
ATI FirePro (FireGL) Graphics Adapter,
ATI FirePro (FireGL) Graphics Adapter, ATI FirePro 2270, CEDAR,
ATI Radeon HD 5450, CEDAR, AMD Radeon HD 6900M Series,
Mobility Radeon HD 6000 Series, BARTS, BARTS,
Mobility Radeon HD 6000 Series, Mobility Radeon HD 6000 Series,
BARTS, BARTS, BARTS, BARTS, AMD Radeon HD 6800 Series,
AMD Radeon HD 6800 Series, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS,
TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, CAICOS, CAICOS,
CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS,
CAICOS
[   361.811] (--) using VT number 7

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 05:16:40 pm
Xorg.0.log 2 Part

Code: [Select]
[   361.817] (II) [KMS] Kernel modesetting enabled.
[   361.817] (**) RADEON(0): Depth 24, (--) framebuffer bpp 32
[   361.817] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
[   361.817] (==) RADEON(0): Default visual is TrueColor
[   361.817] (**) RADEON(0): Option "EnablePageFlip" "on"
[   361.817] (==) RADEON(0): RGB weight 888
[   361.817] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[   361.818] (--) RADEON(0): Chipset: "ATI Radeon 9200SE 5964 (AGP)" (ChipID = 0x5964)
[   361.818] (II) RADEON(0): AGP card detected
[   361.818] drmOpenDevice: node name is /dev/dri/card0
[   361.818] drmOpenDevice: open result is 8, (OK)
[   361.818] drmOpenByBusid: Searching for BusID pci:0000:01:00.0
[   361.818] drmOpenDevice: node name is /dev/dri/card0
[   361.818] drmOpenDevice: open result is 8, (OK)
[   361.818] drmOpenByBusid: drmOpenMinor returns 8
[   361.818] drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
[   361.818] (II) RADEON(0): KMS Color Tiling: disabled
[   361.818] (II) RADEON(0): KMS Pageflipping: enabled
[   361.818] (II) RADEON(0): SwapBuffers wait for vsync: enabled
[   361.818] (II) RADEON(0): Output VGA-0 using monitor section DVI-0
[   361.818] (**) RADEON(0): Option "Primary" "True"
[   361.818] (**) RADEON(0): Option "DefaultModes" "False"
[   361.842] (II) RADEON(0): Output VGA-1 has no monitor section
[   361.848] (II) RADEON(0): Output S-video has no monitor section
[   361.848] (**) RADEON(0): Option "ModeDebug" "true"
[   361.848] (II) RADEON(0): EDID for output VGA-0
[   361.848] (II) RADEON(0): Printing probed modes for output VGA-0
[   361.848] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   361.872] (II) RADEON(0): EDID for output VGA-1
[   361.878] (II) RADEON(0): EDID for output S-video
[   361.878] (II) RADEON(0): Output VGA-0 connected
[   361.878] (II) RADEON(0): Output VGA-1 disconnected
[   361.878] (II) RADEON(0): Output S-video disconnected
[   361.878] (II) RADEON(0): Using fuzzy aspect match for initial modes
[   361.878] (II) RADEON(0): Output VGA-0 using initial mode 648x480x60.00
[   361.878] (II) RADEON(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
[   361.878] (II) RADEON(0): mem size init: gart size :1fdff000 vram size: s:8000000 visible:7e94000
[   361.879] (II) RADEON(0): EXA: Driver will allow EXA pixmaps in VRAM
[   361.879] (==) RADEON(0): DPI set to (96, 96)
[   361.879] (II) Loading sub module "fb"
[   361.879] (II) LoadModule: "fb"
[   361.879] (II) Loading /usr/lib/xorg/modules/libfb.so
[   361.879] (II) Module fb: vendor="X.Org Foundation"
[   361.879] compiled for 1.9.2, module version = 1.0.0
[   361.879] ABI class: X.Org ANSI C Emulation, version 0.4
[   361.879] (II) Loading sub module "ramdac"
[   361.879] (II) LoadModule: "ramdac"
[   361.879] (II) Module "ramdac" already built-in
[   361.879] (II) Loading sub module "exa"
[   361.879] (II) LoadModule: "exa"
[   361.879] (II) Loading /usr/lib/xorg/modules/libexa.so
[   361.880] (II) Module exa: vendor="X.Org Foundation"
[   361.880] compiled for 1.9.2, module version = 2.5.0
[   361.880] ABI class: X.Org Video Driver, version 8.0
[   361.880] (--) Depth 24 pixmap format is 32 bpp
[   361.880] (II) RADEON(0): [DRI2] Setup complete
[   361.880] (II) RADEON(0): [DRI2]   DRI driver: r200
[   361.880] (II) RADEON(0): Front buffer size: 1320K
[   361.880] (II) RADEON(0): VRAM usage limit set to 115466K
[   361.880] (==) RADEON(0): Backing store disabled
[   361.880] (II) RADEON(0): Direct rendering enabled
[   361.880] (II) RADEON(0): Render acceleration enabled for R200 type cards.
[   361.880] (II) RADEON(0): Setting EXA maxPitchBytes
[   361.880] (II) EXA(0): Driver allocated offscreen pixmaps
[   361.880] (II) EXA(0): Driver registered support for the following operations:
[   361.880] (II)         Solid
[   361.880] (II)         Copy
[   361.880] (II)         Composite (RENDER acceleration)
[   361.880] (II)         UploadToScreen
[   361.880] (II)         DownloadFromScreen
[   361.881] (II) RADEON(0): Acceleration enabled
[   361.881] (==) RADEON(0): Silken mouse enabled
[   361.881] (II) RADEON(0): Set up textured video
[   361.881] (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[   361.881] (WW) RADEON(0): Option "ForceMinDotClock" is not used
[   361.881] (WW) RADEON(0): Option "monitor-DVI-0" is not used
[   361.881] (WW) RADEON(0): Option "Primary" is not used
[   361.881] (WW) RADEON(0): Option "DefaultModes" is not used
[   361.881] (--) RandR disabled
[   361.881] (II) Initializing built-in extension Generic Event Extension
[   361.881] (II) Initializing built-in extension SHAPE
[   361.881] (II) Initializing built-in extension MIT-SHM
[   361.881] (II) Initializing built-in extension XInputExtension
[   361.881] (II) Initializing built-in extension XTEST
[   361.881] (II) Initializing built-in extension BIG-REQUESTS
[   361.881] (II) Initializing built-in extension SYNC
[   361.881] (II) Initializing built-in extension XKEYBOARD
[   361.881] (II) Initializing built-in extension XC-MISC
[   361.881] (II) Initializing built-in extension XINERAMA
[   361.881] (II) Initializing built-in extension XFIXES
[   361.881] (II) Initializing built-in extension RENDER
[   361.881] (II) Initializing built-in extension RANDR
[   361.881] (II) Initializing built-in extension COMPOSITE
[   361.881] (II) Initializing built-in extension DAMAGE
[   361.899] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[   361.899] (II) AIGLX: enabled GLX_INTEL_swap_event
[   361.899] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[   361.899] (II) AIGLX: enabled GLX_SGI_make_current_read
[   361.899] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[   361.900] (II) AIGLX: Loaded and initialized /usr/lib/dri/r200_dri.so
[   361.900] (II) GLX: Initialized DRI2 GL provider for screen 0
[   361.951] (II) RADEON(0): Setting screen physical size to 171 x 126
[   362.087] (II) config/udev: Adding input device Power Button (/dev/input/event1)
[   362.087] (**) Power Button: Applying InputClass "evdev keyboard catchall"
[   362.087] (II) LoadModule: "evdev"
[   362.087] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[   362.088] (II) Module evdev: vendor="X.Org Foundation"
[   362.088] compiled for 1.9.2, module version = 2.5.0
[   362.088] Module class: X.Org XInput Driver
[   362.088] ABI class: X.Org XInput driver, version 11.0
[   362.088] (**) Power Button: always reports core events
[   362.088] (**) Power Button: Device: "/dev/input/event1"
[   362.120] (--) Power Button: Found keys
[   362.120] (II) Power Button: Configuring as keyboard
[   362.120] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
[   362.120] (**) Option "xkb_rules" "evdev"
[   362.120] (**) Option "xkb_model" "evdev"
[   362.120] (**) Option "xkb_layout" "us"
[   362.154] (II) config/udev: Adding input device Power Button (/dev/input/event0)
[   362.154] (**) Power Button: Applying InputClass "evdev keyboard catchall"
[   362.154] (**) Power Button: always reports core events
[   362.154] (**) Power Button: Device: "/dev/input/event0"
[   362.190] (--) Power Button: Found keys
[   362.190] (II) Power Button: Configuring as keyboard
[   362.190] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
[   362.190] (**) Option "xkb_rules" "evdev"
[   362.190] (**) Option "xkb_model" "evdev"
[   362.190] (**) Option "xkb_layout" "us"
[   362.198] (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event2)
[   362.198] (**) AT Translated Set 2 keyboard: Applying InputClass "evdev keyboard catchall"
[   362.198] (**) AT Translated Set 2 keyboard: always reports core events
[   362.198] (**) AT Translated Set 2 keyboard: Device: "/dev/input/event2"
[   362.230] (--) AT Translated Set 2 keyboard: Found keys
[   362.230] (II) AT Translated Set 2 keyboard: Configuring as keyboard
[   362.230] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD)
[   362.230] (**) Option "xkb_rules" "evdev"
[   362.230] (**) Option "xkb_model" "evdev"
[   362.230] (**) Option "xkb_layout" "us"
[   362.230] (II) config/udev: Adding input device PC Speaker (/dev/input/event3)
[   362.231] (II) No input driver/identifier specified (ignoring)
[   379.552] (II) RADEON(0): EDID for output VGA-0
[   379.552] (II) RADEON(0): Printing probed modes for output VGA-0
[   379.552] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   379.576] (II) RADEON(0): EDID for output VGA-1
[   379.582] (II) RADEON(0): EDID for output S-video
[   382.552] (II) RADEON(0): EDID for output VGA-0
[   382.553] (II) RADEON(0): Printing probed modes for output VGA-0
[   382.553] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   382.577] (II) RADEON(0): EDID for output VGA-1
[   382.583] (II) RADEON(0): EDID for output S-video
[   387.371] (II) RADEON(0): EDID for output VGA-0
[   387.371] (II) RADEON(0): Printing probed modes for output VGA-0
[   387.371] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   387.395] (II) RADEON(0): EDID for output VGA-1
[   387.401] (II) RADEON(0): EDID for output S-video
[   392.120] (II) RADEON(0): EDID for output VGA-0
[   392.120] (II) RADEON(0): Printing probed modes for output VGA-0
[   392.120] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   392.144] (II) RADEON(0): EDID for output VGA-1
[   392.150] (II) RADEON(0): EDID for output S-video
[   392.156] (II) RADEON(0): EDID for output VGA-0
[   392.156] (II) RADEON(0): Printing probed modes for output VGA-0
[   392.156] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   392.180] (II) RADEON(0): EDID for output VGA-1
[   392.186] (II) RADEON(0): EDID for output S-video
[   392.259] (II) RADEON(0): EDID for output VGA-0
[   392.259] (II) RADEON(0): Printing probed modes for output VGA-0
[   392.259] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   392.283] (II) RADEON(0): EDID for output VGA-1
[   392.289] (II) RADEON(0): EDID for output S-video
[   392.324] (II) RADEON(0): Allocate new frame buffer 368x232 stride 384
[   392.324] (II) RADEON(0): VRAM usage limit set to 116341K
[   392.620] (II) RADEON(0): EDID for output VGA-0
[   392.620] (II) RADEON(0): Printing probed modes for output VGA-0
[   392.620] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   392.644] (II) RADEON(0): EDID for output VGA-1
[   392.650] (II) RADEON(0): EDID for output S-video
[   392.651] (II) RADEON(0): Allocate new frame buffer 648x480 stride 704
[   392.651] (II) RADEON(0): VRAM usage limit set to 115466K
[   392.712] (II) RADEON(0): EDID for output VGA-0
[   392.712] (II) RADEON(0): Printing probed modes for output VGA-0
[   392.712] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   392.736] (II) RADEON(0): EDID for output VGA-1
[   392.742] (II) RADEON(0): EDID for output S-video
[   392.748] (II) RADEON(0): EDID for output VGA-0
[   392.748] (II) RADEON(0): Printing probed modes for output VGA-0
[   392.748] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   392.772] (II) RADEON(0): EDID for output VGA-1
[   392.778] (II) RADEON(0): EDID for output S-video
[   392.831] (II) RADEON(0): EDID for output VGA-0
[   392.831] (II) RADEON(0): Printing probed modes for output VGA-0
[   392.831] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   392.855] (II) RADEON(0): EDID for output VGA-1
[   392.861] (II) RADEON(0): EDID for output S-video
[   394.878] (II) RADEON(0): EDID for output VGA-0
[   394.878] (II) RADEON(0): Printing probed modes for output VGA-0
[   394.878] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   394.902] (II) RADEON(0): EDID for output VGA-1
[   394.908] (II) RADEON(0): EDID for output S-video
[   394.914] (II) RADEON(0): EDID for output VGA-0
[   394.914] (II) RADEON(0): Printing probed modes for output VGA-0
[   394.914] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   394.938] (II) RADEON(0): EDID for output VGA-1
[   394.944] (II) RADEON(0): EDID for output S-video
[   395.021] (II) RADEON(0): EDID for output VGA-0
[   395.021] (II) RADEON(0): Printing probed modes for output VGA-0
[   395.021] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   395.045] (II) RADEON(0): EDID for output VGA-1
[   395.051] (II) RADEON(0): EDID for output S-video
[   395.088] (II) RADEON(0): Allocate new frame buffer 256x256 stride 256
[   395.088] (II) RADEON(0): VRAM usage limit set to 116424K
[   395.245] (II) RADEON(0): EDID for output VGA-0
[   395.245] (II) RADEON(0): Printing probed modes for output VGA-0
[   395.245] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   395.269] (II) RADEON(0): EDID for output VGA-1
[   395.275] (II) RADEON(0): EDID for output S-video
[   395.276] (II) RADEON(0): Allocate new frame buffer 648x480 stride 704
[   395.276] (II) RADEON(0): VRAM usage limit set to 115466K
[   395.337] (II) RADEON(0): EDID for output VGA-0
[   395.337] (II) RADEON(0): Printing probed modes for output VGA-0
[   395.337] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   395.361] (II) RADEON(0): EDID for output VGA-1
[   395.367] (II) RADEON(0): EDID for output S-video
[   395.373] (II) RADEON(0): EDID for output VGA-0
[   395.373] (II) RADEON(0): Printing probed modes for output VGA-0
[   395.373] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   395.397] (II) RADEON(0): EDID for output VGA-1
[   395.403] (II) RADEON(0): EDID for output S-video
[   395.507] (II) RADEON(0): EDID for output VGA-0
[   395.507] (II) RADEON(0): Printing probed modes for output VGA-0
[   395.507] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   395.531] (II) RADEON(0): EDID for output VGA-1
[   395.537] (II) RADEON(0): EDID for output S-video
[   396.912] (II) RADEON(0): EDID for output VGA-0
[   396.912] (II) RADEON(0): Printing probed modes for output VGA-0
[   396.912] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   396.936] (II) RADEON(0): EDID for output VGA-1
[   396.942] (II) RADEON(0): EDID for output S-video
[   396.948] (II) RADEON(0): EDID for output VGA-0
[   396.949] (II) RADEON(0): Printing probed modes for output VGA-0
[   396.949] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   396.973] (II) RADEON(0): EDID for output VGA-1
[   396.979] (II) RADEON(0): EDID for output S-video
[   397.050] (II) RADEON(0): EDID for output VGA-0
[   397.050] (II) RADEON(0): Printing probed modes for output VGA-0
[   397.050] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   397.074] (II) RADEON(0): EDID for output VGA-1
[   397.080] (II) RADEON(0): EDID for output S-video
[   397.116] (II) RADEON(0): Allocate new frame buffer 248x256 stride 256
[   397.116] (II) RADEON(0): VRAM usage limit set to 116424K
[   397.262] (II) RADEON(0): EDID for output VGA-0
[   397.262] (II) RADEON(0): Printing probed modes for output VGA-0
[   397.262] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   397.286] (II) RADEON(0): EDID for output VGA-1
[   397.292] (II) RADEON(0): EDID for output S-video
[   397.293] (II) RADEON(0): Allocate new frame buffer 648x480 stride 704
[   397.293] (II) RADEON(0): VRAM usage limit set to 115466K
[   397.354] (II) RADEON(0): EDID for output VGA-0
[   397.355] (II) RADEON(0): Printing probed modes for output VGA-0
[   397.355] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   397.378] (II) RADEON(0): EDID for output VGA-1
[   397.385] (II) RADEON(0): EDID for output S-video
[   397.390] (II) RADEON(0): EDID for output VGA-0
[   397.391] (II) RADEON(0): Printing probed modes for output VGA-0
[   397.391] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   397.414] (II) RADEON(0): EDID for output VGA-1
[   397.421] (II) RADEON(0): EDID for output S-video
[   397.535] (II) RADEON(0): EDID for output VGA-0
[   397.535] (II) RADEON(0): Printing probed modes for output VGA-0
[   397.535] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   397.559] (II) RADEON(0): EDID for output VGA-1
[   397.565] (II) RADEON(0): EDID for output S-video
[   399.853] (II) RADEON(0): EDID for output VGA-0
[   399.853] (II) RADEON(0): Printing probed modes for output VGA-0
[   399.853] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   399.877] (II) RADEON(0): EDID for output VGA-1
[   399.883] (II) RADEON(0): EDID for output S-video
[   399.889] (II) RADEON(0): EDID for output VGA-0
[   399.889] (II) RADEON(0): Printing probed modes for output VGA-0
[   399.889] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   399.913] (II) RADEON(0): EDID for output VGA-1
[   399.919] (II) RADEON(0): EDID for output S-video
[   399.989] (II) RADEON(0): EDID for output VGA-0
[   399.989] (II) RADEON(0): Printing probed modes for output VGA-0
[   399.989] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   400.013] (II) RADEON(0): EDID for output VGA-1
[   400.019] (II) RADEON(0): EDID for output S-video
[   400.056] (II) RADEON(0): Allocate new frame buffer 512x256 stride 512
[   400.056] (II) RADEON(0): VRAM usage limit set to 116193K
[   400.266] (II) RADEON(0): EDID for output VGA-0
[   400.266] (II) RADEON(0): Printing probed modes for output VGA-0
[   400.266] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   400.290] (II) RADEON(0): EDID for output VGA-1
[   400.296] (II) RADEON(0): EDID for output S-video
[   400.297] (II) RADEON(0): Allocate new frame buffer 648x480 stride 704
[   400.297] (II) RADEON(0): VRAM usage limit set to 115466K
[   400.358] (II) RADEON(0): EDID for output VGA-0
[   400.358] (II) RADEON(0): Printing probed modes for output VGA-0
[   400.358] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   400.382] (II) RADEON(0): EDID for output VGA-1
[   400.388] (II) RADEON(0): EDID for output S-video
[   400.394] (II) RADEON(0): EDID for output VGA-0
[   400.394] (II) RADEON(0): Printing probed modes for output VGA-0
[   400.394] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   400.418] (II) RADEON(0): EDID for output VGA-1
[   400.424] (II) RADEON(0): EDID for output S-video
[   400.519] (II) RADEON(0): EDID for output VGA-0
[   400.519] (II) RADEON(0): Printing probed modes for output VGA-0
[   400.519] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   400.543] (II) RADEON(0): EDID for output VGA-1
[   400.549] (II) RADEON(0): EDID for output S-video
[   403.718] (II) RADEON(0): EDID for output VGA-0
[   403.718] (II) RADEON(0): Printing probed modes for output VGA-0
[   403.718] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   403.742] (II) RADEON(0): EDID for output VGA-1
[   403.748] (II) RADEON(0): EDID for output S-video
[   403.754] (II) RADEON(0): EDID for output VGA-0
[   403.754] (II) RADEON(0): Printing probed modes for output VGA-0
[   403.754] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   403.778] (II) RADEON(0): EDID for output VGA-1
[   403.784] (II) RADEON(0): EDID for output S-video
[   403.870] (II) RADEON(0): EDID for output VGA-0
[   403.871] (II) RADEON(0): Printing probed modes for output VGA-0
[   403.871] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   403.895] (II) RADEON(0): EDID for output VGA-1
[   403.901] (II) RADEON(0): EDID for output S-video
[   403.938] (II) RADEON(0): Allocate new frame buffer 704x528 stride 704
[   403.939] (II) RADEON(0): VRAM usage limit set to 115347K
[   415.723] (II) AIGLX: Suspending AIGLX clients for VT switch

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 05:17:43 pm
Xorg.0.log.old 1 Part

Code: [Select]
[b]Xorg.0.log.old[/b]
[code][   103.768]
X.Org X Server 1.9.2
Release Date: 2010-10-30
[   103.772] X Protocol Version 11, Revision 0
[   103.773] Build Operating System: Linux 2.6.38-rc1 i686 Gentoo
[   103.774] Current Operating System: Linux GroovyArcade 2.6.38-rc2+ #1 SMP Mon Jan 24 22:01:58 CST 2011 i686
[   103.777] Kernel command line: root=/dev/sda1 init=/boot/linuxrc initrd udev nodevfs CGAVGA video=VGA-1:640x480ec
[   103.781] Build Date: 31 January 2011  12:08:30PM
[   103.783] 
[   103.785] Current version of pixman: 0.20.0
[   103.787] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   103.792] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   103.801] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb  4 17:04:06 2011
[   103.804] (==) Using config file: "/etc/X11/xorg.conf"
[   103.807] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   103.811] (**) Option "defaultserverlayout" "Arcade Cabinet"
[   103.811] (**) ServerLayout "Arcade Cabinet"
[   103.811] (**) |-->Screen "Screen0" (0)
[   103.811] (**) |   |-->Monitor "DVI-0"
[   103.811] (**) |   |-->Device "Card0"
[   103.811] (**) |-->Input Device "Mouse0"
[   103.811] (**) |-->Input Device "Keyboard0"
[   103.811] (**) Option "DontZap" "off"
[   103.811] (**) Option "DontZoom" "on"
[   103.811] (**) Option "AllowMouseOpenFail" "true"
[   103.812] (**) Option "BlankTime" "0"
[   103.812] (**) Option "StandbyTime" "0"
[   103.812] (**) Option "SuspendTime" "0"
[   103.812] (**) Option "OffTime" "0"
[   103.812] (**) Option "NoPM" "True"
[   103.812] (**) Option "AIGLX" "on"
[   103.812] (==) Automatically adding devices
[   103.812] (==) Automatically enabling devices
[   103.812] (==) FontPath set to:
/usr/share/fonts/misc/,
/usr/share/fonts/TTF/,
/usr/share/fonts/OTF/,
/usr/share/fonts/Type1/,
/usr/share/fonts/100dpi/,
/usr/share/fonts/75dpi/
[   103.812] (==) ModulePath set to "/usr/lib/xorg/modules"
[   103.812] (**) Extension "Composite" is enabled
[   103.812] (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[   103.812] (WW) Disabling Mouse0
[   103.812] (WW) Disabling Keyboard0
[   103.812] (II) Loader magic: 0x81f2d60
[   103.812] (II) Module ABI versions:
[   103.812] X.Org ANSI C Emulation: 0.4
[   103.812] X.Org Video Driver: 8.0
[   103.812] X.Org XInput driver : 11.0
[   103.812] X.Org Server Extension : 4.0
[   103.813] (--) PCI:*(0:1:0:0) 1002:5964:1787:5964 rev 1, Mem @ 0xd0000000/134217728, 0xe5000000/65536, I/O @ 0x00009000/256, BIOS @ 0x????????/131072
[   103.813] (--) PCI: (0:1:0:1) 1002:5d44:1787:5965 rev 1, Mem @ 0xd8000000/134217728, 0xe5010000/65536
[   103.813] (II) LoadModule: "extmod"
[   103.814] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[   103.814] (II) Module extmod: vendor="X.Org Foundation"
[   103.814] compiled for 1.9.2, module version = 1.0.0
[   103.814] Module class: X.Org Server Extension
[   103.814] ABI class: X.Org Server Extension, version 4.0
[   103.814] (II) Loading extension MIT-SCREEN-SAVER
[   103.814] (II) Loading extension XFree86-VidModeExtension
[   103.814] (II) Loading extension XFree86-DGA
[   103.814] (II) Loading extension DPMS
[   103.814] (II) Loading extension XVideo
[   103.814] (II) Loading extension XVideo-MotionCompensation
[   103.814] (II) Loading extension X-Resource
[   103.814] (II) LoadModule: "dbe"
[   103.814] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
[   103.814] (II) Module dbe: vendor="X.Org Foundation"
[   103.814] compiled for 1.9.2, module version = 1.0.0
[   103.814] Module class: X.Org Server Extension
[   103.814] ABI class: X.Org Server Extension, version 4.0
[   103.814] (II) Loading extension DOUBLE-BUFFER
[   103.814] (II) LoadModule: "glx"
[   103.815] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   103.815] (II) Module glx: vendor="X.Org Foundation"
[   103.815] compiled for 1.9.2, module version = 1.0.0
[   103.815] ABI class: X.Org Server Extension, version 4.0
[   103.815] (**) AIGLX enabled
[   103.815] (II) Loading extension GLX
[   103.815] (II) LoadModule: "record"
[   103.815] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so
[   103.815] (II) Module record: vendor="X.Org Foundation"
[   103.815] compiled for 1.9.2, module version = 1.13.0
[   103.815] Module class: X.Org Server Extension
[   103.815] ABI class: X.Org Server Extension, version 4.0
[   103.815] (II) Loading extension RECORD
[   103.815] (II) LoadModule: "dri"
[   103.815] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so
[   103.816] (II) Module dri: vendor="X.Org Foundation"
[   103.816] compiled for 1.9.2, module version = 1.0.0
[   103.816] ABI class: X.Org Server Extension, version 4.0
[   103.816] (II) Loading extension XFree86-DRI
[   103.816] (II) LoadModule: "dri2"
[   103.816] (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
[   103.816] (II) Module dri2: vendor="X.Org Foundation"
[   103.816] compiled for 1.9.2, module version = 1.2.0
[   103.816] ABI class: X.Org Server Extension, version 4.0
[   103.816] (II) Loading extension DRI2
[   103.816] (II) LoadModule: "radeon"
[   103.816] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[   103.817] (II) Module radeon: vendor="X.Org Foundation"
[   103.817] compiled for 1.9.2, module version = 6.13.99
[   103.817] Module class: X.Org Video Driver
[   103.817] ABI class: X.Org Video Driver, version 8.0
[   103.817] (II) RADEON: Driver for ATI Radeon chipsets:
ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI),
ATI Radeon Mobility X300 (M24) 3152 (PCIE),
ATI FireGL M24 GL 3154 (PCIE), ATI FireMV 2400 3155 (PCI),
ATI Radeon X600 (RV380) 3E50 (PCIE),
ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136,
ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP),
ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP),
ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP),
ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP),
ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP),
ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP),
ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650,
ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237,
ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP),
ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337,
ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI),
ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP),
ATI Radeon X800PRO (R420) JI (AGP),
ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP),
ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP),
ATI Radeon Mobility 9800 (M18) JN (AGP),
ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP),
ATI Radeon X800 VE (R420) JT (AGP), ATI Radeon X850 (R480) (AGP),
ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP),
ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP),
ATI Radeon Mobility M7 LW (AGP),
ATI Mobility FireGL 7800 M7 LX (AGP),
ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP),
ATI FireGL Mobility 9000 (M9) Ld (AGP),
ATI Radeon Mobility 9000 (M9) Lf (AGP),
ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9700 Pro ND (AGP),
ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP),
ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP),
ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP),
ATI Radeon 9800XT NJ (AGP),
ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP),
ATI Radeon Mobility 9600 (M10) NQ (AGP),
ATI Radeon Mobility 9600 (M11) NR (AGP),
ATI Radeon Mobility 9600 (M10) NS (AGP),
ATI FireGL Mobility T2 (M10) NT (AGP),
ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP),
ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP),
ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP),
ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI),
ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI),
ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI),
ATI Radeon Mobility X300 (M22) 5460 (PCIE),
ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE),
ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE),
ATI Radeon X800PRO (R423) UI (PCIE),
ATI Radeon X800LE (R423) UJ (PCIE),
ATI Radeon X800SE (R423) UK (PCIE),
ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE),
ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE),
ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE),
ATI FireGL unknown (R423) UR (PCIE),
ATI FireGL unknown (R423) UT (PCIE),
ATI Mobility FireGL V5000 (M26) (PCIE),
ATI Mobility FireGL V5000 (M26) (PCIE),
ATI Mobility Radeon X700 XL (M26) (PCIE),
ATI Mobility Radeon X700 (M26) (PCIE),
ATI Mobility Radeon X700 (M26) (PCIE),
ATI Radeon X550XTX 5657 (PCIE), ATI Radeon 9100 IGP (A5) 5834,
ATI Radeon Mobility 9100 IGP (U3) 5835,
ATI Radeon XPRESS 200 5954 (PCIE),
ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP),
ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP),
ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI),
ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE),
ATI Radeon XPRESS 200M 5975 (PCIE),
ATI Radeon XPRESS 200 5A41 (PCIE),
ATI Radeon XPRESS 200M 5A42 (PCIE),
ATI Radeon XPRESS 200 5A61 (PCIE),
ATI Radeon XPRESS 200M 5A62 (PCIE),
ATI Radeon X300 (RV370) 5B60 (PCIE),
ATI Radeon X600 (RV370) 5B62 (PCIE),
ATI Radeon X550 (RV370) 5B63 (PCIE),
ATI FireGL V3100 (RV370) 5B64 (PCIE),
ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE),
ATI Radeon Mobility 9200 (M9+) 5C61 (AGP),
ATI Radeon Mobility 9200 (M9+) 5C63 (AGP),
ATI Mobility Radeon X800 XT (M28) (PCIE),
ATI Mobility FireGL V5100 (M28) (PCIE),
ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE),
ATI Radeon X850 XT PE (R480) (PCIE),
ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE),
ATI unknown Radeon / FireGL (R480) 5D50 (PCIE),
ATI Radeon X850 XT (R480) (PCIE),
ATI Radeon X800XT (R423) 5D57 (PCIE),
ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE),
ATI Radeon X700 PRO (RV410) (PCIE),
ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE),
ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X1800,
ATI Mobility Radeon X1800 XT, ATI Mobility Radeon X1800,
ATI Mobility FireGL V7200, ATI FireGL V7200, ATI FireGL V5300,
ATI Mobility FireGL V7100, ATI Radeon X1800, ATI Radeon X1800,
ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800,
ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505,
ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL,
ATI Mobility Radeon X1400, ATI Radeon X1300/X1550,
ATI Radeon X1550 64-bit, ATI Mobility Radeon X1300,
ATI Mobility Radeon X1300, ATI Mobility Radeon X1300,
ATI Mobility Radeon X1300, ATI Radeon X1300, ATI Radeon X1300,
ATI RV505, ATI RV505, ATI FireGL V3300, ATI FireGL V3350,
ATI Radeon X1300, ATI Radeon X1550 64-bit, ATI Radeon X1300/X1550,
ATI Radeon X1600, ATI Radeon X1300/X1550, ATI Mobility Radeon X1450,
ATI Radeon X1300/X1550, ATI Mobility Radeon X2300,
ATI Mobility Radeon X2300, ATI Mobility Radeon X1350,
ATI Mobility Radeon X1350, ATI Mobility Radeon X1450,
ATI Radeon X1300, ATI Radeon X1550, ATI Mobility Radeon X1350,
ATI FireMV 2250, ATI Radeon X1550 64-bit, ATI Radeon X1600,
ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1600,
ATI Mobility FireGL V5200, ATI Mobility Radeon X1600,
ATI Radeon X1650, ATI Radeon X1650, ATI Radeon X1600,
ATI Radeon X1300 XT/X1600 Pro, ATI FireGL V3400,
ATI Mobility FireGL V5250, ATI Mobility Radeon X1700,
ATI Mobility Radeon X1700 XT, ATI FireGL V5200,
ATI Mobility Radeon X1700, ATI Radeon X2300HD,
ATI Mobility Radeon HD 2300, ATI Mobility Radeon HD 2300,
ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1950,
ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900,
ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900,
ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900,
ATI AMD Stream Processor, ATI Radeon X1900, ATI Radeon X1950,
ATI RV560, ATI RV560, ATI Mobility Radeon X1900, ATI RV560,
ATI Radeon X1950 GT, ATI RV570, ATI RV570, ATI FireGL V7400,
ATI RV560, ATI Radeon X1650, ATI Radeon X1650, ATI RV560,
ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835,
ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200,
ATI Radeon X1200, ATI Radeon X1200, ATI RS740, ATI RS740M, ATI RS740,
ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT,
ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro, ATI Radeon HD 2900 GT,
ATI FireGL V8650, ATI FireGL V8600, ATI FireGL V7600,
ATI Radeon 4800 Series, ATI Radeon HD 4870 x2,
ATI Radeon 4800 Series, ATI Radeon HD 4850 x2,
ATI FirePro V8750 (FireGL), ATI FirePro V7760 (FireGL),
ATI Mobility RADEON HD 4850, ATI Mobility RADEON HD 4850 X2,
ATI Radeon 4800 Series, ATI FirePro RV770, AMD FireStream 9270,
AMD FireStream 9250, ATI FirePro V8700 (FireGL),
ATI Mobility RADEON HD 4870, ATI Mobility RADEON M98,
ATI Mobility RADEON HD 4870, ATI Radeon 4800 Series,
ATI Radeon 4800 Series, ATI FirePro M7750, ATI M98, ATI M98, ATI M98,
ATI Mobility Radeon HD 4650, ATI Radeon RV730 (AGP),
ATI Mobility Radeon HD 4670, ATI FirePro M5750,
ATI Mobility Radeon HD 4670, ATI Radeon RV730 (AGP),
ATI RV730XT [Radeon HD 4670], ATI RADEON E4600,
ATI Radeon HD 4600 Series, ATI RV730 PRO [Radeon HD 4650],
ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL),
ATI FirePro V3750 (FireGL), ATI Mobility Radeon HD 4830,
ATI Mobility Radeon HD 4850, ATI FirePro M7740, ATI RV740,
ATI Radeon HD 4770, ATI Radeon HD 4700 Series, ATI Radeon HD 4770,
ATI FirePro M5750, ATI RV610, ATI Radeon HD 2400 XT,
ATI Radeon HD 2400 Pro, ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000,
ATI RV610, ATI Radeon HD 2350, ATI Mobility Radeon HD 2400 XT,
ATI Mobility Radeon HD 2400, ATI RADEON E2400, ATI RV610,
ATI FireMV 2260, ATI RV670, ATI Radeon HD3870,
ATI Mobility Radeon HD 3850, ATI Radeon HD3850,
ATI Mobility Radeon HD 3850 X2, ATI RV670,
ATI Mobility Radeon HD 3870, ATI Mobility Radeon HD 3870 X2,
ATI Radeon HD3870 X2, ATI FireGL V7700, ATI Radeon HD3850,
ATI Radeon HD3690, AMD Firestream 9170, ATI Radeon HD 4550,
ATI Radeon RV710, ATI Radeon RV710, ATI Radeon RV710,
ATI Radeon HD 4350, ATI Mobility Radeon 4300 Series,
ATI Mobility Radeon 4500 Series, ATI Mobility Radeon 4500 Series,
ATI FirePro RG220, ATI Mobility Radeon 4330, ATI RV630,
ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT,
ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP,
ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630,
ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600,
ATI FireGL V3600, ATI Radeon HD 2600 LE,
ATI Mobility FireGL Graphics Processor, ATI Radeon HD 3470,
ATI Mobility Radeon HD 3430, ATI Mobility Radeon HD 3400 Series,
ATI Radeon HD 3450, ATI Radeon HD 3450, ATI Radeon HD 3430,
ATI Radeon HD 3450, ATI FirePro V3700, ATI FireMV 2450,
ATI FireMV 2260, ATI FireMV 2260, ATI Radeon HD 3600 Series,
ATI Radeon HD 3650 AGP, ATI Radeon HD 3600 PRO,
ATI Radeon HD 3600 XT, ATI Radeon HD 3600 PRO,
ATI Mobility Radeon HD 3650, ATI Mobility Radeon HD 3670,
ATI Mobility FireGL V5700, ATI Mobility FireGL V5725,
ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics,
ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics,
ATI Radeon HD 3300 Graphics, ATI Radeon HD 3200 Graphics,
ATI Radeon 3000 Graphics, ATI Radeon HD 4200, ATI Radeon 4100,
ATI Mobility Radeon HD 4200, ATI Mobility Radeon 4100,
ATI Radeon HD 4290, ATI Radeon HD 4250, AMD Radeon HD 6310 Graphics,
AMD Radeon HD 6310 Graphics, AMD Radeon HD 6250 Graphics,
AMD Radeon HD 6250 Graphics, CYPRESS,
ATI FirePro (FireGL) Graphics Adapter,
ATI FirePro (FireGL) Graphics Adapter,
ATI FirePro (FireGL) Graphics Adapter, AMD Firestream 9370,
AMD Firestream 9350, ATI Radeon HD 5800 Series,
ATI Radeon HD 5800 Series, ATI Radeon HD 5800 Series,
ATI Radeon HD 5900 Series, ATI Radeon HD 5900 Series,
ATI Mobility Radeon HD 5800 Series,
ATI Mobility Radeon HD 5800 Series,
ATI FirePro (FireGL) Graphics Adapter,
ATI FirePro (FireGL) Graphics Adapter,
ATI Mobility Radeon HD 5800 Series, ATI Radeon HD 5700 Series,
ATI Radeon HD 5700 Series, ATI Radeon HD 5700 Series,
ATI Mobility Radeon HD 5000 Series,
ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5570,
ATI FirePro (FireGL) Graphics Adapter,
ATI FirePro (FireGL) Graphics Adapter, ATI Radeon HD 5670,
ATI Radeon HD 5570, ATI Radeon HD 5500 Series, REDWOOD,
ATI Mobility Radeon HD 5000 Series,
ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon Graphics,
ATI Mobility Radeon Graphics, CEDAR,
ATI FirePro (FireGL) Graphics Adapter,
ATI FirePro (FireGL) Graphics Adapter, ATI FirePro 2270, CEDAR,
ATI Radeon HD 5450, CEDAR, AMD Radeon HD 6900M Series,
Mobility Radeon HD 6000 Series, BARTS, BARTS,
Mobility Radeon HD 6000 Series, Mobility Radeon HD 6000 Series,
BARTS, BARTS, BARTS, BARTS, AMD Radeon HD 6800 Series,
AMD Radeon HD 6800 Series, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS,
TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, CAICOS, CAICOS,
CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS,
CAICOS
[   103.825] (--) using VT number 7
[/code]
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 05:18:51 pm
Xorg.0.log.old 2 Part

Code: [Select]
[   103.832] (II) [KMS] Kernel modesetting enabled.
[   103.832] (**) RADEON(0): Depth 24, (--) framebuffer bpp 32
[   103.832] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
[   103.832] (==) RADEON(0): Default visual is TrueColor
[   103.832] (**) RADEON(0): Option "EnablePageFlip" "on"
[   103.832] (==) RADEON(0): RGB weight 888
[   103.832] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[   103.832] (--) RADEON(0): Chipset: "ATI Radeon 9200SE 5964 (AGP)" (ChipID = 0x5964)
[   103.832] (II) RADEON(0): AGP card detected
[   103.832] drmOpenDevice: node name is /dev/dri/card0
[   103.832] drmOpenDevice: open result is 8, (OK)
[   103.832] drmOpenByBusid: Searching for BusID pci:0000:01:00.0
[   103.832] drmOpenDevice: node name is /dev/dri/card0
[   103.832] drmOpenDevice: open result is 8, (OK)
[   103.832] drmOpenByBusid: drmOpenMinor returns 8
[   103.832] drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
[   103.832] (II) RADEON(0): KMS Color Tiling: disabled
[   103.832] (II) RADEON(0): KMS Pageflipping: enabled
[   103.832] (II) RADEON(0): SwapBuffers wait for vsync: enabled
[   103.832] (II) RADEON(0): Output VGA-0 using monitor section DVI-0
[   103.833] (**) RADEON(0): Option "Primary" "True"
[   103.833] (**) RADEON(0): Option "DefaultModes" "False"
[   103.856] (II) RADEON(0): Output VGA-1 has no monitor section
[   103.863] (II) RADEON(0): Output S-video has no monitor section
[   103.863] (**) RADEON(0): Option "ModeDebug" "true"
[   103.863] (II) RADEON(0): EDID for output VGA-0
[   103.863] (II) RADEON(0): Printing probed modes for output VGA-0
[   103.863] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   103.887] (II) RADEON(0): EDID for output VGA-1
[   103.893] (II) RADEON(0): EDID for output S-video
[   103.893] (II) RADEON(0): Output VGA-0 connected
[   103.893] (II) RADEON(0): Output VGA-1 disconnected
[   103.893] (II) RADEON(0): Output S-video disconnected
[   103.893] (II) RADEON(0): Using fuzzy aspect match for initial modes
[   103.893] (II) RADEON(0): Output VGA-0 using initial mode 648x480x60.00
[   103.893] (II) RADEON(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
[   103.893] (II) RADEON(0): mem size init: gart size :1fdff000 vram size: s:8000000 visible:7e94000
[   103.893] (II) RADEON(0): EXA: Driver will allow EXA pixmaps in VRAM
[   103.893] (==) RADEON(0): DPI set to (96, 96)
[   103.893] (II) Loading sub module "fb"
[   103.893] (II) LoadModule: "fb"
[   103.893] (II) Loading /usr/lib/xorg/modules/libfb.so
[   103.893] (II) Module fb: vendor="X.Org Foundation"
[   103.893] compiled for 1.9.2, module version = 1.0.0
[   103.893] ABI class: X.Org ANSI C Emulation, version 0.4
[   103.893] (II) Loading sub module "ramdac"
[   103.893] (II) LoadModule: "ramdac"
[   103.894] (II) Module "ramdac" already built-in
[   103.894] (II) Loading sub module "exa"
[   103.894] (II) LoadModule: "exa"
[   103.894] (II) Loading /usr/lib/xorg/modules/libexa.so
[   103.894] (II) Module exa: vendor="X.Org Foundation"
[   103.894] compiled for 1.9.2, module version = 2.5.0
[   103.894] ABI class: X.Org Video Driver, version 8.0
[   103.894] (--) Depth 24 pixmap format is 32 bpp
[   103.894] (II) RADEON(0): [DRI2] Setup complete
[   103.894] (II) RADEON(0): [DRI2]   DRI driver: r200
[   103.894] (II) RADEON(0): Front buffer size: 1320K
[   103.894] (II) RADEON(0): VRAM usage limit set to 115466K
[   103.895] (==) RADEON(0): Backing store disabled
[   103.895] (II) RADEON(0): Direct rendering enabled
[   103.895] (II) RADEON(0): Render acceleration enabled for R200 type cards.
[   103.895] (II) RADEON(0): Setting EXA maxPitchBytes
[   103.895] (II) EXA(0): Driver allocated offscreen pixmaps
[   103.895] (II) EXA(0): Driver registered support for the following operations:
[   103.895] (II)         Solid
[   103.895] (II)         Copy
[   103.895] (II)         Composite (RENDER acceleration)
[   103.895] (II)         UploadToScreen
[   103.895] (II)         DownloadFromScreen
[   103.895] (II) RADEON(0): Acceleration enabled
[   103.895] (==) RADEON(0): Silken mouse enabled
[   103.895] (II) RADEON(0): Set up textured video
[   103.895] (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[   103.895] (WW) RADEON(0): Option "ForceMinDotClock" is not used
[   103.895] (WW) RADEON(0): Option "monitor-DVI-0" is not used
[   103.895] (WW) RADEON(0): Option "Primary" is not used
[   103.895] (WW) RADEON(0): Option "DefaultModes" is not used
[   103.895] (--) RandR disabled
[   103.896] (II) Initializing built-in extension Generic Event Extension
[   103.896] (II) Initializing built-in extension SHAPE
[   103.896] (II) Initializing built-in extension MIT-SHM
[   103.896] (II) Initializing built-in extension XInputExtension
[   103.896] (II) Initializing built-in extension XTEST
[   103.896] (II) Initializing built-in extension BIG-REQUESTS
[   103.896] (II) Initializing built-in extension SYNC
[   103.896] (II) Initializing built-in extension XKEYBOARD
[   103.896] (II) Initializing built-in extension XC-MISC
[   103.896] (II) Initializing built-in extension XINERAMA
[   103.896] (II) Initializing built-in extension XFIXES
[   103.896] (II) Initializing built-in extension RENDER
[   103.896] (II) Initializing built-in extension RANDR
[   103.896] (II) Initializing built-in extension COMPOSITE
[   103.896] (II) Initializing built-in extension DAMAGE
[   103.913] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[   103.913] (II) AIGLX: enabled GLX_INTEL_swap_event
[   103.913] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[   103.913] (II) AIGLX: enabled GLX_SGI_make_current_read
[   103.913] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[   103.914] (II) AIGLX: Loaded and initialized /usr/lib/dri/r200_dri.so
[   103.914] (II) GLX: Initialized DRI2 GL provider for screen 0
[   103.966] (II) RADEON(0): Setting screen physical size to 171 x 126
[   104.101] (II) config/udev: Adding input device Power Button (/dev/input/event1)
[   104.102] (**) Power Button: Applying InputClass "evdev keyboard catchall"
[   104.102] (II) LoadModule: "evdev"
[   104.102] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[   104.102] (II) Module evdev: vendor="X.Org Foundation"
[   104.102] compiled for 1.9.2, module version = 2.5.0
[   104.102] Module class: X.Org XInput Driver
[   104.102] ABI class: X.Org XInput driver, version 11.0
[   104.102] (**) Power Button: always reports core events
[   104.102] (**) Power Button: Device: "/dev/input/event1"
[   104.140] (--) Power Button: Found keys
[   104.140] (II) Power Button: Configuring as keyboard
[   104.140] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
[   104.140] (**) Option "xkb_rules" "evdev"
[   104.140] (**) Option "xkb_model" "evdev"
[   104.140] (**) Option "xkb_layout" "us"
[   104.175] (II) config/udev: Adding input device Power Button (/dev/input/event0)
[   104.175] (**) Power Button: Applying InputClass "evdev keyboard catchall"
[   104.175] (**) Power Button: always reports core events
[   104.175] (**) Power Button: Device: "/dev/input/event0"
[   104.230] (--) Power Button: Found keys
[   104.230] (II) Power Button: Configuring as keyboard
[   104.230] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
[   104.230] (**) Option "xkb_rules" "evdev"
[   104.230] (**) Option "xkb_model" "evdev"
[   104.230] (**) Option "xkb_layout" "us"
[   104.237] (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event2)
[   104.237] (**) AT Translated Set 2 keyboard: Applying InputClass "evdev keyboard catchall"
[   104.237] (**) AT Translated Set 2 keyboard: always reports core events
[   104.237] (**) AT Translated Set 2 keyboard: Device: "/dev/input/event2"
[   104.270] (--) AT Translated Set 2 keyboard: Found keys
[   104.270] (II) AT Translated Set 2 keyboard: Configuring as keyboard
[   104.270] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD)
[   104.270] (**) Option "xkb_rules" "evdev"
[   104.270] (**) Option "xkb_model" "evdev"
[   104.270] (**) Option "xkb_layout" "us"
[   104.270] (II) config/udev: Adding input device PC Speaker (/dev/input/event3)
[   104.271] (II) No input driver/identifier specified (ignoring)
[   107.730] (II) AIGLX: Suspending AIGLX clients for VT switch
[   134.993] (II) AIGLX: Resuming AIGLX clients after VT switch
[   135.045] (II) RADEON(0): EDID for output VGA-0
[   135.045] (II) RADEON(0): Printing probed modes for output VGA-0
[   135.045] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   135.069] (II) RADEON(0): EDID for output VGA-1
[   135.075] (II) RADEON(0): EDID for output S-video
[   144.210] (II) RADEON(0): EDID for output VGA-0
[   144.210] (II) RADEON(0): Printing probed modes for output VGA-0
[   144.210] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   144.234] (II) RADEON(0): EDID for output VGA-1
[   144.240] (II) RADEON(0): EDID for output S-video
[   172.132] (II) AIGLX: Suspending AIGLX clients for VT switch
[   181.255] (II) AIGLX: Resuming AIGLX clients after VT switch
[   181.306] (II) RADEON(0): EDID for output VGA-0
[   181.306] (II) RADEON(0): Printing probed modes for output VGA-0
[   181.307] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   181.330] (II) RADEON(0): EDID for output VGA-1
[   181.336] (II) RADEON(0): EDID for output S-video
[   204.121] (II) AIGLX: Suspending AIGLX clients for VT switch
[   218.909] (II) AIGLX: Resuming AIGLX clients after VT switch
[   218.960] (II) RADEON(0): EDID for output VGA-0
[   218.960] (II) RADEON(0): Printing probed modes for output VGA-0
[   218.960] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   218.984] (II) RADEON(0): EDID for output VGA-1
[   218.990] (II) RADEON(0): EDID for output S-video
[   222.522] (II) RADEON(0): EDID for output VGA-0
[   222.523] (II) RADEON(0): Printing probed modes for output VGA-0
[   222.523] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   222.547] (II) RADEON(0): EDID for output VGA-1
[   222.553] (II) RADEON(0): EDID for output S-video
[   228.452] (II) RADEON(0): EDID for output VGA-0
[   228.452] (II) RADEON(0): Printing probed modes for output VGA-0
[   228.452] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   228.476] (II) RADEON(0): EDID for output VGA-1
[   228.482] (II) RADEON(0): EDID for output S-video
[   231.560] (II) AIGLX: Suspending AIGLX clients for VT switch
[   301.064] (II) AIGLX: Resuming AIGLX clients after VT switch
[   301.115] (II) RADEON(0): EDID for output VGA-0
[   301.115] (II) RADEON(0): Printing probed modes for output VGA-0
[   301.115] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   301.139] (II) RADEON(0): EDID for output VGA-1
[   301.145] (II) RADEON(0): EDID for output S-video
[   308.033] (II) RADEON(0): EDID for output VGA-0
[   308.033] (II) RADEON(0): Printing probed modes for output VGA-0
[   308.033] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   308.057] (II) RADEON(0): EDID for output VGA-1
[   308.063] (II) RADEON(0): EDID for output S-video
[   331.724] (II) AIGLX: Suspending AIGLX clients for VT switch
[   337.697] (II) AIGLX: Resuming AIGLX clients after VT switch
[   337.748] (II) RADEON(0): EDID for output VGA-0
[   337.748] (II) RADEON(0): Printing probed modes for output VGA-0
[   337.748] (II) RADEON(0): Modeline "648x480x60.00"x60.0   13.13  648 672 736 840  480 482 487 521 interlace -hsync -vsync (15.6 kHz)
[   337.772] (II) RADEON(0): EDID for output VGA-1
[   337.778] (II) RADEON(0): EDID for output S-video
[   357.375] (II) AIGLX: Suspending AIGLX clients for VT switch
[   359.349] (II) AT Translated Set 2 keyboard: Close
[   359.349] (II) UnloadModule: "evdev"
[   359.349] (II) Power Button: Close
[   359.350] (II) UnloadModule: "evdev"
[   359.350] (II) Power Button: Close
[   359.350] (II) UnloadModule: "evdev"
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 05:19:50 pm
dmesg 1 Part
Code: [Select]
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.38-rc2+ (root@mcp) (gcc version 4.4.4 (Gentoo 4.4.4-r2 p1.3, pie-0.4.5) ) #1 SMP Mon Jan 24 22:01:58 CST 2011
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
[    0.000000]  BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
[    0.000000] Notice: NX (Execute Disable) protection missing in CPU!
[    0.000000] DMI 2.3 present.
[    0.000000] DMI: GA-8S661FXM-775/ , BIOS F2 02/25/2005
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] last_pfn = 0x1fff0 max_arch_pfn = 0x100000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-CCFFF write-protect
[    0.000000]   CD000-EFFFF uncachable
[    0.000000]   F0000-FFFFF write-through
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000 mask FE0000000 write-back
[    0.000000]   1 disabled
[    0.000000]   2 disabled
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] found SMP MP-table at [c00f54f0] f54f0
[    0.000000] Scanning 0 areas for low memory corruption
[    0.000000] initial memory mapped : 0 - 01c00000
[    0.000000] init_memory_mapping: 0000000000000000-000000001fff0000
[    0.000000]  0000000000 - 0000400000 page 4k
[    0.000000]  0000400000 - 001fc00000 page 2M
[    0.000000]  001fc00000 - 001fff0000 page 4k
[    0.000000] kernel direct mapping tables up to 1fff0000 @ 1bfb000-1c00000
[    0.000000] RAMDISK: 1fc3f000 - 1ffe0000
[    0.000000] ACPI: RSDP 000f6e40 00014 (v00 GBT   )
[    0.000000] ACPI: RSDT 1fff3040 00034 (v01 GBT    AWRDACPI 42302E31 AWRD 01010101)
[    0.000000] ACPI: FACP 1fff30c0 00074 (v01 GBT    AWRDACPI 42302E31 AWRD 01010101)
[    0.000000] ACPI: DSDT 1fff3180 034EE (v01 GBT    AWRDACPI 00001000 MSFT 0100000C)
[    0.000000] ACPI: FACS 1fff0000 00040
[    0.000000] ACPI: APIC 1fff66c0 00068 (v01 GBT    AWRDACPI 42302E31 AWRD 01010101)
[    0.000000] ACPI: SSDT 1fff6770 0015C (v01  PmRef  Cpu0Ist 00003000 INTL 20040311)
[    0.000000] ACPI: SSDT 1fff6c00 0014E (v01  PmRef    CpuPm 00003000 INTL 20040311)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] 0MB HIGHMEM available.
[    0.000000] 511MB LOWMEM available.
[    0.000000]   mapped low ram: 0 - 1fff0000
[    0.000000]   low ram: 0 - 1fff0000
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   Normal   0x00001000 -> 0x0001fff0
[    0.000000]   HighMem  empty
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009f
[    0.000000]     0: 0x00000100 -> 0x0001fff0
[    0.000000] On node 0 totalpages: 130943
[    0.000000]   DMA zone: 32 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 3951 pages, LIFO batch:0
[    0.000000]   Normal zone: 992 pages used for memmap
[    0.000000]   Normal zone: 125968 pages, LIFO batch:31
[    0.000000] Using APIC driver default
[    0.000000] ACPI: PM-Timer IO Port: 0x1008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, version 20, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 40
[    0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000
[    0.000000] PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
[    0.000000] Allocating PCI resources starting at 20000000 (gap: 20000000:dec00000)
[    0.000000] Booting paravirtualized kernel on bare hardware
[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:2 nr_node_ids:1
[    0.000000] PERCPU: Embedded 12 pages/cpu @df400000 s27520 r0 d21632 u2097152
[    0.000000] pcpu-alloc: s27520 r0 d21632 u2097152 alloc=1*4194304
[    0.000000] pcpu-alloc: [0] 0 1
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129919
[    0.000000] Kernel command line: root=/dev/sda1 init=/boot/linuxrc initrd udev nodevfs CGAVGA video=VGA-1:640x480ec
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Initializing CPU#0
[    0.000000] Initializing HighMem for node 0 (00000000:00000000)
[    0.000000] Memory: 506848k/524224k available (4296k kernel code, 16924k reserved, 2678k data, 556k init, 0k highmem)
[    0.000000] virtual kernel memory layout:
[    0.000000]     fixmap  : 0xfff16000 - 0xfffff000   ( 932 kB)
[    0.000000]     pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
[    0.000000]     vmalloc : 0xe07f0000 - 0xff7fe000   ( 496 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xdfff0000   ( 511 MB)
[    0.000000]       .init : 0xc16d0000 - 0xc175b000   ( 556 kB)
[    0.000000]       .data : 0xc1432280 - 0xc16cfb40   (2678 kB)
[    0.000000]       .text : 0xc1000000 - 0xc1432280   (4296 kB)
[    0.000000] Checking if this processor honours the WP bit even in supervisor mode...Ok.
[    0.000000] SLUB: Genslabs=15, HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] RCU-based detection of stalled CPUs is disabled.
[    0.000000] NR_IRQS:2304 nr_irqs:512 16
[    0.000000] CPU 0 irqstacks, hard=df008000 soft=df00a000
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty0] enabled
[    0.000000] allocated 2621440 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 3001.013 MHz processor.
[    0.020011] Calibrating delay loop (skipped), value calculated using timer frequency.. 6002.02 BogoMIPS (lpj=30010130)
[    0.020100] pid_max: default: 32768 minimum: 301
[    0.020204] Security Framework initialized
[    0.020299] AppArmor: AppArmor initialized
[    0.020432] Mount-cache hash table entries: 512
[    0.020769] Initializing cgroup subsys ns
[    0.020819] ns_cgroup deprecated: consider using the 'clone_children' flag without the ns_cgroup.
[    0.020874] Initializing cgroup subsys cpuacct
[    0.020921] Initializing cgroup subsys memory
[    0.020976] Initializing cgroup subsys devices
[    0.021019] Initializing cgroup subsys freezer
[    0.021124] CPU: Physical Processor ID: 0
[    0.021166] CPU: Processor Core ID: 0
[    0.021210] mce: CPU supports 4 MCE banks
[    0.021275] CPU0: Thermal monitoring enabled (TM1)
[    0.021325] using mwait in idle threads.
[    0.025883] ACPI: Core revision 20110112
[    0.032687] ftrace: allocating 22184 entries in 44 pages
[    0.040132] Enabling APIC mode:  Flat.  Using 1 I/O APICs
[    0.040444] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.149324] CPU0: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 03
[    0.150000] Performance Events: Netburst events, Netburst P4/Xeon PMU driver.
[    0.150000] ... version:                0
[    0.150000] ... bit width:              40
[    0.150000] ... generic registers:      18
[    0.150000] ... value mask:             000000ffffffffff
[    0.150000] ... max period:             0000007fffffffff
[    0.150000] ... fixed-purpose events:   0
[    0.150000] ... event mask:             000000000003ffff
[    0.150000] CPU 1 irqstacks, hard=de8a6000 soft=de8b0000
[    0.150000] Booting Node   0, Processors  #1 Ok.
[    0.030000] Initializing CPU#1
[    0.310036] Brought up 2 CPUs
[    0.310126] Total of 2 processors activated (12003.89 BogoMIPS).
[    0.310872] devtmpfs: initialized
[    0.311840] print_constraints: dummy:
[    0.311909] Time: 23:02:22  Date: 02/04/11
[    0.311994] NET: Registered protocol family 16
[    0.312219] ACPI: bus type pci registered
[    0.336060] PCI: PCI BIOS revision 2.10 entry at 0xfb6d0, last bus=1
[    0.336105] PCI: Using configuration type 1 for base access
[    0.337708] bio: create slab <bio-0> at 0
[    0.337708] ACPI: EC: Look up EC in DSDT
[    0.343393] ACPI: SSDT 1fff6b70 00087 (v01  PmRef  Cpu1Ist 00003000 INTL 20040311)
[    0.343724] ACPI: Dynamic OEM Table Load:
[    0.343826] ACPI: SSDT   (null) 00087 (v01  PmRef  Cpu1Ist 00003000 INTL 20040311)
[    0.344113] ACPI: Interpreter enabled
[    0.344161] ACPI: (supports S0 S1 S4 S5)
[    0.344346] ACPI: Using IOAPIC for interrupt routing
[    0.349522] ACPI: No dock devices found.
[    0.349567] HEST: Table not found.
[    0.349610] PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug
[    0.349755] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.349987] pci_root PNP0A03:00: host bridge window [io  0x0000-0x047f] (ignored)
[    0.349992] pci_root PNP0A03:00: host bridge window [io  0x0490-0x0cf7] (ignored)
[    0.350006] pci_root PNP0A03:00: host bridge window [io  0x0d00-0x0fff] (ignored)
[    0.350011] pci_root PNP0A03:00: host bridge window [io  0x1100-0xffff] (ignored)
[    0.350015] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] (ignored)
[    0.350019] pci_root PNP0A03:00: host bridge window [mem 0x20000000-0xfebfffff] (ignored)
[    0.350040] pci 0000:00:00.0: [1039:0661] type 0 class 0x000600
[    0.350053] pci 0000:00:00.0: reg 10: [mem 0xe0000000-0xe3ffffff]
[    0.350135] pci 0000:00:01.0: [1039:0003] type 1 class 0x000604
[    0.350184] pci 0000:00:02.0: [1039:0964] type 0 class 0x000601
[    0.350279] pci 0000:00:02.5: [1039:5513] type 0 class 0x000101
[    0.350299] pci 0000:00:02.5: reg 10: [io  0x0000-0x0007]
[    0.350313] pci 0000:00:02.5: reg 14: [io  0x0000-0x0003]
[    0.350325] pci 0000:00:02.5: reg 18: [io  0x0000-0x0007]
[    0.350337] pci 0000:00:02.5: reg 1c: [io  0x0000-0x0003]
[    0.350349] pci 0000:00:02.5: reg 20: [io  0xf000-0xf00f]
[    0.350398] pci 0000:00:02.7: [1039:7012] type 0 class 0x000401
[    0.350420] pci 0000:00:02.7: reg 10: [io  0xa000-0xa0ff]
[    0.350433] pci 0000:00:02.7: reg 14: [io  0xa400-0xa47f]
[    0.350502] pci 0000:00:02.7: supports D1 D2
[    0.350506] pci 0000:00:02.7: PME# supported from D3hot D3cold
[    0.350511] pci 0000:00:02.7: PME# disabled
[    0.350530] pci 0000:00:03.0: [1039:7001] type 0 class 0x000c03
[    0.350547] pci 0000:00:03.0: reg 10: [mem 0xe7004000-0xe7004fff]
[    0.350621] pci 0000:00:03.1: [1039:7001] type 0 class 0x000c03
[    0.350637] pci 0000:00:03.1: reg 10: [mem 0xe7000000-0xe7000fff]
[    0.350709] pci 0000:00:03.2: [1039:7001] type 0 class 0x000c03
[    0.350725] pci 0000:00:03.2: reg 10: [mem 0xe7001000-0xe7001fff]
[    0.350801] pci 0000:00:03.3: [1039:7002] type 0 class 0x000c03
[    0.350822] pci 0000:00:03.3: reg 10: [mem 0xe7002000-0xe7002fff]
[    0.350896] pci 0000:00:03.3: PME# supported from D0 D3hot D3cold
[    0.350902] pci 0000:00:03.3: PME# disabled
[    0.350930] pci 0000:00:04.0: [1039:0900] type 0 class 0x000200
[    0.350951] pci 0000:00:04.0: reg 10: [io  0xa800-0xa8ff]
[    0.350964] pci 0000:00:04.0: reg 14: [mem 0xe7003000-0xe7003fff]
[    0.351013] pci 0000:00:04.0: reg 30: [mem 0x00000000-0x0001ffff pref]
[    0.351036] pci 0000:00:04.0: supports D1 D2
[    0.351040] pci 0000:00:04.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.351045] pci 0000:00:04.0: PME# disabled
[    0.351069] pci 0000:00:05.0: [1039:0180] type 0 class 0x000101
[    0.351090] pci 0000:00:05.0: reg 10: [io  0xac00-0xac07]
[    0.351102] pci 0000:00:05.0: reg 14: [io  0xb000-0xb003]
[    0.351114] pci 0000:00:05.0: reg 18: [io  0xb400-0xb407]
[    0.351126] pci 0000:00:05.0: reg 1c: [io  0xb800-0xb803]
[    0.351138] pci 0000:00:05.0: reg 20: [io  0xbc00-0xbc0f]
[    0.351150] pci 0000:00:05.0: reg 24: [io  0xc000-0xc07f]
[    0.351183] pci 0000:00:05.0: PME# supported from D3cold
[    0.351189] pci 0000:00:05.0: PME# disabled
[    0.351268] pci 0000:01:00.0: [1002:5964] type 0 class 0x000300
[    0.351289] pci 0000:01:00.0: reg 10: [mem 0xd0000000-0xd7ffffff pref]
[    0.351300] pci 0000:01:00.0: reg 14: [io  0x9000-0x90ff]
[    0.351311] pci 0000:01:00.0: reg 18: [mem 0xe5000000-0xe500ffff]
[    0.351344] pci 0000:01:00.0: reg 30: [mem 0x00000000-0x0001ffff pref]
[    0.351370] pci 0000:01:00.0: supports D1 D2
[    0.351391] pci 0000:01:00.1: [1002:5d44] type 0 class 0x000380
[    0.351408] pci 0000:01:00.1: reg 10: [mem 0xd8000000-0xdfffffff pref]
[    0.351419] pci 0000:01:00.1: reg 14: [mem 0xe5010000-0xe501ffff]
[    0.351475] pci 0000:01:00.1: supports D1 D2
[    0.351527] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    0.351574] pci 0000:00:01.0:   bridge window [io  0x9000-0x9fff]
[    0.351580] pci 0000:00:01.0:   bridge window [mem 0xe4000000-0xe5ffffff]
[    0.351586] pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff pref]
[    0.351597] pci_bus 0000:00: on NUMA node 0
[    0.351602] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.366515] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11 *12 14 15)
[    0.367026] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
[    0.367531] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
[    0.368038] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
[    0.368543] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
[    0.369050] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
[    0.369560] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 *6 7 9 10 11 12 14 15)
[    0.370080] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
[    0.370666] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.370721] vgaarb: loaded
[    0.370976] SCSI subsystem initialized
[    0.371033] libata version 3.00 loaded.
[    0.371033] usbcore: registered new interface driver usbfs
[    0.371033] usbcore: registered new interface driver hub
[    0.371033] usbcore: registered new device driver usb
[    0.371033] wmi: Mapper loaded
[    0.371033] PCI: Using ACPI for IRQ routing
[    0.371033] PCI: pci_cache_line_size set to 64 bytes
[    0.371033] reserve RAM buffer: 000000000009f800 - 000000000009ffff
[    0.371033] reserve RAM buffer: 000000001fff0000 - 000000001fffffff
[    0.383961] AppArmor: AppArmor Filesystem Enabled
[    0.384073] pnp: PnP ACPI init
[    0.384145] ACPI: bus type pnp registered
[    0.384375] pnp 00:00: [bus 00-ff]
[    0.384379] pnp 00:00: [io  0x0cf8-0x0cff]
[    0.384383] pnp 00:00: [io  0x0000-0x047f window]
[    0.384387] pnp 00:00: [io  0x0480-0x048f]
[    0.384390] pnp 00:00: [io  0x0490-0x0cf7 window]
[    0.384393] pnp 00:00: [io  0x0d00-0x0fff window]
[    0.384396] pnp 00:00: [io  0x1000-0x107f]
[    0.384399] pnp 00:00: [io  0x1080-0x10ff]
[    0.384403] pnp 00:00: [io  0x1100-0xffff window]
[    0.384406] pnp 00:00: [mem 0x000a0000-0x000bffff window]
[    0.384410] pnp 00:00: [mem 0x20000000-0xfebfffff window]
[    0.384505] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
[    0.384819] pnp 00:01: [io  0x0010-0x001f]
[    0.384823] pnp 00:01: [io  0x0022-0x003f]
[    0.384826] pnp 00:01: [io  0x0044-0x005f]
[    0.384835] pnp 00:01: [io  0x0062-0x0063]
[    0.384838] pnp 00:01: [io  0x0065-0x006f]
[    0.384841] pnp 00:01: [io  0x0074-0x007f]
[    0.384844] pnp 00:01: [io  0x0091-0x0093]
[    0.384847] pnp 00:01: [io  0x00a2-0x00bf]
[    0.384850] pnp 00:01: [io  0x00e0-0x00ef]
[    0.384853] pnp 00:01: [io  0x04d0-0x04d1]
[    0.384856] pnp 00:01: [io  0x0290-0x029f]
[    0.384859] pnp 00:01: [io  0x0800-0x0805]
[    0.384862] pnp 00:01: [io  0x0880-0x088f]
[    0.384959] system 00:01: [io  0x04d0-0x04d1] has been reserved
[    0.385005] system 00:01: [io  0x0290-0x029f] has been reserved
[    0.385050] system 00:01: [io  0x0800-0x0805] has been reserved
[    0.385095] system 00:01: [io  0x0880-0x088f] has been reserved
[    0.385141] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.385163] pnp 00:02: [dma 4]
[    0.385168] pnp 00:02: [io  0x0000-0x000f]
[    0.385172] pnp 00:02: [io  0x0080-0x0090]
[    0.385175] pnp 00:02: [io  0x0094-0x009f]
[    0.385177] pnp 00:02: [io  0x00c0-0x00df]
[    0.385230] pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.385250] pnp 00:03: [io  0x0070-0x0073]
[    0.385276] pnp 00:03: [irq 8]
[    0.385338] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.385354] pnp 00:04: [io  0x0061]
[    0.385408] pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.385425] pnp 00:05: [io  0x00f0-0x00ff]
[    0.385432] pnp 00:05: [irq 13]
[    0.385488] pnp 00:05: Plug and Play ACPI device, IDs PNP0c04 (active)
[    0.385837] pnp 00:06: [io  0x03f8-0x03ff]
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 05:20:58 pm
dmesg 2 Part

Code: [Select]
[    0.385845] pnp 00:06: [irq 4]
[    0.385944] pnp 00:06: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.386218] pnp 00:07: [io  0x02f8-0x02ff]
[    0.386227] pnp 00:07: [irq 3]
[    0.386323] pnp 00:07: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.386781] pnp 00:08: [io  0x0378-0x037f]
[    0.386785] pnp 00:08: [io  0x0778-0x077b]
[    0.386792] pnp 00:08: [irq 7]
[    0.386795] pnp 00:08: [dma 3]
[    0.386899] pnp 00:08: Plug and Play ACPI device, IDs PNP0401 (active)
[    0.386963] pnp 00:09: [io  0x0060]
[    0.386967] pnp 00:09: [io  0x0064]
[    0.386973] pnp 00:09: [irq 1]
[    0.387030] pnp 00:09: Plug and Play ACPI device, IDs PNP0303 (active)
[    0.387257] pnp 00:0a: [mem 0x000cd000-0x000cffff]
[    0.387261] pnp 00:0a: [mem 0x000f0000-0x000f7fff]
[    0.387264] pnp 00:0a: [mem 0x000f8000-0x000fbfff]
[    0.387267] pnp 00:0a: [mem 0x000fc000-0x000fffff]
[    0.387271] pnp 00:0a: [mem 0x1fff0000-0x1fffffff]
[    0.387279] pnp 00:0a: [mem 0xffff0000-0xffffffff]
[    0.387283] pnp 00:0a: [mem 0x00000000-0x0009ffff]
[    0.387287] pnp 00:0a: [mem 0x00100000-0x1ffeffff]
[    0.387290] pnp 00:0a: [mem 0xffee0000-0xffefffff]
[    0.387293] pnp 00:0a: [mem 0xfffe0000-0xfffeffff]
[    0.387296] pnp 00:0a: [mem 0xfec00000-0xfec00fff]
[    0.387300] pnp 00:0a: [mem 0xfee00000-0xfeefffff]
[    0.387386] system 00:0a: [mem 0x000cd000-0x000cffff] has been reserved
[    0.387434] system 00:0a: [mem 0x000f0000-0x000f7fff] could not be reserved
[    0.387479] system 00:0a: [mem 0x000f8000-0x000fbfff] could not be reserved
[    0.387525] system 00:0a: [mem 0x000fc000-0x000fffff] could not be reserved
[    0.389523] system 00:0a: [mem 0x1fff0000-0x1fffffff] could not be reserved
[    0.389568] system 00:0a: [mem 0xffff0000-0xffffffff] has been reserved
[    0.389614] system 00:0a: [mem 0x00000000-0x0009ffff] could not be reserved
[    0.389659] system 00:0a: [mem 0x00100000-0x1ffeffff] could not be reserved
[    0.389705] system 00:0a: [mem 0xffee0000-0xffefffff] has been reserved
[    0.389750] system 00:0a: [mem 0xfffe0000-0xfffeffff] has been reserved
[    0.389795] system 00:0a: [mem 0xfec00000-0xfec00fff] could not be reserved
[    0.389841] system 00:0a: [mem 0xfee00000-0xfeefffff] has been reserved
[    0.389892] system 00:0a: Plug and Play ACPI device, IDs PNP0c01 (active)
[    0.389906] pnp: PnP ACPI: found 11 devices
[    0.389948] ACPI: ACPI bus type pnp unregistered
[    0.428011] Switching to clocksource acpi_pm
[    0.428112] pci 0000:00:04.0: BAR 6: assigned [mem 0x20000000-0x2001ffff pref]
[    0.428170] pci 0000:01:00.0: BAR 6: assigned [mem 0xe4000000-0xe401ffff pref]
[    0.428223] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    0.428268] pci 0000:00:01.0:   bridge window [io  0x9000-0x9fff]
[    0.428316] pci 0000:00:01.0:   bridge window [mem 0xe4000000-0xe5ffffff]
[    0.428363] pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff pref]
[    0.428434] pci_bus 0000:00: resource 0 [io  0x0000-0xffff]
[    0.428438] pci_bus 0000:00: resource 1 [mem 0x00000000-0xffffffff]
[    0.428442] pci_bus 0000:01: resource 0 [io  0x9000-0x9fff]
[    0.428446] pci_bus 0000:01: resource 1 [mem 0xe4000000-0xe5ffffff]
[    0.428449] pci_bus 0000:01: resource 2 [mem 0xd0000000-0xdfffffff pref]
[    0.428512] NET: Registered protocol family 2
[    0.428644] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.428991] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
[    0.429241] TCP bind hash table entries: 16384 (order: 5, 131072 bytes)
[    0.429494] TCP: Hash tables configured (established 16384 bind 16384)
[    0.429540] TCP reno registered
[    0.429581] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.429637] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.429772] NET: Registered protocol family 1
[    0.429921] pci 0000:01:00.0: Boot video device
[    0.429929] PCI: CLS 32 bytes, default 64
[    0.429929] Trying to unpack rootfs image as initramfs...
[    0.578920] Freeing initrd memory: 3716k freed
[    0.585680] Scanning for low memory corruption every 60 seconds
[    0.585948] audit: initializing netlink socket (disabled)
[    0.586026] type=2000 audit(1296860542.579:1): initialized
[    0.600878] HugeTLB registered 4 MB page size, pre-allocated 0 pages
[    0.603762] VFS: Disk quotas dquot_6.5.2
[    0.603894] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.604720] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.605185] fuse init (API version 7.16)
[    0.605429] msgmni has been set to 997
[    0.605878] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    0.605932] io scheduler noop registered
[    0.605973] io scheduler deadline registered
[    0.606036] io scheduler cfq registered (default)
[    0.606293] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    0.606378] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    0.606700] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
[    0.606761] ACPI: Power Button [PWRB]
[    0.606900] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    0.606954] ACPI: Power Button [PWRF]
[    0.607244] ACPI: acpi_idle registered with cpuidle
[    0.609060] ERST: Table is not found!
[    0.609202] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.629822] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    0.710499] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    0.750951] 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    0.771633] 00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    0.771969] Linux agpgart interface v0.103
[    0.772060] [drm] Initialized drm 1.1.0 20060810
[    0.772136] [drm] radeon defaulting to kernel modesetting.
[    0.772179] [drm] radeon kernel modesetting enabled.
[    0.772297] radeon 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    0.774844] [drm] initializing kernel modesetting (RV280 0x1002:0x5964).
[    0.774957] [drm] register mmio base: 0xE5000000
[    0.774999] [drm] register mmio size: 65536
[    0.775377] [drm:radeon_agp_init] *ERROR* Unable to acquire AGP: -19
[    0.775422] [drm] Forcing AGP to PCI mode
[    0.775465] [drm] Generation 2 PCI interface, using max accessible memory
[    0.775514] radeon 0000:01:00.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (128M used)
[    0.775569] radeon 0000:01:00.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
[    0.775630] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    0.775674] [drm] Driver supports precise vblank timestamp query.
[    0.775765] [drm] radeon: irq initialized.
[    0.778013] [drm] Detected VRAM RAM=128M, BAR=128M
[    0.778075] [drm] RAM width 64bits DDR
[    0.778248] [TTM] Zone  kernel: Available graphics memory: 255282 kiB.
[    0.778296] [TTM] Initializing pool allocator.
[    0.778371] [drm] radeon: 128M of VRAM memory ready
[    0.778416] [drm] radeon: 512M of GTT memory ready.
[    0.778498] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    0.782167] radeon 0000:01:00.0: WB enabled
[    0.782295] [drm] Loading R200 Microcode
[    0.782576] [drm] radeon: ring at 0x00000000B0001000
[    0.782637] [drm] ring test succeeded in 1 usecs
[    0.782851] [drm] radeon: ib pool ready.
[    0.783008] [drm] ib test succeeded in 0 usecs
[    0.783445] [drm] Radeon Display Connectors
[    0.783488] [drm] Connector 0:
[    0.783528] [drm]   VGA
[    0.783568] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[    0.783612] [drm]   Encoders:
[    0.783652] [drm]     CRT1: INTERNAL_DAC1
[    0.783693] [drm] Connector 1:
[    0.783732] [drm]   VGA
[    0.783772] [drm]   DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c
[    0.783815] [drm]   Encoders:
[    0.783855] [drm]     CRT2: INTERNAL_DAC2
[    0.783896] [drm] Connector 2:
[    0.783935] [drm]   S-video
[    0.783975] [drm]   Encoders:
[    0.784014] [drm]     TV1: INTERNAL_DAC2
[    0.787930] [drm] forcing VGA-1 connector ON
[    0.802913] No connectors reported connected with modes
[    0.808684] [drm] fb mappable at 0xD0040000
[    0.808726] [drm] vram apper at 0xD0000000
[    0.808767] [drm] size 1228800
[    0.808807] [drm] fb depth is 24
[    0.808847] [drm]    pitch is 2560
[    0.872887] Console: switching to colour frame buffer device 80x30
[    0.880267] fb0: radeondrmfb frame buffer device
[    0.882451] drm: registered panic notifier
[    0.884644] [drm] Initialized radeon 2.8.0 20080528 for 0000:01:00.0 on minor 0
[    0.891396] brd: module loaded
[    0.894768] loop: module loaded
[    0.897251] i2c-core: driver [adp5520] using legacy suspend method
[    0.899733] i2c-core: driver [adp5520] using legacy resume method
[    0.902423] pata_sis 0000:00:02.5: version 0.5.2
[    0.902452] pata_sis 0000:00:02.5: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    0.905815] scsi0 : pata_sis
[    0.908548] scsi1 : pata_sis
[    0.911930] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14
[    0.914611] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15
[    0.917397] pata_acpi 0000:00:05.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    0.923065] pata_acpi 0000:00:05.0: PCI INT A disabled
[    0.926575] Fixed MDIO Bus: probed
[    0.929572] PPP generic driver version 2.4.2
[    0.932585] tun: Universal TUN/TAP device driver, 1.6
[    0.935524] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    0.938700] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.941883] ehci_hcd 0000:00:03.3: PCI INT D -> GSI 23 (level, low) -> IRQ 23
[    0.945162] ehci_hcd 0000:00:03.3: EHCI Host Controller
[    0.948513] ehci_hcd 0000:00:03.3: new USB bus registered, assigned bus number 1
[    0.955098] ehci_hcd 0000:00:03.3: irq 23, io mem 0xe7002000
[    0.970043] ehci_hcd 0000:00:03.3: USB 2.0 started, EHCI 1.00
[    0.973515] hub 1-0:1.0: USB hub found
[    0.976682] hub 1-0:1.0: 8 ports detected
[    0.979954] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.983298] ohci_hcd 0000:00:03.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[    0.986631] ohci_hcd 0000:00:03.0: OHCI Host Controller
[    0.990048] ohci_hcd 0000:00:03.0: new USB bus registered, assigned bus number 2
[    0.996572] ohci_hcd 0000:00:03.0: irq 20, io mem 0xe7004000
[    1.052232] hub 2-0:1.0: USB hub found
[    1.055582] hub 2-0:1.0: 3 ports detected
[    1.059046] ohci_hcd 0000:00:03.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
[    1.062525] ohci_hcd 0000:00:03.1: OHCI Host Controller
[    1.065905] ohci_hcd 0000:00:03.1: new USB bus registered, assigned bus number 3
[    1.072631] ohci_hcd 0000:00:03.1: irq 21, io mem 0xe7000000
[    1.090417] ata1.00: HPA detected: current 78163247, native 78165360
[    1.093916] ata1.00: ATA-5: ST340016A, 3.19, max UDMA/100
[    1.097381] ata1.00: 78163247 sectors, multi 16: LBA
[    1.100802] ata1.01: ATAPI: Compaq  DVD-ROM SD-616T, F304, max UDMA/44
[    1.104224] ata1.00: limited to UDMA/33 due to 40-wire cable
[    1.107641] ata1.01: limited to UDMA/33 due to 40-wire cable
[    1.132236] hub 3-0:1.0: USB hub found
[    1.135468] hub 3-0:1.0: 3 ports detected
[    1.138695] ohci_hcd 0000:00:03.2: PCI INT C -> GSI 22 (level, low) -> IRQ 22
[    1.142043] ohci_hcd 0000:00:03.2: OHCI Host Controller
[    1.145360] ohci_hcd 0000:00:03.2: new USB bus registered, assigned bus number 4
[    1.150871] ata1.00: configured for UDMA/33
[    1.155310] ohci_hcd 0000:00:03.2: irq 22, io mem 0xe7001000
[    1.170393] ata1.01: configured for UDMA/33
[    1.174086] scsi 0:0:0:0: Direct-Access     ATA      ST340016A        3.19 PQ: 0 ANSI: 5
[    1.180903] sd 0:0:0:0: [sda] 78163247 512-byte logical blocks: (40.0 GB/37.2 GiB)
[    1.181017] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    1.191531] scsi 0:0:1:0: CD-ROM            Compaq   DVD-ROM SD-616T  F304 PQ: 0 ANSI: 5
[    1.191772] sd 0:0:0:0: [sda] Write Protect is off
[    1.191785] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    1.191941] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.212218] hub 4-0:1.0: USB hub found
[    1.215644] hub 4-0:1.0: 2 ports detected
[    1.219219] uhci_hcd: USB Universal Host Controller Interface driver
[    1.222797] Initializing USB Mass Storage driver...
[    1.226302] usbcore: registered new interface driver usb-storage
[    1.229931] USB Mass Storage support registered.
[    1.233587] usbcore: registered new interface driver ums-alauda
[    1.237274] usbcore: registered new interface driver ums-datafab
[    1.240859] usbcore: registered new interface driver ums-freecom
[    1.244337] usbcore: registered new interface driver ums-isd200
[    1.247741] usbcore: registered new interface driver ums-jumpshot
[    1.251019] usbcore: registered new interface driver ums-sddr09
[    1.254205]  sda: sda1 sda2
[    1.254473] usbcore: registered new interface driver ums-sddr55
[    1.254625] usbcore: registered new interface driver ums-usbat
[    1.254927] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[    1.254946] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[    1.255383] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.256265] mousedev: PS/2 mouse device common for all mice
[    1.257120] rtc_cmos 00:03: RTC can wake from S4
[    1.257174] sr0: scsi3-mmc drive: 0x/40x cd/rw xa/form2 cdda tray
[    1.257216] cdrom: Uniform CD-ROM driver Revision: 3.20
[    1.258073] sr 0:0:1:0: Attached scsi CD-ROM sr0
[    1.258635] sr 0:0:1:0: Attached scsi generic sg1 type 5
[    1.280608] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[    1.297911] sd 0:0:0:0: [sda] Attached SCSI disk
[    1.310115] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[    1.313206] rtc0: alarms up to one year, 242 bytes nvram
[    1.316406] device-mapper: uevent: version 1.0.3
[    1.319529] device-mapper: ioctl: 4.19.1-ioctl (2011-01-07) initialised: dm-devel@redhat.com
[    1.325788] device-mapper: multipath: version 1.2.0 loaded
[    1.329071] device-mapper: multipath round-robin: version 1.0.0 loaded
[    1.332674] cpuidle: using governor ladder
[    1.336099] cpuidle: using governor menu
[    1.339920] TCP cubic registered
[    1.343288] NET: Registered protocol family 17
[    1.346648] Registering the dns_resolver key type
[    1.351031] Using IPI No-Shortcut mode
[    1.354544] PM: Hibernation image not present or could not be loaded.
[    1.354564] registered taskstats version 1
[    1.358114]   Magic number: 15:675:48
[    1.361484] rtc_cmos 00:03: setting system clock to 2011-02-04 23:02:23 UTC (1296860543)
[    1.368050] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[    1.371470] EDD information not available.
[    1.410159] Freeing unused kernel memory: 556k freed
[    1.414274] Write protecting the kernel text: 4300k
[    1.417672] Write protecting the kernel read-only data: 2312k
[    1.580143] Refined TSC clocksource calibration: 3000.852 MHz.
[    1.580153] Switching to clocksource tsc
[    3.852965] sata_sis 0000:00:05.0: version 1.0
[    3.853008] sata_sis 0000:00:05.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    3.853020] sata_sis 0000:00:05.0: Detected SiS 180/181/964 chipset in SATA mode
[    3.855339] scsi2 : sata_sis
[    3.856075] scsi3 : sata_sis
[    3.856779] ata3: SATA max UDMA/133 cmd 0xac00 ctl 0xb000 bmdma 0xbc00 irq 17
[    3.856784] ata4: SATA max UDMA/133 cmd 0xb400 ctl 0xb800 bmdma 0xbc08 irq 17
[    4.210849] ata3: SATA link down (SStatus 0 SControl 300)
[    4.570840] ata4: SATA link down (SStatus 0 SControl 300)
[    5.471637] scsi: <fdomain> Detection failed (no card)
[    5.561429] GDT-HA: Storage RAID Controller Driver. Version: 3.05
[    5.843805] imm: Version 2.05 (for Linux 2.4.0)
[    6.238045] Fusion MPT base driver 3.04.17
[    6.238051] Copyright (c) 1999-2008 LSI Corporation
[    6.391885] Fusion MPT SPI Host driver 3.04.17
[    6.522415] Fusion MPT FC Host driver 3.04.17
[    6.634231] Fusion MPT SAS Host driver 3.04.17
[    6.705976] 3ware Storage Controller device driver for Linux v1.26.02.003.
[    6.779065] 3ware 9000 Storage Controller device driver for Linux v2.26.02.014.
[    6.851727] Compaq SMART2 Driver (v 2.6.0)
[    6.974222] HP CISS Driver (v 3.6.26)
[    7.200567] Adaptec aacraid driver 1.1-5[26400]-ms
[    7.369931] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006)
[    7.374315] megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006)
[    7.546688] megasas: 00.00.05.29-rc1 Tue. Dec. 7 17:00:00 PDT 2010
[    7.639504] QLogic Fibre Channel HBA Driver: 8.03.05-k0
[    7.738068] Emulex LightPulse Fibre Channel SCSI driver 8.3.20
[    7.738073] Copyright(c) 2004-2009 Emulex.  All rights reserved.
[    7.964979] aic94xx: Adaptec aic94xx SAS/SATA driver version 1.0.3 loaded
[    8.166341] usbcore: registered new interface driver usbhid
[    8.166349] usbhid: USB HID core driver
[    8.248291] sl811: driver sl811-hcd, 19 May 2005
[    8.653906] md: raid0 personality registered for level 0
[    8.738401] md: raid1 personality registered for level 1
[    9.030063] raid6: int32x1    629 MB/s
[    9.200025] raid6: int32x2    824 MB/s
[    9.370011] raid6: int32x4    753 MB/s
[    9.540077] raid6: int32x8    524 MB/s
[    9.710012] raid6: mmxx1     1827 MB/s
[    9.880034] raid6: mmxx2     2150 MB/s
[   10.050050] raid6: sse1x1    1111 MB/s
[   10.220026] raid6: sse1x2    1230 MB/s
[   10.390037] raid6: sse2x1    2223 MB/s
[   10.560034] raid6: sse2x2    1851 MB/s
[   10.560037] raid6: using algorithm sse2x1 (2223 MB/s)
[   10.598870] async_tx: api initialized (async)
[   10.617449] xor: automatically using best checksumming function: pIII_sse
[   10.660012]    pIII_sse  :  4486.800 MB/sec
[   10.660016] xor: using function: pIII_sse (4486.800 MB/sec)
[   10.724016] md: raid6 personality registered for level 6
[   10.724024] md: raid5 personality registered for level 5
[   10.724029] md: raid4 personality registered for level 4
[   10.821498] md: raid10 personality registered for level 10
[   11.021354] JFS: nTxBlock = 3993, nTxLock = 31945
[   11.196128] RPC: Registered udp transport module.
[   11.196135] RPC: Registered tcp transport module.
[   11.196141] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   11.232088] FS-Cache: Loaded
[   11.310969] FS-Cache: Netfs 'nfs' registered for caching
[   11.474903] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
[   11.478002] SGI XFS Quota Management subsystem
[   11.581640] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[   11.581648] e1000: Copyright (c) 1999-2006 Intel Corporation.
[   11.784932] Loading iSCSI transport class v2.0-870.
[   12.029268] iscsi: registered transport (tcp)
[   16.225678] EXT3-fs (sda1): error: couldn't mount because of unsupported optional features (240)
[   16.225952] EXT2-fs (sda1): error: couldn't mount because of unsupported optional features (240)
[   16.261509] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[   18.266629] udev: starting version 151
[   18.266772] udevd (10930): /proc/10930/oom_adj is deprecated, please use /proc/10930/oom_score_adj instead.
[   18.441262] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[   18.713187] agpgart-sis 0000:00:00.0: SiS chipset [1039/0661]
[   18.720641] agpgart-sis 0000:00:00.0: AGP aperture is 64M @ 0xe0000000
[   18.744437] parport_pc 00:08: reported by Plug and Play ACPI
[   18.744517] parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
[   18.849800] input: PC Speaker as /devices/platform/pcspkr/input/input3
[   18.862627] sis900.c: v1.08.10 Apr. 2 2006
[   18.862764] sis900 0000:00:04.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[   18.863832] 0000:00:04.0: ICS LAN PHY transceiver found at address 1.
[   18.874721] 0000:00:04.0: Using transceiver found at address 1 as default
[   18.876077] eth0: SiS 900 PCI Fast Ethernet at 0xa800, IRQ 19, 00:0f:ea:e3:89:ea
[   18.917304] ppdev: user-space parallel port driver
[   20.074740] EXT4-fs (sda1): re-mounted. Opts: (null)
[   20.785856] Adding 1967956k swap on /dev/sda2.  Priority:-1 extents:1 across:1967956k
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 05:22:36 pm
Glxinfo
Code: [Select]
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_INTEL_swap_event
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap,
    GLX_INTEL_swap_event
GLX version: 1.4
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap,
    GLX_INTEL_swap_event
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R200 (RV280 5964) 20090101 x86/MMX/SSE2 TCL DRI2
OpenGL version string: 1.3 Mesa 7.9
OpenGL extensions:
    GL_ARB_draw_buffers, GL_ARB_imaging, GL_ARB_multisample,
    GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters,
    GL_ARB_point_sprite, GL_ARB_texture_border_clamp,
    GL_ARB_texture_compression, GL_ARB_texture_cube_map,
    GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
    GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,
    GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle,
    GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object,
    GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra,
    GL_EXT_blend_color, GL_EXT_blend_equation_separate,
    GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax,
    GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_convolution,
    GL_EXT_copy_texture, GL_EXT_draw_range_elements,
    GL_EXT_framebuffer_object, GL_EXT_fog_coord, GL_EXT_histogram,
    GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil,
    GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset,
    GL_EXT_rescale_normal, GL_EXT_secondary_color,
    GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture,
    GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_cube_map,
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
    GL_EXT_texture_mirror_clamp, GL_EXT_texture_object,
    GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels,
    GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3,
    GL_ATI_texture_mirror_once, GL_ATI_fragment_shader,
    GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip,
    GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
    GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos,
    GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_packed_depth_stencil,
    GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_OES_read_format,
    GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap,
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp,
    GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays

64 GLX Visuals
   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x21 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x22 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0xb9 24 tc  0 24  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0xba 24 tc  0 24  0 r  .  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0xbb 24 tc  0 24  0 r  y  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0xbc 24 tc  0 24  0 r  y  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0xbd 24 tc  0 24  0 r  .  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0xbe 24 tc  0 24  0 r  .  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0xbf 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0xc0 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0xc1 24 tc  0 24  0 r  .  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0xc2 24 tc  0 24  0 r  .  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0xc3 24 tc  0 24  0 r  y  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0xc4 24 tc  0 24  0 r  y  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0xc5 24 tc  0 24  0 r  .  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0xc6 24 tc  0 24  0 r  .  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0xc7 24 tc  0 24  0 r  y  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0xc8 24 tc  0 24  0 r  y  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0xc9 24 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0xca 24 tc  0 32  0 r  .  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0xcb 24 tc  0 32  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0xcc 24 tc  0 32  0 r  y  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0xcd 24 tc  0 32  0 r  .  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0xce 24 tc  0 32  0 r  .  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0xcf 24 tc  0 32  0 r  y  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0xd0 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0xd1 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0xd2 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0xd3 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0xd4 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0xd5 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0xd6 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0xd7 24 dc  0 24  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0xd8 24 dc  0 24  0 r  .  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0xd9 24 dc  0 24  0 r  y  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0xda 24 dc  0 24  0 r  y  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0xdb 24 dc  0 24  0 r  .  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0xdc 24 dc  0 24  0 r  .  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0xdd 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0xde 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0xdf 24 dc  0 24  0 r  .  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0xe0 24 dc  0 24  0 r  .  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0xe1 24 dc  0 24  0 r  y  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0xe2 24 dc  0 24  0 r  y  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0xe3 24 dc  0 24  0 r  .  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0xe4 24 dc  0 24  0 r  .  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0xe5 24 dc  0 24  0 r  y  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0xe6 24 dc  0 24  0 r  y  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0xe7 24 dc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0xe8 24 dc  0 32  0 r  .  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0xe9 24 dc  0 32  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0xea 24 dc  0 32  0 r  y  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0xeb 24 dc  0 32  0 r  .  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0xec 24 dc  0 32  0 r  .  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0xed 24 dc  0 32  0 r  y  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0xee 24 dc  0 32  0 r  y  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0xef 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0xf0 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0xf1 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0xf2 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0xf3 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0xf4 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0xf5 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x58 32 tc  0 32  0 r  y  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None

96 GLXFBConfigs:
   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x59  0 tc  0 16  0 r  .  .  5  6  5  0  0  0  0  0  0  0  0  0 0 None
0x5a  0 tc  0 16  0 r  .  .  5  6  5  0  0  0  0 16 16 16  0  0 0 Slow
0x5b  0 tc  0 16  0 r  y  .  5  6  5  0  0  0  0  0  0  0  0  0 0 None
0x5c  0 tc  0 16  0 r  y  .  5  6  5  0  0  0  0 16 16 16  0  0 0 Slow
0x5d  0 tc  0 16  0 r  .  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x5e  0 tc  0 16  0 r  .  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x5f  0 tc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x60  0 tc  0 16  0 r  y  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x61  0 tc  0 16  0 r  .  .  5  6  5  0  0 24  0  0  0  0  0  0 0 None
0x62  0 tc  0 16  0 r  .  .  5  6  5  0  0 24  0 16 16 16  0  0 0 Slow
0x63  0 tc  0 16  0 r  y  .  5  6  5  0  0 24  0  0  0  0  0  0 0 None
0x64  0 tc  0 16  0 r  y  .  5  6  5  0  0 24  0 16 16 16  0  0 0 Slow
0x65  0 tc  0 16  0 r  .  .  5  6  5  0  0 24  8  0  0  0  0  0 0 None
0x66  0 tc  0 16  0 r  .  .  5  6  5  0  0 24  8 16 16 16  0  0 0 Slow
0x67  0 tc  0 16  0 r  y  .  5  6  5  0  0 24  8  0  0  0  0  0 0 None
0x68  0 tc  0 16  0 r  y  .  5  6  5  0  0 24  8 16 16 16  0  0 0 Slow
0x69  0 tc  0 24  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0x6a  0 tc  0 24  0 r  .  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0x6b  0 tc  0 24  0 r  y  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0x6c  0 tc  0 24  0 r  y  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0x6d  0 tc  0 24  0 r  .  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0x6e  0 tc  0 24  0 r  .  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0x6f  0 tc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0x70  0 tc  0 24  0 r  y  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0x71  0 tc  0 24  0 r  .  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0x72  0 tc  0 24  0 r  .  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0x73  0 tc  0 24  0 r  y  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0x74  0 tc  0 24  0 r  y  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0x75  0 tc  0 24  0 r  .  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0x76  0 tc  0 24  0 r  .  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0x77  0 tc  0 24  0 r  y  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0x78  0 tc  0 24  0 r  y  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0x79  0 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x7a  0 tc  0 32  0 r  .  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0x7b  0 tc  0 32  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x7c  0 tc  0 32  0 r  y  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0x7d  0 tc  0 32  0 r  .  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0x7e  0 tc  0 32  0 r  .  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0x7f  0 tc  0 32  0 r  y  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0x80  0 tc  0 32  0 r  y  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0x81  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x82  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x83  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x84  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x85  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x86  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x87  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x88  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x89  0 dc  0 16  0 r  .  .  5  6  5  0  0  0  0  0  0  0  0  0 0 None
0x8a  0 dc  0 16  0 r  .  .  5  6  5  0  0  0  0 16 16 16  0  0 0 Slow
0x8b  0 dc  0 16  0 r  y  .  5  6  5  0  0  0  0  0  0  0  0  0 0 None
0x8c  0 dc  0 16  0 r  y  .  5  6  5  0  0  0  0 16 16 16  0  0 0 Slow
0x8d  0 dc  0 16  0 r  .  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x8e  0 dc  0 16  0 r  .  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x8f  0 dc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x90  0 dc  0 16  0 r  y  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x91  0 dc  0 16  0 r  .  .  5  6  5  0  0 24  0  0  0  0  0  0 0 None
0x92  0 dc  0 16  0 r  .  .  5  6  5  0  0 24  0 16 16 16  0  0 0 Slow
0x93  0 dc  0 16  0 r  y  .  5  6  5  0  0 24  0  0  0  0  0  0 0 None
0x94  0 dc  0 16  0 r  y  .  5  6  5  0  0 24  0 16 16 16  0  0 0 Slow
0x95  0 dc  0 16  0 r  .  .  5  6  5  0  0 24  8  0  0  0  0  0 0 None
0x96  0 dc  0 16  0 r  .  .  5  6  5  0  0 24  8 16 16 16  0  0 0 Slow
0x97  0 dc  0 16  0 r  y  .  5  6  5  0  0 24  8  0  0  0  0  0 0 None
0x98  0 dc  0 16  0 r  y  .  5  6  5  0  0 24  8 16 16 16  0  0 0 Slow
0x99  0 dc  0 24  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0x9a  0 dc  0 24  0 r  .  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0x9b  0 dc  0 24  0 r  y  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0x9c  0 dc  0 24  0 r  y  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0x9d  0 dc  0 24  0 r  .  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0x9e  0 dc  0 24  0 r  .  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0x9f  0 dc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0xa0  0 dc  0 24  0 r  y  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0xa1  0 dc  0 24  0 r  .  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0xa2  0 dc  0 24  0 r  .  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0xa3  0 dc  0 24  0 r  y  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0xa4  0 dc  0 24  0 r  y  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0xa5  0 dc  0 24  0 r  .  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0xa6  0 dc  0 24  0 r  .  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0xa7  0 dc  0 24  0 r  y  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0xa8  0 dc  0 24  0 r  y  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0xa9  0 dc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0xaa  0 dc  0 32  0 r  .  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0xab  0 dc  0 32  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0xac  0 dc  0 32  0 r  y  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0xad  0 dc  0 32  0 r  .  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0xae  0 dc  0 32  0 r  .  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0xaf  0 dc  0 32  0 r  y  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0xb0  0 dc  0 32  0 r  y  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0xb1  0 dc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0xb2  0 dc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0xb3  0 dc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0xb4  0 dc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0xb5  0 dc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0xb6  0 dc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0xb7  0 dc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0xb8  0 dc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 05:27:03 pm
mame: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.

The mame error that you see, it seems to have to do with mesa and opengl somehow.  When did that error start exactly, it's odd because there have not been any changes to opengl recently and the old kernel doesn't fix it either so that's not the issue then.  Isn't Calamity using the same card too, it seemed to work on his, so definitely strange.  All the logs look good, like things *should* work, but somehow it's hitting that issue and it's an old issue it seems...

https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/656100

So doesn't seem like it should be happening anymore, or if it had it should have always been doing that.

Also the audio warnings are easy to get rid of with 'audiodriver dsp', it's choosing that after trying alsa basically but it is cleaner to add that to the mame.ini.  I probably will add that.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 05:36:36 pm
Quote
Hello bitbytebit tests with LiveCD32-Full-1.368-33e345e.iso

Grub still fails, you can make a solution a bit sloppy as to create initrd vmlinuz symlinks in /

I think you should warn for newbies to choose the home directory is to put it on a partition other than the installation because it can not be installed, as well as data.

Here I have my doubts if you choose a partition to install the live and another to take home, which creates data?
Do not think it is best to default data within the home? Sorry for insisting on this, but I think it would be as easy for any newbies.

For xterm loads. xinitrc? If you hide the mouse, remove gdm etc. .. is to make it look as possible to the system, no? to me it has worked well without putting advmenu xterm.

After installation, the boot does not directly load X, it waits console login.
What application do you use to autologin? mingetty ...?

I tried mame and mess, but I can not always run the libraries fail with Alsa, but alsa or oss configure the installation, always the same error of libraries alsa, and I can not run any game.
I do not think that imaging can be corrupt, and I set advmenu to sound a mp3 while you're on the list of games working well, so it can be a bad compilation, right?

Another thing that would be interesting is that the arcade user can use the shutdown command to turn off the machine from a key or key combination, I was wearing with 2 +5 key in msdos, but in linux I have not been able to do not function to run shutdown from regular user.



Thank you and Goodnight today.


I think it was from here, no update Xorg? then there is no solution for AVGA 9250? I can do?

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 04, 2011, 05:55:40 pm
I'm testing the webmin thing right now and it is absolutely amazing how easy it's everything now. Still exploring it and finding out stuff. I've managed to put some roms thanks to the network folders now available as /home and /roms (shouldn't be any for snaps?) and finally been able to play 'normal' roms on this system, it's really awesome.

I'm having an issue however when trying to mount my ntfs partition, I'm doing it like this:
(http://img689.imageshack.us/img689/5859/mountj.png) (http://img689.imageshack.us/i/mountj.png/)

It actually gets mounted and I'm able to browse the file system with the file manager provided in webmin. So that drive is mounted as /calamity and I can see it also in lxde, but when I try to get into it it says "permission denied". Then I'm trying to use it to point its rom directory as /calamity/Roms/Mame, either in advmenu.rc and mame.ini, but AdvMenu complains something like "no Mame game found to match the filter selected" so it seems it can't use that folder for the same reason. Do you have any clue why this could happen?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 06:04:12 pm
I'm testing the webmin thing right now and it is absolutely amazing how easy it's everything now. Still exploring it and finding out stuff. I've managed to put some roms thanks to the network folders now available as /home and /roms (shouldn't be any for snaps?) and finally been able to play 'normal' roms on this system, it's really awesome.

I'm having an issue however when trying to mount my ntfs partition, I'm doing it like this:
(http://img689.imageshack.us/img689/5859/mountj.png) (http://img689.imageshack.us/i/mountj.png/)

It actually gets mounted and I'm able to browse the file system with the file manager provided in webmin. So that drive is mounted as /calamity and I can see it also in lxde, but when I try to get into it it says "permission denied". Then I'm trying to use it to point its rom directory as /calamity/Roms/Mame, either in advmenu.rc and mame.ini, but AdvMenu complains something like "no Mame game found to match the filter selected" so it seems it can't use that folder for the same reason. Do you have any clue why this could happen?

It sounds like a permissions issue, I am thinking possibly the unix permissions it's getting are disallowing you from reading it.  check the 'ls -altr' output, see what the permissions are, try to access it after doing 'sudo -s' with ls and see what it does then.  It can only do read only for ntfs, so can't change or hurt anything, might have to do some trick with root access I guess to be able to utilize them (or become root, and copy them over, at least to test).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 04, 2011, 06:17:39 pm
Yes, I could get in there from the xterm by doing sudo -s and then cd /calamity, so it seems permision related. Problem is I can't invoke Switchres (doesn't find Mame) or AdvMenu from there...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 06:19:40 pm
Hello AVGA I use is 9250, with the kernel version 2.6.38-rc2+ ,but with the new rc +3 no way it will work, the X function but loading mame not think that's why the error was radeon .....
Code: [Select]
penGL: PBO not supported
mame: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.
Aborted

The bash_profile not believe it has to be done manually.


You could put the old kernel to install it myself, and so that it works or not?

I am pretty sure I can fix this bug, I found that it seems the version of Mesa 7.9 we are using needs to be upgraded to 7.9.1 and that is where the fix is for your radeon card with the r200 chip in it.

I should have this fixed in the next ISO image, you can run this on an install and test this fix right now...

autounmask media-libs/mesa-7.9.1
emerge -av mesa

That should update your Mesa, and fix it hopefully.

Thanks,
Chris
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 06:21:52 pm
Yes, I could get in there from the xterm by doing sudo -s and then cd /calamity, so it seems permision related. Problem is I can't invoke Switchres (doesn't find Mame) or AdvMenu from there...

Right, you won't want to run mame or switchres as root like that, but check the 'ls -altr' output of the files/directories under there and let me see that part (send me a msg w/it attached).  We'll have to look into what people normally do with NTFS file systems, although I *think* the way would be by specifying a user as the files permissions at the mount command line.  That's what you have to do with windows shares and NFS shares sometimes.

Ahha, you probably just have to specify in that menu setup in webmin the user as arcade and group arcade, maybe even let users mount the drive too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 04, 2011, 06:33:04 pm
Here it goes...

BTW previously in Windows I had changed the properties of the drive to share all of it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 06:35:27 pm
Here it goes...

Yeah, I updated the last post, I think you'll just need to say it's owned by the arcade user in those options in the webmin setup for the drive, and maybe set it so users can mount it too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 06:43:27 pm
Hi, I have the solution for apgar the pc from the user advmenu arcade.

Code: [Select]
groupadd shutdown
Code: [Select]
add arcade to the group shutdown
check this created the user group and has arcade
Code: [Select]
shutdown:x:1002:arcade...
now with the command visudo, add the following lines

Code: [Select]
%shutdown ALL=(root) NOPASSWD: /sbin/reboot
%shutdown ALL=(root) NOPASSWD: /sbin/halt
%shutdown ALL=(root) NOPASSWD: /sbin/shutdown

And finally create the alias .bashrc

Code: [Select]
alias shutdown = ' sudo shutdown -h now'
alias shutdown = ' sudo halt '
alias halt = ' sudo halt'
alias halt = ' sudo shutdown -h now'


This all tested from the console, since I have done with a virtual machine, so I need to check that advmenu off the pc.


Thank





Actually just doing this..

alias poweroff='sudo halt'

At the top of /home/arcade/.bash_profile

Should allow advmenu to halt the machine and shutdown basically.  The arcade user already can run sudo without a password and advmame calls poweroff to shutdown the machine :).


Or actually just this in .xinitrc...


#
#
export PATH=/usr/local/bin:/usr/games/bin:$PATH
alias poweroff='sudo halt'
xhost +
xsetroot -cursor .emptycursor .emptycursor
advmenu


Test that and see if it works



Update: Actually you'll probably have to do this, it probably is the only way:

rm /sbin/poweroff
touch /sbin/poweroff
chmod 755 /sbin/poweroff
echo '#!/bin/bash' > /sbin/poweroff
echo "sudo halt" >> /sbin/poweroff

poweroff is normally a symlink to /sbin/halt, that is what advmenu calls.  The aliases won't work because advmenu calls the full path to poweroff as /sbin/poweroff and an alias can't have a path.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 04, 2011, 06:47:53 pm
Yeah, I updated the last post, I think you'll just need to say it's owned by the arcade user in those options in the webmin setup for the drive, and maybe set it so users can mount it too.

That was it! It's working! I can access all my games and snaps from AdvMenu now.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 04, 2011, 07:31:33 pm
Hello, I do not feel the eyes and I'm a little crazy  :'(

It works well, and you can configure a key or key combination to turn off the machine.
Quote
rm /sbin/poweroff
touch /sbin/poweroff
chmod 755 /sbin/poweroff
echo '#!/bin/bash' > /sbin/poweroff
echo "sudo halt" >> /sbin/poweroff


And now the most important, I think some had taken me as a bit  :angry: :banghead: But I have to say I am ..........

Quote
autounmask media-libs/mesa-7.9.1
emerge -av mesa

But now if you suck and everything is working properly
Thank you very much, now you can get a final version, to new updates.

So if I have 2 days I will not stop testing versions and versions  :banghead: :banghead:, and you made me no error case OpneGL  ;)







Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 04, 2011, 07:38:17 pm
Hello, I do not feel the eyes and I'm a little crazy  :'(

It works well, and you can configure a key or key combination to turn off the machine.
Quote
rm /sbin/poweroff
touch /sbin/poweroff
chmod 755 /sbin/poweroff
echo '#!/bin/bash' > /sbin/poweroff
echo "sudo halt" >> /sbin/poweroff


And now the most important, I think some had taken me as a bit  :angry: :banghead: But I have to say I am ..........

Quote
autounmask media-libs/mesa-7.9.1
emerge -av mesa

But now if you suck and everything is working properly
Thank you very much, now you can get a final version, to new updates.

So if I have 2 days I will not stop testing versions and versions  :banghead: :banghead:, and you made me no error case OpneGL  ;)









Sounds good, yeah I am building ISO's right now, looks like there's a lot of good fixes including mame 0141u1 fixed discrete audio too so mario and asteroids galaxian sounds work right again.  I guess they posted the fix a few hours after the release, so that is really cool since the mario issue was a bummer, now everything is working correctly with mario and even sounds nicer than in the past I think.

Also there's a fix for the console not interlacing for the 5450 radeon boards, or probably all the newer ones basically, I think it might do vblanking actually (need to test it more).  So we may just have support for newer Radeon cards now too in the 5xxx series.

Also that patch, I'm not sure, but it may fix that rs690 issue, will have to see with the next ISO and test it for me.  If not it's close, I haven't been able to test the patch with my 5450 yet but I get the feeling it's good there.  It at least could help Alex see how to fix the rs690, I'm guessing it's a similar issue in that part of the driver.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 05, 2011, 01:31:04 pm
I'm testing again and this really rocks. All games running smooth like silk, and this cd finally being so close to a plug and play thing.

I'm surprised to see that you've implemented some kind of soundsync also in Linux? For instance, Contra runs at 92% of its speed, which is normal as my monitor can't do any better having that game 280 lines of height, but... sound should be choppy because of that but it's perfect, what have you done? I remind from previous versions that in these cases when vfreq was unable to catch the original you were not using vsync and activating throttle instead, so I'm happy to see it's not necessary any more ?!?

There's a weak point however with stretched vertical games, for some reason opengl unevenstretch does not achieve such good results as ddraw hwstretch, so virtualized resolutions have a lot of flicker. It seems the method they're using for stretching is different, don't know the reason, but stretching with ddraw looks smoother, maybe it could be benefiting there from some hardware feature not available from Linux?

Twincobra runs at 98% of it's speed, the same thing happens in Windows. I thought it was a flaw of the modeline generator but not, it's again a badly reported vfreq by mame.xml, so it's reported as 54.000 Hz but then when during the game you go to game information it says it's actually 54.87 Hz. So they're misleading Switchres with that.

Also when pressing f11 to check the game speed, the screen gets full of rubbish for some reason, not important anyway. On the wish list side it could be great to figure out a way of having pixel perfect menu fonts and not the filtered crap they do since recent versions of Mame, I've been making some tests on that and does not look easy to fix however.

I've seen that changing the monitor orientation from your menu does not have any effect once you've been playing for a while.

Snes and Megadrive also work fine at full screen but they're using an interlaced resolution, have you achieved anything better on your system or are we limited to that?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 05, 2011, 02:28:09 pm
Good to hear, hopefully I can get some things tied up in the next day with trimming out some of the extra stuff and some issues with the 32bit gens on the 64bit cd.  I realized these last ISO's were bigger, because of a dependency issue of the nvidia driver version and the older opengl, but have fixed that, so it should allow the trimming down of the extra packages again (it refused to remove anything when the dependencies were not all fully met). 

I'm not sure how the sound is being nicer in Linux, but good to hear that too, and also the stretching is interesting and I've always wondered why they have different things in Linux and Windows for that.  In fact you would think if it's possible in Windows it is too in Linux, it's the same hardware, just maybe either not implemented in Mame or the Linux drivers *yet*.  I will look at that more, also I suspect in Linux the interlacing might be different perhaps, but not sure why, although I do know they don't do the page flip vertical blank timestamping yet for interlacing or doublescan.  So maybe that's it, they have comments in the kernel that they haven't tackled that issue yet.

Yeah I've seen that certain games run at 98.9% and stuff like that, or even more off, and it doesn't seem to be any factor besides us not knowing the original resolution.  I wonder if there's a lot of games where things haven't been really calculated accurately and it makes sense because they aren't fully targeting playing them like we are on arcade monitors at the original resolution.  It seems if true, that's pretty sad, things aren't being documented, but I suspect it's more of an issue with the difficulty of measuring the original PCB and finding one working at original speed as it is.  I never actually notice though anything wrong with those games, like virtua racer, that just can't get that 100% perfection like pacman can.

What do you mean about the orientation, technically it's just setting mo=1 or mo=2 in /home/arcade/switchres.conf to do that, of course also one needs to edit advmenu config too but not as important for now (I probably need to get more into making configuration interfaces for these things).  It should hold, but suspect maybe it's something todo actually with mame then?  Sounds strange, not sure.

I haven't looked into the other emulators much yet, did that awhile back but mostly just let them go at what mess said.  Some of them are tricky because they weren't programmed to actually run at the original resolution or the configuration has to be really setup just right to do that.   So they need some going through, maybe even some changing internally I suspect to get them to easily do things right.  Of course on this d9800 it never needs to do interlaced resolutions, so maybe that's the main issue, and it might go back to the interlacing needing improvements in Linux still and also possibly the need to look at what those emulators want in resolution and reducing it to the original which an arcade monitor should be able to do.

I'm uploading a new 32bit ISO today, but won't have it in place to download till later tonight.  Mainly just a smaller more trimmed down ISO without extra packages, and all the fixes we've had lately.  There is one up right now, but it had the extra stuff in it so should be good too but this one has a cleaner build I like more.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 05, 2011, 03:31:21 pm
I've figured up the virtualize (interlaced) issue, it was only needed to set 'filter' on in mame.ini, OpenGL-specific options. Now it looks exactly as in Windows when hwstretch is on. At the cost of loosing some sharpness you have a much more bearable flicker. So interlace is working great with Linux it seems.

With orientation I mean that if I run switchres --mo 0|1|2 it works as intended but when I try to preset that from the gasetup menu then when launching the games from advmenu it always assumes the --mo 0 option it seems.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 05, 2011, 03:41:42 pm
I've figured up the virtualize (interlaced) issue, it was only needed to set 'filter' on in mame.ini, OpenGL-specific options. Now it looks exactly as in Windows when hwstretch is on. At the cost of loosing some sharpness you have a much more bearable flicker. So interlace is working great with Linux it seems.

With orientation I mean that if I run switchres --mo 0|1|2 it works as intended but when I try to preset that from the gasetup menu then when launching the games from advmenu it always assumes the --mo 0 option it seems.


Ah interesting, so when interlaced I should have switchres turn on filtering then.  It sounds like possibly either there's a bug in switchres for the mo option or the setup in setting that option.  I'll have to look at that closer.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 05, 2011, 03:49:22 pm
Ah interesting, so when interlaced I should have switchres turn on filtering then.  It sounds like possibly either there's a bug in switchres for the mo option or the setup in setting that option.  I'll have to look at that closer.

Well actually when stretching occurs is when we should enable 'filter', as interlacing is more bearable when the picture is not stretched, for instance if the native resolution of a game is 640x480 then you'd interlace but not stretch, flicker would be noticeable but free of artifacts. However I've been testing and it seems that filter only affects stretching so you might keep it activated by default (not sure).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 06, 2011, 11:42:25 am
Hi bitbytebit, I've noticed missing mame remove this warning, that of coinklock disable

Code: [Select]
"inptport.c" delete:

ui_popup_time(3, "Coinlock disabled %­s.", input_field_name(field));
return FALSE;

I do not remember what was the last live version of that probe is that it was a 1.4 ... but not if you're wearing on your website 1404 or not, since I see that you have the 64bit version on a 1,408 more, and if it still has flaws that I hope.

I wanted to know if you had ever thought of updating procedure for the distribution, without resintalar all, or else it would be better resinstalar, because if you have to update the kernel, xorg etc. .. resintalar is much faster to update as gentoo does, unless you already ready to leave the packages installed, I do not think this can be done in gentoo, no? there is always that compile to install, right?


Thank
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 06, 2011, 12:48:05 pm
Hi bitbytebit, I've noticed missing mame remove this warning, that of coinklock disable

Code: [Select]
"inptport.c" delete:

ui_popup_time(3, "Coinlock disabled %­s.", input_field_name(field));
return FALSE;

I do not remember what was the last live version of that probe is that it was a 1.4 ... but not if you're wearing on your website 1404 or not, since I see that you have the 64bit version on a 1,408 more, and if it still has flaws that I hope.

I wanted to know if you had ever thought of updating procedure for the distribution, without resintalar all, or else it would be better resinstalar, because if you have to update the kernel, xorg etc. .. resintalar is much faster to update as gentoo does, unless you already ready to leave the packages installed, I do not think this can be done in gentoo, no? there is always that compile to install, right?


Thank

I just updated the ISO images, there's 1.413 up now, and hopefully have fixed just about all the *known* flaws :).  Also it again is stripped down of extra packages, so about 100 meg smaller ISO images.

What is the coinlock disable thing, I've seen that but never know what it means.

With Gentoo updates will always be by source + compile, they explain that somewhere on the gentoo website how they will never have binary packages besides things like firefox or openoffice.  The only way to do updates I can see, is to fully use ebuild packages.  Right now you can update mame/mess builds that I have customized by my ebuild package, although so much else is changing it's probably better to just get a new ISO.  So currently it's more of a complete package, but would be nice to eventually do updates but after more subtle things are changing or just things like mame change and everything else works so wouldn't need to update everything and only mame. 

Usually in Gentoo an upgrade is just...

emerge --sync # (only do this one a day at most, it's a very large download of the /usr/portage files)
emerge -aDuv world
revdep-rebuild

I wouldn't recommend doing that now unless you want to spend a lot of time/bandwidth and possibly chasing some broken stuff :)  It usually is quite clean on a normal build but of course there's a few things different we've done so currently I'm tailoring the build carefully and some things could be overwritten with the generic gentoo update procedures.



So try the 1.413 ISO, it contains these fixes and more...


05022011 - Fixed monitor orientation setup in gasetup
         - filter when stretching for mame
    - fixes in mame0141u1 for mario/dkongjr/asteroids/galaxian sounds
    - gens works again in 64 bit build even when stripped down

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 06, 2011, 04:11:46 pm
I've gotten the ATI Radeon 5450 working perfectly now, interlaced 15khz 640x480 on the console, 15khz modes, page flipping/vblank.  This required a kernel patch, mame patch, and a change to xorg.conf too. 

So these cards can work just fine at 15khz, it's just the Windows drivers, and basically all the 5xxx cards are the same so that means they all should be able to work fine in my next ISO image. 

Mame needed to clear the frame before every draw with glClear(), I suspect that's just something mame should always be doing and I've submitted a patch for it.  The Linux kernel needed a patch that is new and not in the -rc tree yet for 2.6.38 to fix interlacing on the 5xxx cards, and xorg.conf seemed to need an option pointing VGA-0 to the right monitor section (this was odd, not sure why it's different than the other cards, but now all should work fine with that difference).

I don't think the 6xxx cards work with Linux yet, they are just now getting close though with those so they should in theory work in the future also.  I suspect they'll just work since probably the mame/xorg config parts are fixed and the interlace bug was a fluke it seems since the support is quite new for them.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 06, 2011, 06:18:54 pm
Those are great news, very important indeed, if Linux is able to deal with the newer ATIs then there's still hope for the 'crt scene' at least for some years.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 06, 2011, 06:34:56 pm
Those are great news, very important indeed, if Linux is able to deal with the newer ATIs then there's still hope for the 'crt scene' at least for some years.

Yeah I'm glad it works, because I bought this card for my desktop actually and yet it now is in my arcade cabinet because the n64 emulator likes it, mario cart is nice now :).  Swapped the 4350 with my desktop system, so figure the 5450 is my base card now I am using to test, it's quite wonderful with all the little issues worked out.  It's as cheap as a 4350 and modern, so sounds like a good base in the future and the ATI official cheap card now days.

Also I figured out what is necessary to support the Arcade VGA 3000 cards in Linux, it's actually really simple.  The method to take a video bios of the official Radeon HD2600 card and load it into the kernel mapping it to the kernels vbios structure.  It's really just loading the file and mapping it out to memory, easy actually, then we should be able to treat it like an HD2600 and the user doesn't even need to flash the bios of the card.  Of course it's also going to allow people to change the vbios of their radeon cards dynamically like some like to do, hack any radeon card to any vbios too.  Not supported or suggested/recommended but possible. I'll have to try to code it up and see how it works, probably the only way we'll support an Arcade VGA 3000 in Linux though.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 07, 2011, 06:00:32 am
Hi bit, this distribution is working properly with avga9250.

In the installation does not create or copy the file bash_profile.

I think that when you choose the partition /data format should not ask for, since more than a certain format is wrong and all your roms.

By not format the partition /data folder does not copy the cat, and the symlinks in /home/arcade/emulator/mame are orphaned, but here there are many like flyers cabinets etc. .. I have never been created in /data

With respect to alsa, I could not make me recognize the sound card is installed, I need to prove from the livecd, and make an installation by selecting alsa.

One more thing, switchres have or could have any parameter for vertical games fill the screen?
Because there are games that if you stop to stretch and fill the screen and not others?

The files are in /home/arcade/ini are for something special or because you forgot to delete them?

Thank
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 07, 2011, 06:20:49 am
One more thing, switchres have or could have any parameter for vertical games fill the screen?
Because there are games that if you stop to stretch and fill the screen and not others?

Hi VeS, regarding the vertical games thing, yesterday I was doing some tests with that in my VMMaker app, and figured out a general method for adding a "vertical aspect" param that works the same both for stretched and non-stretched cases. I'll write out the details later so the --vcalc param in Switchres may be extended for this feature if bitbytebit thinks it's a good idea.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 07, 2011, 10:04:12 am
Hi bit, this distribution is working properly with avga9250.

In the installation does not create or copy the file bash_profile.

I think that when you choose the partition /data format should not ask for, since more than a certain format is wrong and all your roms.

By not format the partition /data folder does not copy the cat, and the symlinks in /home/arcade/emulator/mame are orphaned, but here there are many like flyers cabinets etc. .. I have never been created in /data

With respect to alsa, I could not make me recognize the sound card is installed, I need to prove from the livecd, and make an installation by selecting alsa.

One more thing, switchres have or could have any parameter for vertical games fill the screen?
Because there are games that if you stop to stretch and fill the screen and not others?

The files are in /home/arcade/ini are for something special or because you forgot to delete them?

Thank

It should create /home/arcade/.bash_profile actually, are you sure it's not, it should be there.

I still need to figure out how to handle /data/ I guess, although it's tricky because there are many different options possible.  Right now I ask if it should be formatted for the case where someone just created a new partition to store roms on.  If the partition already exists then they can say no there and it should mount it no matter what type it is.  If they don't choose /data/ at all, then the directory will just be the one from the liveCD and they can populate it with the samba share after that.  I'm sure it could be simplified, I haven't looked at it more yet, but seems to work for my case where I mount a directory under /data/  with the roms/snaps and it seems to deal with  that, and when I don't it works fine too with the default roms and just a directory under / as /data/.   

Alsa might not work for your card I'm guessing, OSS4 is the better choice in most cases, it actually is preferred by a lot of people so makes some sense we are seeing it working better and why I made it the default.

That sounds interesting about vertical games, interested in seeing what Calamity has come up with, not totally understanding what the issue is but will be good to make them better and suspect it's another tricky vertical game aspect issue.

The /home/arcade/ini/ files are good ones that are necessary, because those few games in there like zookeeper have the wrong refresh rate in mame and the vector.ini does that thing where the vector  games look better.  The dbz is because they have the size wrong in mame, so helps it fit onto the screen properly, and the a2600 and genesis are actually for the emulators for them else they don't like the resolution mess chooses for them and wont run.  So they are purposefully there to help things run.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 07, 2011, 10:21:19 am
Quote
It should create /home/arcade/.bash_profile actually, are you sure it's not, it should be there.

If I am sure, when you first boot the console dry without running startx, and if I look there I have to create the file.

Quote
Alsa might not work for your card I'm guessing, OSS4 is the better choice in most cases, it actually is preferred by a lot of people so makes some sense we are seeing it working better and why I made it the default.

Alsa I have always worked well, but not because it does not work here, it may be of any conflict, or lack of modules, or the kernel you are using to be RC




Thank
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 07, 2011, 10:27:11 am
Quote
It should create /home/arcade/.bash_profile actually, are you sure it's not, it should be there.

If I am sure, when you first boot the console dry without running startx, and if I look there I have to create the file.

Quote
Alsa might not work for your card I'm guessing, OSS4 is the better choice in most cases, it actually is preferred by a lot of people so makes some sense we are seeing it working better and why I made it the default.

Alsa I have always worked well, but not because it does not work here, it may be of any conflict, or lack of modules, or the kernel you are using to be RC




Thank

Oh I see what is going on, yeah it's not writing it to the right place if you aren't using a /home/ partition separately, I'll fix that :).

I wonder about Alsa, it in theory should be the same build as Ubuntu but definitely strange, might be the rc kernel but I suspect it's possibly some other way it should be setup better.  It's odd because the aplay -l output said it saw the soundcard, and are alsa mixer levels all up and unmuted?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 07, 2011, 10:49:26 am

I think that when you choose the partition /data format should not ask for, since more than a certain format is wrong and all your roms.

By not format the partition /data folder does not copy the cat, and the symlinks in /home/arcade/emulator/mame are orphaned, but here there are many like flyers cabinets etc. .. I have never been created in /data

Thank

Actually that emulator directory is the part of wahcade I didn't like, since it is a  pain to create that and might as well consider it 'depreciated' and I even might remove any wahcade pre-config all together.  Since we have advmenu  now, it takes care of all that, but will have wahcade if the user wants to go through the trouble of setting it up.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 07, 2011, 12:27:04 pm
That sounds interesting about vertical games, interested in seeing what Calamity has come up with, not totally understanding what the issue is but will be good to make them better and suspect it's another tricky vertical game aspect issue.

I'm using the 'screen_aspect' option to tweak some things and it works well in Windows, but I still need to test today if that option works also for the Linux part.
BTW testing this I noticed the 'changeres' option and maybe the 'cleanstretch' one are preventing 'hwstretch' to work in Windows, maybe related to what you observed in Linux, so I had to disable them. I definitely need to look deeper at this changeres thing as it's going to be a must have to properly deal with games like the sega ones (dbz) that are trying to dynamically change resolutions during the game.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 07, 2011, 12:33:22 pm
That sounds interesting about vertical games, interested in seeing what Calamity has come up with, not totally understanding what the issue is but will be good to make them better and suspect it's another tricky vertical game aspect issue.

I'm using the 'screen_aspect' option to tweak some things and it works well in Windows, but I still need to test today if that option works also for the Linux part.
BTW testing this I noticed the 'changeres' option and maybe the 'cleanstretch' one are preventing 'hwstretch' to work in Windows, maybe related to what you observed in Linux, so I had to disable them. I definitely need to look deeper at this changeres thing as it's going to be a must have to properly deal with games like the sega ones (dbz) that are trying to dynamically change resolutions during the game.

Yeah I disable both changeres and cleanstretch now in switchres.  Changeres will not scale, it forces the pixel aspect ratio to be 1:1.  The Cleanstretch one seems alright a lot of the time, but for a few games it'll just make them way off, like Gorf. 

Changeres is tricky of course because how are we going to know ahead of time which modeline is needed, and mame would have to signal switchres to tell it what is necessary.  I guess that is one reason to try and modify mame to have the logic of modeline calculation within it.  Although the problem then gets really complicated with all the different possible ways to insert modelines so we'd be chasing that in mame instead of a separate switchres program.  Definitely interesting, hopefully we can come up with some innovative amazing way to figure it out :).  I have wanted to look into putting switchres into mame but everytime it starts seeming like a big pain and probably just wasted time, eventually I might get brave enough to try it if I can think of a clean way that really would avoid creating a hard to maintain mame like advancemame was.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 07, 2011, 01:03:46 pm
Yeah I disable both changeres and cleanstretch now in switchres.  Changeres will not scale, it forces the pixel aspect ratio to be 1:1.  The Cleanstretch one seems alright a lot of the time, but for a few games it'll just make them way off, like Gorf.  

Yes Switchres is doing it already, actually I was getting crazy yesterday seeing this problem when launching mame alone so I figured out from Switchres command line that it was 'changeres' the problematic option.

Changeres is tricky of course because how are we going to know ahead of time which modeline is needed, and mame would have to signal switchres to tell it what is necessary.  I guess that is one reason to try and modify mame to have the logic of modeline calculation within it.  Although the problem then gets really complicated with all the different possible ways to insert modelines so we'd be chasing that in mame instead of a separate switchres program.  Definitely interesting, hopefully we can come up with some innovative amazing way to figure it out :).  I have wanted to look into putting switchres into mame but everytime it starts seeming like a big pain and probably just wasted time, eventually I might get brave enough to try it if I can think of a clean way that really would avoid creating a hard to maintain mame like advancemame was.

Yes, putting Switchres into Mame is too tempting :). By now, it could be done by making Switchres enable 2 or more modelines instead of one before launching Mame. Of course we'd need an ugly external file to patch xml values for the Mame drivers involved, unless it was possible to educate Mame itself by patching it to return the right values and various display resolutions without breaking it. Also some emulators expect to have more than one video mode available, and the information in Mess is certainly not enough. Either way seems there's a lot of work involved.

EDIT: Well, there would be an interesting way to do it I'm thinking, at least from the Windows point of view, that would even avoid the need of dealing with xml at all. We could patch Mame so that when it is about to request a given video mode, it'll send a message to the Switchres process with the needed data as a parameter, in the same way that Powerstrip api can be  controlled remotely. So from Mame side it would be enough with a little patch that can be easily ported between versions. However that would require a big amount of os specific bloat in your code. This could even work for MameUI builds. It's not something definitely needed by now, but just wanted to write it down in case I forget  :D

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 07, 2011, 05:36:18 pm
Fortunately the screen_aspect option works exactly the same for both Linux and Windows. The idea with this is to do the same vertical aspect calculations for the stretched and not stretched case. So one can use the --vcalc 0 option to have all vertical games looking 3:4, --valc 1 to make them 3:3, etc. until 4:3, that means the game covers the full screen wide (with the wrong proportions of course).

First, the stretched case. All we need to do is use hwstretch/unevenstretch as we do, + nokeepaspect, then use 'screen_aspect <num:den>', using the inverse of the actual ratio we want, so:

normal aspect (3:4) -> use 4:3
square aspect (3:3) -> use 3:3
stretch to full screen (4:3) -> use 3:4

So for --vcalc 0 (default) we would use screen_aspect 4:3
EDIT: For the resolution we still use the same virtualized one, we just add the screen_aspect option

Now, for the non-stretched case we would use this formula:

  SWAP xres, yres
  xres = Normalize ( xres * ( 4 / 3 ) / VerticalAspect, 8 )

where VerticalAspect = (the actual aspect we want, num/den)

... so for the default case it would be 3/4 -> (4/3)/(3/4) =(16/9)
... for the square case it would be 3/3 -> (4/3)/(3/3)=(4/3)
... and for the full screen case 4/3 -> (4/3)/(4/3)=1

Of course some intermediate values are possible, so we can fit one similar to your method that was somewhere between default and square.

----

I've been testing the new ISO, the 64 bits one now, it works perfect, even seems faster. Just noticed that now P2 button from AdvMenu turns the power off instead of exiting, is it intended to be like that or a bug instead?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 07, 2011, 05:58:39 pm
Fortunately the screen_aspect option works exactly the same for both Linux and Windows. The idea with this is to do the same vertical aspect calculations for the stretched and not stretched case. So one can use the --vcalc 0 option to have all vertical games looking 3:4, --valc 1 to make them 3:3, etc. until 4:3, that means the game covers the full screen wide (with the wrong proportions of course).

First, the stretched case. All we need to do is use hwstretch/unevenstretch as we do, + nokeepaspect, then use 'screen_aspect <num:den>', using the inverse of the actual ratio we want, so:

normal aspect (3:4) -> use 4:3
square aspect (3:3) -> use 3:3
stretch to full screen (4:3) -> use 3:4

So for --vcalc 0 (default) we would use screen_aspect 4:3

Now, for the non-stretched case we would use this formula:

  SWAP xres, yres
  xres = Normalize ( xres * ( 4 / 3 ) / VerticalAspect, 8 )

where VerticalAspect = (the actual aspect we want, num/den)

... so for the default case it would be 3/4 -> (4/3)/(3/4) =(16/9)
... for the square case it would be 3/3 -> (4/3)/(3/3)=(4/3)
... and for the full screen case 4/3 -> (4/3)/(4/3)=1

Of course some intermediate values are possible, so we can fit one similar to your method that was somewhere between default and square.

----

I've been testing the new ISO, the 64 bits one now, it works perfect, even seems faster. Just noticed that now P2 button from AdvMenu turns the power off instead of exiting, is it intended to be like that or a bug instead?


It's from the config Ves has, but I sort of want to change it to possibly exit/esc instead.

I've been getting wahcade so it'll somewhat be easy to setup/use and defaults fit switchres setup, so when wanted that option as an alternative will be decent.  I also removed all the pre-config setup of it and the links Ves saw that are dead basically, updated to the newer version from the dev repository too since it looks like there has been a few improvements. 

Also the xorg.conf setup has been done a bit differently now and more simple from a single shell script instead of Perl, I discovered some connection between the Monitor and Device outputs being wrong which showed up when switching to VGA and DVI interfaces for output.

I might have found your font/OSD issue, try removing the /home/arcade/fonts/ directory, I no longer have the font specified in that directory anymore and I suspect that might have been using a bad font for you (or there might be better ones in that folder too, not sure, try them and see which works best).

I will absorb that aspect ration information, sounds cool, I always was confused by the aspect option in mame and haven't ever had luck with it so sounds like the way your explaining it will help a lot.  Any good examples of games this affects, and how I can test it with them?  So basically we need to use the -screen_aspect argument, and how do we know if it's the default/square/full screen case?  Or is this basically altering the vcalc decision of the user for their desired way to display, to have them choose which one of those to display (or are certain games needing certain values there?).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Gray_Area on February 07, 2011, 07:37:18 pm
I will absorb that aspect ration information, sounds cool, I always was confused by the aspect option in mame and haven't ever had luck with it so sounds like the way your explaining it will help a lot.  Any good examples of games this affects, and how I can test it with them?  So basically we need to use the -screen_aspect argument, and how do we know if it's the default/square/full screen case?  Or is this basically altering the vcalc decision of the user for their desired way to display, to have them choose which one of those to display (or are certain games needing certain values there?).

This is pretty basic, but may be helpful if not already familiar: with games in MAME, 4:3 is the desired setting for horizontal games run horizontally; vertical games run vertically (monitor is turned); and either combination of those run at the same time: H+V on H display; V+H on V display.

I have only used it (with hardware stretch) was when I felt a vertical game displayed on horizontally oriented monitor was wider than I thought it was back in the day. A common setting would be 7:5 .  I have long discontinued this practice, though.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 08, 2011, 03:25:52 am
Here's the code and my commented out parts I was testing with the screen_aspect option...

Code: [Select]
        if (gameInfo.stretch) {
                if (cs->cleanstretch)
                        mamearg[mameargc++] = "-nocleanstretch";

                if (IS_WIN)
                        mamearg[mameargc++] = "-hwstretch";
                else
                        mamearg[mameargc++] = "-unevenstretch";
                mamearg[mameargc++] = "-filter";

                if (cs->changeres && !gameInfo.changeres)
                        mamearg[mameargc++] = "-nochangeres";

                //mamearg[mameargc++] = "-screen_aspect";
                //mamearg[mameargc++] = "4:3";
        } else {
                if (cs->cleanstretch)
                        mamearg[mameargc++] = "-nocleanstretch";

                //mamearg[mameargc++] = "-screen_aspect";
                //mamearg[mameargc++] = "16:9";
        }

        if (gameInfo.keepaspect)
                mamearg[mameargc++] = "-keepaspect";

For some reason, and like before when I played with it, it never seems to really make things correct or help them.  I'm not sure what needs to be done above, but would be interested in seeing it.   From what I can tell, some games adhere to aspect ration with or without keepaspect, others don't and usually look nasty too (like tron).  What would be the case for Tron on a CGA monitor, how could I make it look good with the screen_aspect setting and avoiding keep aspect, or is is possible?

Definitely looks interesting, something I've wondered about, on the d9800 I never really have to worry about this but for a 15khz monitor it definitely is a big issue from what I can see.  So would be good to get this right, because I suspect a game like Tron should be able to show up properly virtualized and not look terrible like it does right now.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 08, 2011, 03:49:55 am
Yesterday I didn't have much time so I just sketched that, sorry if it wasn't clear. The games I usually choose for testing are 1942 for the normal non-stretched case, and twincobr for the stretched virtualized case. Of course you'll need to use my monitor setup in order to see the same results.

So, now when you select from the --vcalc options, you only get a difference in the 1942 case, but twincobr will still look 3:4 whatever you select. What I'm trying to do is to extend the way --vcalc works for the stretched case also. That involves using the screen_aspect option when in the stretched case, to explicitely tell Mame the aspect we want. When in the non-stretched case, that's not necessary as the resulting aspect is already implicit in the pixel aspect of the resolution we select.

Now, I assume that all games that were designed for a 4:3 crt screen have a native aspect ratio of 4:3 (or 3:4 if vertical), as they were expected to fill the screen, regardless their pixel aspect (xres/yres). So what I mean by "default/square/full screen" is the way the user prefers these games to look when shown in a horizontal monitor, being the default ideal case 3:4, which respects the proportions, while the square 3:3 means that the resulting picture will be square, same width than height, altering the proportions but covering a bigger area on the screen, which some people get used to and like, and then the extreme case of 4:3 full screen mode, where the whole thing is stretched to fill the screen, ruinning the proportions while maximizing the use of our phosphorus area.

The only way I've figured out to get this in the stretched case is by indirectly using the screen_aspect option. The aim of this option is to tell Mame the actual aspect ratio of our screen. So, if we want to have the extreme 4:3 full screen aspect, we cheat Mame to think our screen is actually 3:4, so it will stretch the picture right to the side borders thinking it's doing it right.

Edit: In your code above, you should not use 16:9. You should use screen_aspect 4:3 | 3:3 | 3:4 depending of the --vcalc option. For the non stretched case, you would use 3:4 | 3:3 | 4:3 as VerticalAspect value in the above formula (notice that these quotients are the inverse of the others for the same cases).

* 1942 (256x224)

--vcalc 0; VerticalAspect = 3/4
  yres = 256
  xres = Normalize ( 224 * ( 4 / 3 ) / VerticalAspect, 8 ) = 400
  resolution0 400x256

--vcalc 1; VerticalAspect = 3/3
  yres = 256
  xres = Normalize ( 224 * ( 4 / 3 ) / VerticalAspect, 8 ) = 304
  resolution0 304x256

--vcalc 2; VerticalAspect = 4/3
  yres = 256
  xres = Normalize ( 224 * ( 4 / 3 ) / VerticalAspect, 8 ) = 224
  resolution0 224x256

* twincobr (320x240)

--vcalc 0; VerticalAspect = 3/4;  1 / Vertical Aspect => 4:3
  resolution0 752x560 (virtualized)
  screen_aspect 4:3
  hwstretch
 
--vcalc 1; VerticalAspect = 3/3;  1 / Vertical Aspect => 3:3
  resolution0 752x560 (virtualized)
  screen_aspect 3:3
  hwstretch

--vcalc 2; VerticalAspect = 4/3;  1 / Vertical Aspect => 3:4
  resolution0 752x560 (virtualized)
  screen_aspect 3:4
  hwstretch
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 08, 2011, 12:00:09 pm
This change seems to do the multiple types of vertical game aspect ratio setups.  Now have vcalc able to do the 0, 1, 2 for the 3 cases mentioned of normal square and stretched, also there's options 3 and 4 for the old normal and older normal which makes it slightly wider (probably pretty much are 0 and 1, but slightly different perhaps).  Then if the value is a double, like 1.777 it uses that to multiply the width for the vertical games.  So basically sticking to 0 is good for most, maybe 1 if a person likes a wider game, and 3 if they want the screen full.  This works for both vertical games on horizontal monitors and horizontal games on vertical monitors.  So you can play Mario on a vertical monitor stretched to fit up/down or with it correctly aspect ratio'd.

Also this patch fixes rotation of the screen so it's always the same direction, it seemed that some vertical games wanted to go one direction, and others the other way, and horizontal games on a vertical screen now also go the same way as the vertical games.   Seemed like a good thing :).

Code: [Select]
diff --git a/src/SwitchResC/switchres.c b/src/SwitchResC/switchres.c
index b3293b7..8377c47 100644
--- a/src/SwitchResC/switchres.c
+++ b/src/SwitchResC/switchres.c
@@ -681,9 +681,10 @@ int main(int argc, char **argv) {
 
                // Vertical oriented monitor
                if (cs->morientation == 1) {
-                       if (gameInfo.orientation == 1)
-                               mamearg[mameargc++] = "-norotate";
-                       else {
+                       if (gameInfo.orientation == 1) {
+                               mamearg[mameargc++] = "-rotate";
+                               mamearg[mameargc++] = "-autorol";
+                       } else {
                                mamearg[mameargc++] = "-rotate";
                                mamearg[mameargc++] = "-rol";
                        }
@@ -691,13 +692,44 @@ int main(int argc, char **argv) {
 
                // Vertical and Horizontal rotating monitor
                if (cs->morientation == 2) {
-                       if (gameInfo.orientation == 1)
-                               mamearg[mameargc++] = "-norotate";
-                       else
+                       if (gameInfo.orientation == 1) {
+                               mamearg[mameargc++] = "-rotate";
+                               mamearg[mameargc++] = "-autorol";
+                       } else {
                                mamearg[mameargc++] = "-rotate";
+                       }
+               }
+       }
+
+       if ((gameInfo.orientation && !cs->morientation) || (!gameInfo.orientation && (cs->morientation == 1))) {
+               if (monitorMode->ModeLine->result & RESULT_VIRTUALIZE) {
+                       if (cs->vcalc == 0) {
+                               mamearg[mameargc++] = "-screen_aspect";
+                               mamearg[mameargc++] = "4:3";
+                       } else if (cs->vcalc == 1) {
+                               mamearg[mameargc++] = "-screen_aspect";
+                               mamearg[mameargc++] = "3:3";
+                       } else if (cs->vcalc == 2) {
+                               mamearg[mameargc++] = "-screen_aspect";
+                               mamearg[mameargc++] = "3:4";
+                       }
+               } else {
+                       if (cs->vcalc == 0) {
+                               mamearg[mameargc++] = "-screen_aspect";
+                               mamearg[mameargc++] = "3:4";
+                       } else if (cs->vcalc == 1) {
+                               mamearg[mameargc++] = "-screen_aspect";
+                               mamearg[mameargc++] = "3:3";
+                       } else if (cs->vcalc == 2) {
+                               mamearg[mameargc++] = "-screen_aspect";
+                               mamearg[mameargc++] = "4:3";
+                       }
                }
        }
 
+       if (gameInfo.keepaspect)
+               mamearg[mameargc++] = "-keepaspect";
+
        if (gameInfo.stretch) {
                if (cs->cleanstretch)
                        mamearg[mameargc++] = "-nocleanstretch";
@@ -710,20 +742,11 @@ int main(int argc, char **argv) {
 
                if (cs->changeres && !gameInfo.changeres)
                        mamearg[mameargc++] = "-nochangeres";
-
-               //mamearg[mameargc++] = "-screen_aspect";
-               //mamearg[mameargc++] = "4:3";
        } else {
                if (cs->cleanstretch)
                        mamearg[mameargc++] = "-nocleanstretch";
-
-               //mamearg[mameargc++] = "-screen_aspect";
-               //mamearg[mameargc++] = "16:9";
        }
 
-       if (gameInfo.keepaspect)
-               mamearg[mameargc++] = "-keepaspect";
-
        if (gameInfo.redraw) {
                mamearg[mameargc++] = "-redraw";
                mamearg[mameargc++] = "auto";
@@ -861,7 +884,7 @@ int usage(void) {
        fprintf(stderr, "  --novsync               Weight for x/y instead of vertical refresh\n");
        fprintf(stderr, "  --noswitchres           Don't switch resolutions, just use as wrapper to mame, best for LCD's\n");
        fprintf(stderr, "  --notriplebuffer        Use Mame option waitvsync instead of triple buffer (Windows)\n");
-       fprintf(stderr, "  --vcalc [0|1]           Method of calculating width on vertical games (0=16/9, 1=3/4)\n");
+       fprintf(stderr, "  --vcalc [0|1|2|3|4]     Method of calculating width on vertical games (0=4:3 1=1:1 2=3:4 3=4:3 4=4:3)\n");
        fprintf(stderr, "  --mo [0|1|2]            Monitor Orientation, 0=horizontal, 1=vertical, 2=both/rotateable\n");
        fprintf(stderr, "  --dcalign <HZ>          Align dotclock to Hz (Windows 10000 Linux 1000)\n");
        fprintf(stderr, "  --ff                    Frogger/Galaxian Hack is in mame executable\n");
diff --git a/src/SwitchResC/xml.c b/src/SwitchResC/xml.c
index 7f7fb72..2886bab 100644
--- a/src/SwitchResC/xml.c
+++ b/src/SwitchResC/xml.c
@@ -223,12 +223,6 @@ int ParseXML(xmlDocPtr xmlbuffer, GameInfo *game, ConfigSettings *cs) {
                                                        if (cs->morientation == 0) {
                                                                game->width = h;
                                                                game->height = w;
-                                                               if (cs->vcalc == 0) // New calculation using 16:9
-                                                                       game->width = (4.0/3.0) * ((double)game->width * (4.0/3.0));
-                                                               else if (cs->vcalc == 1) // Older calculation 4:3 makes things wider
-                                                                       game->width = (4.0/3.0) * game->height;
-                                                               else // Custom calculation
-                                                                       game->width = cs->vcalc * ((double)game->width * (cs->vcalc));
                                                        }
                                                        } else { // horizontal
                                                        game->orientation = 0;
@@ -237,13 +231,21 @@ int ParseXML(xmlDocPtr xmlbuffer, GameInfo *game, ConfigSettings *cs) {
                                                                        int h = game->height;
                                                                game->width = h;
                                                                game->height = w;
-                                                               if (cs->vcalc == 0) // New calculation using 16:9
-                                                                       game->width = (4.0/3.0) * ((double)game->width * (4.0/3.0));
-                                                               else if (cs->vcalc == 1) // Older calculation 4:3 makes things wider
-                                                                       game->width = (4.0/3.0) * game->height;
-                                                               else // Custom calculation
-                                                                       game->width = cs->vcalc * ((double)game->width * (cs->vcalc));
-                                                               //game->keepaspect = 1;
+                                                       }
+                                               }
+                                               if ((game->orientation && !cs->morientation) || (!game->orientation &&  (cs->morientation == 1))) {
+                                                       if (cs->vcalc == 0.0) { // 3:4 Normal
+                                                               game->width = Normalize((double)game->width * (4.0/3.0) / (3.0/4.0), 8);
+                                                       } else if (cs->vcalc == 1.0) { // 3:3 Square
+                                                               game->width = Normalize((double)game->width * (4.0/3.0) / (3.0/3.0), 8);
+                                                       } else if (cs->vcalc == 2.0) { // 4:3 Stretch
+                                                               game->width = Normalize((double)game->width * (4.0/3.0) / (4.0/3.0), 8);
+                                                       } else if (cs->vcalc == 3.0) { // Old 3/4
+                                                               game->width = (4.0/3.0) * ((double)game->width * (4.0/3.0));
+                                                       } else if (cs->vcalc == 4.0) { // Older 3/4
+                                                               game->width = (4.0/3.0) * game->height;
+                                                       } else { // Custom
+                                                               game->width = cs->vcalc * ((double)game->width * (cs->vcalc));
                                                        }
                                                }
                                        } else {



When my connection speeds up, I will get new ISO images uploaded, with a lot of changes, my upload speed has been crap the last day, but guess it's fine since these changes that way can get into the ISO too.

I've uploaded new versions of switchres to test with this change, version 1.436-b901bb2.  Let me know if this works the way it's expected to, then can get new ISO's with all the changes recently made and this one.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 08, 2011, 12:56:21 pm
Oh thanks for doing that, that was the only missing feature I can imagine, I'll test it tonight.

Actually -screen_aspect should only be applied when virtualizing, so this could be removed, unless I'm wrong:

Code: [Select]
+               } else {
+                       if (cs->vcalc == 0) {
+                               mamearg[mameargc++] = "-screen_aspect";
+                               mamearg[mameargc++] = "3:4";
+                       } else if (cs->vcalc == 1) {
+                               mamearg[mameargc++] = "-screen_aspect";
+                               mamearg[mameargc++] = "3:3";
+                       } else if (cs->vcalc == 2) {
+                               mamearg[mameargc++] = "-screen_aspect";
+                               mamearg[mameargc++] = "4:3";
+                       }
                }

... as in the non-stretched mode the proper aspect is already achieved by the way we calculate the resolution (it was working ok already).

You can use a general formula instead of doing particular cases, by using vcalc at the beginning to define the quotient to apply. I like your idea of being able to pass a double, but you should treat it in the same way as the other quotients to keep coherence, so if one wants to pass an intermediate value between option 0 (3/4) and option 1 (3/3), say 5/6, you can pass it as the VerticalAspectRatio value:

Code: [Select]
game->width = Normalize((double)game->width * (4.0/3.0) / VerticalAspectRatio, 8);
The problem with passing a double is that you can't easily specify it as text <num:den> for the stretched case unless you write a function to do so.

In a way, your 3 and 4 options could be particular cases between the basic default/square/full options.

BTW, the (4.0/3.0) of the formula above accounts for the actual screen aspect of our monitor, so eventually that could also be modified to 16:9, 16:10, or other available aspect ratios (although the target of this is not to support flat screens it can be an option), and at least in theory the calculations should provide the proper proportions.

I think it's clearer to specify the ratios as the actual ones the game will show:
 --vcalc [0|1|2|3|4]     Method of calculating width on vertical games (0=3:4 1=3:3 2=4:3 ...)

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 08, 2011, 01:52:09 pm
Oh thanks for doing that, that was the only missing feature I can imagine, I'll test it tonight.

Actually -screen_aspect should only be applied when virtualizing, so this could be removed, unless I'm wrong:

Code: [Select]
+               } else {
+                       if (cs->vcalc == 0) {
+                               mamearg[mameargc++] = "-screen_aspect";
+                               mamearg[mameargc++] = "3:4";
+                       } else if (cs->vcalc == 1) {
+                               mamearg[mameargc++] = "-screen_aspect";
+                               mamearg[mameargc++] = "3:3";
+                       } else if (cs->vcalc == 2) {
+                               mamearg[mameargc++] = "-screen_aspect";
+                               mamearg[mameargc++] = "4:3";
+                       }
                }

... as in the non-stretched mode the proper aspect is already achieved by the way we calculate the resolution (it was working ok already).

You can use a general formula instead of doing particular cases, by using vcalc at the beginning to define the quotient to apply. I like your idea of being able to pass a double, but you should treat it in the same way as the other quotients to keep coherence, so if one wants to pass an intermediate value between option 0 (3/4) and option 1 (3/3), say 5/6, you can pass it as the VerticalAspectRatio value:

Code: [Select]
game->width = Normalize((double)game->width * (4.0/3.0) / VerticalAspectRatio, 8);
The problem with passing a double is that you can't easily specify it as text <num:den> for the stretched case unless you write a function to do so.

In a way, your 3 and 4 options could be particular cases between the basic default/square/full options.

BTW, the (4.0/3.0) of the formula above accounts for the actual screen aspect of our monitor, so eventually that could also be modified to 16:9, 16:10, or other available aspect ratios (although the target of this is not to support flat screens it can be an option), and at least in theory the calculations should provide the proper proportions.

I think it's clearer to specify the ratios as the actual ones the game will show:
 --vcalc [0|1|2|3|4]     Method of calculating width on vertical games (0=3:4 1=3:3 2=4:3 ...)



Ah cool, well that makes it easy :) and I think this makes the most sense:

  --aspect num:den        Method of calculating width on vertical games, default 4:3

Just throw away the --vcalc option and make it an easy aspect ratio value, so this patch instead.  I'll have to get new versions with this uploaded soon.  The old methods really aren't necessary from what I can tell because they are either wrong in calculations sometimes or the same as the new possible ones.  Also I think your right, don't need the extra aspect ratio for non-virtualized since the resolution itself should indicate that I am thinking.

Code: [Select]
diff --git a/src/SwitchResC/config.c b/src/SwitchResC/config.c
index 17df9ed..1c6fddb 100644
--- a/src/SwitchResC/config.c
+++ b/src/SwitchResC/config.c
@@ -96,8 +96,8 @@ int readConfig(ConfigSettings *cs, char *filename) {
                        sprintf(cs->emulator, "%s", tmp2);
                } else if (!strcmp(tmp, "vsync")) {
                        cs->vsync = atoi(tmp2);
-               } else if (!strcmp(tmp, "vcalc")) {
-                       cs->vcalc = atof(tmp2);
+               } else if (!strcmp(tmp, "aspect")) {
+                       sprintf(cs->aspect, "%s", tmp2);
                } else if (!strcmp(tmp, "mo")) {
                        cs->morientation = atoi(tmp2);
                } else if (!strcmp(tmp, "dcalign")) {
diff --git a/src/SwitchResC/switchres.c b/src/SwitchResC/switchres.c
index b3293b7..d76900a 100644
--- a/src/SwitchResC/switchres.c
+++ b/src/SwitchResC/switchres.c
@@ -84,6 +84,7 @@ int main(int argc, char **argv) {
        cs->vectorwidth  = 640;
        cs->vectorheight = 480;
        sprintf(cs->emulator, "%s", "mame");
+       sprintf(cs->aspect, "%s", "4:3");
        cs->is_mame = 1;
        cs->is_mess = 0;
        cs->version = 105;
@@ -222,14 +223,14 @@ int main(int argc, char **argv) {
                                                                "Error with -mo\n");
                                                        goto Game_Over;
                                                }
-                                       } else if (!strcmp(s, "vcalc")) {
+                                       } else if (!strcmp(s, "aspect")) {
                                                if ((i+1) < argc && *(s = argv[i+1]) != '-') {
-                                                       cs->vcalc = atof(s);
+                                                       sprintf(cs->aspect, "%s", s);
                                                        i++;
                                                } else {
                                                        usage();
                                                        sr_fprintf(stderr,
-                                                               "Error with -vcalc\n");
+                                                               "Error with -aspect\n");
                                                        goto Game_Over;
                                                }
                                        } else if (!strcmp(s, "dcalign")) {
@@ -681,9 +682,10 @@ int main(int argc, char **argv) {
 
                // Vertical oriented monitor
                if (cs->morientation == 1) {
-                       if (gameInfo.orientation == 1)
-                               mamearg[mameargc++] = "-norotate";
-                       else {
+                       if (gameInfo.orientation == 1) {
+                               mamearg[mameargc++] = "-rotate";
+                               mamearg[mameargc++] = "-autorol";
+                       } else {
                                mamearg[mameargc++] = "-rotate";
                                mamearg[mameargc++] = "-rol";
                        }
@@ -691,13 +693,26 @@ int main(int argc, char **argv) {
 
                // Vertical and Horizontal rotating monitor
                if (cs->morientation == 2) {
-                       if (gameInfo.orientation == 1)
-                               mamearg[mameargc++] = "-norotate";
-                       else
+                       if (gameInfo.orientation == 1) {
                                mamearg[mameargc++] = "-rotate";
+                               mamearg[mameargc++] = "-autorol";
+                       } else {
+                               mamearg[mameargc++] = "-rotate";
+                       }
                }
        }
 
+       if ((gameInfo.orientation && !cs->morientation) || (!gameInfo.orientation && (cs->morientation == 1))) {
+               if (monitorMode->ModeLine->result & RESULT_VIRTUALIZE)
+                       mamearg[mameargc++] = cs->aspect;
+               /*else
+                       mamearg[mameargc++] = cs->aspect;
+               */
+       }
+
+       if (gameInfo.keepaspect)
+               mamearg[mameargc++] = "-keepaspect";
+
        if (gameInfo.stretch) {
                if (cs->cleanstretch)
                        mamearg[mameargc++] = "-nocleanstretch";
@@ -710,20 +725,11 @@ int main(int argc, char **argv) {
 
                if (cs->changeres && !gameInfo.changeres)
                        mamearg[mameargc++] = "-nochangeres";
-
-               //mamearg[mameargc++] = "-screen_aspect";
-               //mamearg[mameargc++] = "4:3";
        } else {
                if (cs->cleanstretch)
                        mamearg[mameargc++] = "-nocleanstretch";
-
-               //mamearg[mameargc++] = "-screen_aspect";
-               //mamearg[mameargc++] = "16:9";
        }
 
-       if (gameInfo.keepaspect)
-               mamearg[mameargc++] = "-keepaspect";
-
        if (gameInfo.redraw) {
                mamearg[mameargc++] = "-redraw";
                mamearg[mameargc++] = "auto";
@@ -861,7 +867,7 @@ int usage(void) {
        fprintf(stderr, "  --novsync               Weight for x/y instead of vertical refresh\n");
        fprintf(stderr, "  --noswitchres           Don't switch resolutions, just use as wrapper to mame, best for LCD's\n");
        fprintf(stderr, "  --notriplebuffer        Use Mame option waitvsync instead of triple buffer (Windows)\n");
-       fprintf(stderr, "  --vcalc [0|1]           Method of calculating width on vertical games (0=16/9, 1=3/4)\n");
+       fprintf(stderr, "  --aspect num:den        Method of calculating width on vertical games, default 4:3\n");
        fprintf(stderr, "  --mo [0|1|2]            Monitor Orientation, 0=horizontal, 1=vertical, 2=both/rotateable\n");
        fprintf(stderr, "  --dcalign <HZ>          Align dotclock to Hz (Windows 10000 Linux 1000)\n");
        fprintf(stderr, "  --ff                    Frogger/Galaxian Hack is in mame executable\n");
diff --git a/src/SwitchResC/switchres.h b/src/SwitchResC/switchres.h
index efd6231..ebb769e 100644
--- a/src/SwitchResC/switchres.h
+++ b/src/SwitchResC/switchres.h
@@ -69,8 +69,8 @@ typedef struct ConfigSettings {
        int    always_throttle;
        int    xrandr;
        char   ROM[256];
-       double vcalc;
        int    morientation;
+       char   aspect[32];
        int    dcalign;
        int    threads;
        int    triplebuffer;
diff --git a/src/SwitchResC/xml.c b/src/SwitchResC/xml.c
index 7f7fb72..08d83ab 100644
--- a/src/SwitchResC/xml.c
+++ b/src/SwitchResC/xml.c
@@ -223,12 +223,6 @@ int ParseXML(xmlDocPtr xmlbuffer, GameInfo *game, ConfigSettings *cs) {
                                                        if (cs->morientation == 0) {
                                                                game->width = h;
                                                                game->height = w;
-                                                               if (cs->vcalc == 0) // New calculation using 16:9
-                                                                       game->width = (4.0/3.0) * ((double)game->width * (4.0/3.0));
-                                                               else if (cs->vcalc == 1) // Older calculation 4:3 makes things wider
-                                                                       game->width = (4.0/3.0) * game->height;
-                                                               else // Custom calculation
-                                                                       game->width = cs->vcalc * ((double)game->width * (cs->vcalc));
                                                        }
                                                        } else { // horizontal
                                                        game->orientation = 0;
@@ -237,15 +231,14 @@ int ParseXML(xmlDocPtr xmlbuffer, GameInfo *game, ConfigSettings *cs) {
                                                                        int h = game->height;
                                                                game->width = h;
                                                                game->height = w;
-                                                               if (cs->vcalc == 0) // New calculation using 16:9
-                                                                       game->width = (4.0/3.0) * ((double)game->width * (4.0/3.0));
-                                                               else if (cs->vcalc == 1) // Older calculation 4:3 makes things wider
-                                                                       game->width = (4.0/3.0) * game->height;
-                                                               else // Custom calculation
-                                                                       game->width = cs->vcalc * ((double)game->width * (cs->vcalc));
-                                                               //game->keepaspect = 1;
                                                        }
                                                }
+                                               if ((game->orientation && !cs->morientation) || (!game->orientation &&  (cs->morientation == 1))) {
+                                                       double num, den;
+                                                       sscanf(cs->aspect, "%lf:%lf", &den, &num);
+
+                                                       game->width = Normalize((double)game->width * (4.0/3.0) / (num/den), 8);
+                                               }
                                        } else {
                                                game->orientation = 0;
                                        }

Hopefully that all works as I suspect, and should hopefully allow anything to be done in regards to aspect and how a monitor is setup and a user wants to see things.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 08, 2011, 02:04:28 pm
Oh definitely that's the perfect way, so you can actually use the aspect you like as a <num:den> from the command line and actually use it for both virtualized and non stretched cases, great.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 08, 2011, 05:27:00 pm
Hi, I've tried the option - with options vcalc 0 1 2 3 4, but I really have worked well are 1 and 2, we lose the pixel perfect, but I prefer to play without pixel perfect in vertical games Since many of them as esprade, etc. .. mazinger to be so small and not very comfortable this way and whether, many thank you very much.

On the contrary I did not understand the other option (I have not tested this) is that of - aspect, it is not done automatically? Or is it to customize more? which is better?

Regarding the number of resolutions have the same game as is the issue?

Bithebity, you create something really awesome thanks for all this effort, but of course I could go without asking for anything else,) you could put your website on the date of creation links? so I find it easier to see if you have upgraded any link.


Thanks ..
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 08, 2011, 05:47:14 pm
Hi, I've tried the option - with options vcalc 0 1 2 3 4, but I really have worked well are 1 and 2, we lose the pixel perfect, but I prefer to play without pixel perfect in vertical games Since many of them as esprade, etc. .. mazinger to be so small and not very comfortable this way and whether, many thank you very much.

On the contrary I did not understand the other option (I have not tested this) is that of - aspect, it is not done automatically? Or is it to customize more? which is better?

Regarding the number of resolutions have the same game as is the issue?

Bithebity, you create something really awesome thanks for all this effort, but of course I could go without asking for anything else,) you could put your website on the date of creation links? so I find it easier to see if you have upgraded any link.


Thanks ..

Basically it's the same thing now but you have full control.  The old option '--vcalc 0' is now '--aspect 4:3', the old option --vcalc 1 is now --aspect 5:4 essentially, you can use --aspect 7:5, or --aspect 3:3.  This controls how the resolution is calculated for games which are vertical on a horizontal monitor or horizontal on a vertical monitor.  Then it also passes the switched around value like 3:4 in the first case (--vcalc 0) to the mame aspect parameter when things are virtualized. 

I just made the change in my php script to show the dates, sounds good :)

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 08, 2011, 05:51:50 pm
The new 32bit ISO is uploaded LiveCD32-Full-1.439-4a6ebaa.iso and the 64 bit one will be there in a few hours.

The changes are:
Quote
         - volume saved with OSS4 properly during install and for liveCD
         - Switchres uses --aspect num:den now for vertical game calculations
         - Fixed issues with switchres and vertical monitors, direction of rotation
           is now consistant.
         - Setup blanking for normal X Windows
         - Setup terminal not to blank, since it doesn't work on an arcade monitor
         - New xorg.sh script to create xorg.conf
         - Radeon 5xxx card support
         - Fixed bug with .bash_profile not getting created for arcade user
           if home directory wasn't separately mounted
         - Don't ask about formatting /data/ since figure it's an existing partition
         - Require all menu items to be entered before install is done
         - Better label for home partition as arcade users home
         - Remove wahcade config, user must create this on their own
         - Default font no longer forced from /home/arcade/fonts/, up to user to choose
         - Fvwm config changed to only have advmenu/wahcade/setup and xterm buttons
         - Updated Wahcade to 1.0pre and added default setup with switchres

So 5450 radeon cards work perfectly now, new wahcade version and setup easier for it if chosen, lots of bugs fixed

Also soon, in the next ISO, I should have AVGA 3000 card support so those will work perfectly in Linux (which now they do not if you actually try to use the Atom bios on them like KMS DRM does).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 09, 2011, 03:53:27 pm
I'm testing LiveCD32-Full-1.439-4a6ebaa.iso, seems there's a problem with the new aspect option in Switchres, it's passing "-rotate 4:3", the "screen_aspect" option is missing, so Mame complains about unknown command "4:3".
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 09, 2011, 04:00:50 pm
I'm testing LiveCD32-Full-1.439-4a6ebaa.iso, seems there's a problem with the new aspect option in Switchres, it's passing "-rotate 4:3", the "screen_aspect" option is missing, so Mame complains about unknown command "4:3".

Yep, here's my bug:
Code: [Select]
diff --git a/src/SwitchResC/switchres.c b/src/SwitchResC/switchres.c
index d76900a..97023f5 100644
--- a/src/SwitchResC/switchres.c
+++ b/src/SwitchResC/switchres.c
@@ -703,8 +703,10 @@ int main(int argc, char **argv) {
        }
 
        if ((gameInfo.orientation && !cs->morientation) || (!gameInfo.orientation && (cs->morientation == 1))) {
-               if (monitorMode->ModeLine->result & RESULT_VIRTUALIZE)
+               if (monitorMode->ModeLine->result & RESULT_VIRTUALIZE) {
+                       mamearg[mameargc++] = "-screen_aspect";
                        mamearg[mameargc++] = cs->aspect;
+               }
                /*else
                        mamearg[mameargc++] = cs->aspect;
                */

I'll have to fix that, in editing I totally messed that up :)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 09, 2011, 04:39:31 pm
I'll have some new ISO's up by later tonight that fix that aspect ratio command line bug.

Also the next ISO will work with the ArcadeVGA 3000 finally, I figured it mostly out and so now it'll be able to do the mode switching properly and users of that card will be able to enjoy Linux and Switchres on them too.  There's some issues with trying to run horizontal frequencies between 18khz -> 22 or something on a d9800 though, but any normal arcade monitor in fixed ranges should be just fine.  It only affects a few games on my d9800, I'm still trying to figure it out, something to do with PLL dividers probably being a bit off.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 09, 2011, 04:57:06 pm
That's great, the ArcadeVGA 3000 support will make a lot of people decide to test this Linux livecd probably.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 09, 2011, 05:01:42 pm
That's great, the ArcadeVGA 3000 support will make a lot of people decide to test this Linux livecd probably.

Yeah it's cool to be able to boot up and see the grub menu at 15khz and yet it'll go into Linux and run fine with 15khz there too now.  Also can use either interface at 15khz now too, but of course only the VGA one boots right at 15khz.

One oddity though, this card thinks it has two DVI ports, it calls the VGA one a DVI one actually.  Plus the DVI/VGA port is actually interface DVI-2, kinda odd, opposite of what it's saying in Windows.  So the grub boot line will need to use DVI-2 and the xorg.conf will need to reference that DVI-2 port to connect it up to the right Monitor.  I'll have to work out the config setup to adjust for that.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 09, 2011, 11:59:57 pm
The 32bit ISO for version 1.443-ced8096 has uploaded, 64 bit one should be there by tomorrow.


09022011 - Fix bug in switchres command line with aspect option in stretched modes
         - Added fixes for ArcadeVGA 3000 cards so they work in Linux now
         - Grub menu improved, now first menu option should work in most cases
         - Improved xorg.conf creater script xorg.sh

This version has a new grub menu list, first option most likely will work with most setups now for any VGA/DVI interface.  Might need to pick specific ones if you have J-Pac or NTSC/PAL outputs. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 10, 2011, 04:35:23 pm
Hi bitbytebit, I tried the new version but I have to say 15Hz cga monitor options do not work, I tried to AVGA 9250 and an ATI x1300 PCI Express and no way in ati driver loaded into the kernel at principle of image display everything stops, but with the ati x1300 I've tried the option to SVGA and LCD monitor and if it looks when all the boot.


Thanks. :lol
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 10, 2011, 04:40:42 pm
Hi bit, I tried the new version but I have to say 15Hz cga monitor options do not work, I tried to AVGA 9250 and an ATI x1300 PCI Express (I recorcar) and no way in ati driver loaded into the kernel at principle of image display everything stops, but with the ati x1300 I've tried the option to SVGA and LCD monitor and if it looks when all the boot.


Thanks.

Did you try the J-Pac option and the first generic option?  The first option probably won't work for J-Pac I am guessing, it doesn't force the output enabled, but the J-Pac option for DVI or VGA should do that and is still just like the old first one was before.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 10, 2011, 04:44:17 pm
Hi I have no j-pac, but may be worth anyway?


Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 10, 2011, 04:51:33 pm
Hi I have no j-pac, but may be worth anyway?




Yeah that would be interesting, and it's the same as the old first choice which always forced the connector output enabled for just one of the interfaces.  I am guessing it will work with the J-Pac options.

How is your setup exactly, interesting that it needs the J-Pac setting without J-Pac.

Basically the first option now tries all interfaces in CGA mode, but none are forced because we can only force 1 output or else things don't work if more than 1 are forced.  So it is generic, and works if the monitor reports it exists to the video card, which doesn't happen with J-Pac, and your setup too :) which I'm guessing is probably a breakout cable type hook up from VGA to the monitor?  So guess I should word the grub menu better then, and not use the work J-Pac. 

I wish I could figure out a way to change which interfaces are forced on after booting, might be able to, but I have to test that more.  Then I can have a single menu item and in the setup menu choose which interface to output to.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 10, 2011, 04:54:14 pm
I'm trying the new 1.443-ced8096 64bits and it's working perfectly here (I'm still using the last grub option for my motherboard). New --aspect option works fantastic both for stretched vertical games and not stretched. Also the fonts in Mame look good again, no more ugly scaled fonts. I'm seriously considering installing this soon as replacement for my Windows system. Mame loads faster and seems as if the whole thing works smoother than Windows, of course I'm testing this 64bits vs my XP 32bits, so that could be a reason. Apart from Mame, I just have Snes and Genesis on my Win cab, maybe those need some tweaking yet, but most of the time I just use Mame anyway. I'll keep both systems as I need Windows for testing stuff also.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 11, 2011, 07:56:25 am
Hi bitbytebit, I've seen it does not load, I noticed that the option in the grub vga=640x480c I've changed to vga=640x480ec, so missing the letter "e", so that option is worth? I have seen that the option of putting grub with jpac GroovyArcade 15Hz if it's okay, if I have no problems or I can jpac we break with the monitor for not getting the signal correctly?


Thank
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 11, 2011, 10:12:11 am
Hi bitbytebit, I've seen it does not load, I noticed that the option in the grub vga=640x480c I've changed to vga=640x480ec, so missing the letter "e", so that option is worth? I have seen that the option of putting grub with jpac GroovyArcade 15Hz if it's okay, if I have no problems or I can jpac we break with the monitor for not getting the signal correctly?


Thank
I changed the grub.conf back to having the DVI-I-1 forced as the first option, I can see how it's really the most common setup.  The option in grub.conf which will work for your setup on the ISO you have should be...

title=Groovy Arcade LiveCD [15khz J-Pac DVI-1]
         kernel /boot/vmlinuz real_root=/dev/loop0 looptype=squashfs loop=/livecd.squashfs initrd udev nodevfs cdroot video=DVI-I-1:640x480ec
         initrd /boot/initrd

I've removed the word J-Pac in that now, and made it the first choice, so all should be fine in the next ISO. 
 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 12, 2011, 07:08:28 am
Hi bit, I installed the new version with the option of jpac, had the decision not to set grub with the option video = VGA-1: 640x480ec, has not set anything, just normal grub commands.

Another thing I've noticed this morning was that some games do not fit well on screen and games are horizontal, I put a Capure here for you to check, you can also look out for in the decision graph that has the menu mame, I think you had already solved, right?


(http://img511.imageshack.us/img511/9641/20110212105048.jpg) (http://img511.imageshack.us/i/20110212105048.jpg/)

(http://img823.imageshack.us/img823/8353/20110212105101.jpg) (http://img823.imageshack.us/i/20110212105101.jpg/)

If we change the full option to crooped the game fits well but has a strange effect when moving.

(http://img23.imageshack.us/img23/8931/20110212105112.jpg) (http://img23.imageshack.us/i/20110212105112.jpg/)


(http://img26.imageshack.us/img26/3514/20110212105309.jpg) (http://img26.imageshack.us/i/20110212105309.jpg/)

(http://img696.imageshack.us/img696/4609/20110212105316.jpg) (http://img696.imageshack.us/i/20110212105316.jpg/)

Now ghost chaser, this looks completely straight, if you change the option of full and Cropper stays well and has that strange effect on the image.
Notice how the default game is fully stretched, with very large characters with weird effect

(http://img708.imageshack.us/img708/5289/20110212105416.jpg) (http://img708.imageshack.us/i/20110212105416.jpg/)

(http://img6.imageshack.us/img6/9990/20110212105424.jpg) (http://img6.imageshack.us/i/20110212105424.jpg/)

(http://img842.imageshack.us/img842/9137/20110212105419.jpg) (http://img842.imageshack.us/i/20110212105419.jpg/)

(http://img35.imageshack.us/img35/7215/20110212105537.jpg) (http://img35.imageshack.us/i/20110212105537.jpg/)

(http://img822.imageshack.us/img822/139/20110212105544.jpg) (http://img822.imageshack.us/i/20110212105544.jpg/)


Looking at the log of mame, I've seen that gives the ruling OpenGL: PBO not supported by, it is possible that the 9250 AVGA not support such resolutions.
Or maybe not generate switchres While these resolutions?

(http://img69.imageshack.us/img69/980/20110212103945.jpg) (http://img69.imageshack.us/i/20110212103945.jpg/)









Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 12, 2011, 07:50:01 am
Hi VeS, that's not Switchres fault, what happens is that Mame reports a smaller resolution than the real one. Normally, those games perform mode switching during the game play, so Mame just reports one of the resolutions, that is the one that Switchres calculates, then when the game switches its resolution internally, our screen resolution does not change so the picture is chopped. That happens with many Sega games. What you can do by now, is to enable the 'changeres' option for those games, using an ini for each of those roms, or better an ini for the problematic driver (well that might not work with Linux as we only enable one resolution each time I believe). The best solution I think it is to make an ini for each of those games with the right resolution used, like it's done with the 'dbz.ini' you can find inside the ini folder.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 12, 2011, 07:53:03 am
But by changing the option of full by Cropper and fits the game well, what happens is something that has a strange effect.
There is also the error of OpenGL, you might see if you also gives you that error? and you might try these games?


Thank.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 12, 2011, 07:55:26 am
Don't worry about the PBO not supported message, I also see it here, doesn't matter.

If you use the option "full", the game will be stretched so it will ruin the picture.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 14, 2011, 02:02:10 pm
New ISO Images up with the following changes:

Quote
    - ArcadeVGA 3000 card shows input as VGA-1 like it should, no longer calls it a DVI port
    - Switchres multi monitor ranges changed to match most flat screen LCD monitors
    - Newer Linux kernel AVIVO Radeon PLL calculations, improves refresh rate accuracy
    - ArcadeVGA 3000 now works perfectly in Linux, on d9800 too, no restrictions
    - Grub menu listings have better descriptions
    - Mame updated to 141u2

Now the ArcadeVGA3000 works without any problems at all, and radeon cards in general have improved timing.  Test and report any bugs/issues. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 15, 2011, 05:23:21 pm
Testing 1.455 iso, 64 bit, everything perfect here. I notice Twin Cobra is running at 100% now. Actually all games I've tested run at exact 100%, where before you could very rarely see a fluctuation around 99%-100%, not sure but could it be the new pll calculation method is improving things there. Also I'm seeing again this soundsync bevaviour that seems to be built in the Linux OSD part, it's really interesting because sound is automatically adjusted to gameplay in Linux, as Windows Mame versions prior to 0.107 did. I might be wrong, but I'm wondering if Windows OSD could be modified to do the same without the need of the soundsync patch.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 15, 2011, 06:00:32 pm
Hello bite I've tried the new version 1455 iso 32 bit.

Bugs detected.

Grub installation is not configured with the option video = vga-1: 640x480ec

When you install and create a partition for home, when you create two folders you created arcade and arcade.default not know if it's something concrete.

Alsa sometimes I recognized the sound and others not, but when you restart the pc, never recognize it.
I still have oss4 and I already like it more or less ;)


I have reviewed many games all, in the absence of a bit like:

1000 miglia great 1000, this game I've been playing about 40 minutes and from time to time we came out a band that crossed the entire screen lower left corner to upper right corner, then I tried a little and I have not seen since May be a bug by using version mame 141u2.

Toki my favorite game is out of sync the entire game has a resolution of 256x224@59.610000
If you create the toki.ini with that resolution is out of sync, but if you change the 59.61 by 59, 59.62, 59.63 works well, I think it switchres error, but I can not confirm because I have not found any game more with that resolution, you can try?


Calamity when you say that all games are 100% that you see in Terminal 1 in the logs from time to load each game, right? whenever I get my 99.9% 99.98% have pc's could be more powerful than others? you can put the description of your pc? micro memory etc. ..

That lack of affect significantly the% pixel perfect or operation of the game? where it can be noticed more?

For sound, I have noticed no synch problems, but if some decisions newzeland sound like the story, in its Japanese version.

Thank.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 15, 2011, 06:17:14 pm
Calamity when you say that all games are 100% that you see in Terminal 1 in the logs from time to load each game, right? whenever I get my 99.9% 99.98% have pc's could be more powerful than others? you can put the description of your pc? micro memory etc. ..

That lack of affect significantly the% pixel perfect or operation of the game? where it can be noticed more?

I mean the percentage it shows when you press F11, of course it's rounded to an integer so it could be 99,8% actually. When I talk about % it's always about speed of gameplay/operation.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 15, 2011, 06:57:24 pm
Hello bite I've tried the new version 1455 iso 32 bit.

Bugs detected.

Grub installation is not configured with the option video = vga-1: 640x480ec

When you install and create a partition for home, when you create two folders you created arcade and arcade.default not know if it's something concrete.

Alsa sometimes I recognized the sound and others not, but when you restart the pc, never recognize it.
I still have oss4 and I already like it more or less ;)


I have reviewed many games all, in the absence of a bit like:

1000 miglia great 1000, this game I've been playing about 40 minutes and from time to time we came out a band that crossed the entire screen lower left corner to upper right corner, then I tried a little and I have not seen since May be a bug by using version mame 141u2.

Toki my favorite game is out of sync the entire game has a resolution of 256x224@59.610000
If you create the toki.ini with that resolution is out of sync, but if you change the 59.61 by 59, 59.62, 59.63 works well, I think it switchres error, but I can not confirm because I have not found any game more with that resolution, you can try?


Calamity when you say that all games are 100% that you see in Terminal 1 in the logs from time to load each game, right? whenever I get my 99.9% 99.98% have pc's could be more powerful than others? you can put the description of your pc? micro memory etc. ..

That lack of affect significantly the% pixel perfect or operation of the game? where it can be noticed more?

For sound, I have noticed no synch problems, but if some decisions newzeland sound like the story, in its Japanese version.

Thank.


Thanks for finding that error with grub.conf and video=, I fixed that just now, was a side effect of the new grub menu and xorg.sh setup script.  Now it should be done a bit more robust and not have issues like that again.

I just changed setup to remove the /home/arcade/arcade.default directory, it uses that in a copy/mount/copy sequence for setting up the new home/arcade partition or directory, and was just leaving it there.

Yeah that is strange about Alsa, I'm not sure what it's doing, but might be thinking there's another interface upon boot or something.  See what 'aplay -l' looks like when you boot and/or it doesn't work. 

I tried the toki game, and it works fine here in 15khz h9110 monitor mode and others, not sure what it's doing but may be something tricky about the monitor.  Here's the modeline it should produce (here I get the exact same modeline with 59.61 or 59.63 so shouldn't really change what is setup either way).  Maybe Calamity can see how his monitor reacts to that game, I think he's got the same one...


mcp GroovyArcade # switchres --monitor h9110 --calc 256 224 59.61
#  256x224@59.61 15.6774Khz
   ModeLine          "256x224x59.61" 5.518455 256 272 304 352 224 235 238 263 -HSync -VSync


Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 16, 2011, 08:54:40 am
Hello bitbytebit, as I said toki is my favorite and I always use is to test the lives (of course that also taste other) and have never had porblem with up to install the latest version.
If I remember right before formatting the hd, install, I tried it and it worked fine, but after installation I stop, but if so it makes no sense, no? if I can this afternoon formateare again and proves it.
Waiting for Calamity try it and tell me that this is going, if you try it with the AVGA Calamities.

With respect to the other game, I've understood, the error was happening?
is how to split the screen diagonal, and towards dbz snes when alebajan characters.



Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 16, 2011, 02:09:02 pm
Hello bitbytebit, as I said toki is my favorite and I always use is to test the lives (of course that also taste other) and have never had porblem with up to install the latest version.
If I remember right before formatting the hd, install, I tried it and it worked fine, but after installation I stop, but if so it makes no sense, no? if I can this afternoon formateare again and proves it.
Waiting for Calamity try it and tell me that this is going, if you try it with the AVGA Calamities.

With respect to the other game, I've understood, the error was happening?
is how to split the screen diagonal, and towards dbz snes when alebajan characters.



Thanks.

See if the output with -v -v on switchres shows any difference in the resolution setup by xrandr, possibly on the older and newer ISO, or when it works and doesn't.   I'm not sure, it might be the newer kernel perhaps and the calculations done for the dotclock/PLL but that part really shouldn't have changed for the older ATI cards and only the newer AVIVO ones.  Figuring out exactly what is triggering it, the dotclock value possibly being below a certain amount or something like that, would be the way to pin it down more and be able to figure out what is causing it. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 16, 2011, 03:41:12 pm
Hello bitbytebit, with respect to toki've been testing the mame directory toki upload, looks good, but not take up his resolution, if I use switchres toki no way, I have to have the toki.ini with its resolution and take on 1 the 59.61hz, so I think the problem is the calculation that makes switchres.
Then I try the options you told me-v-v ....

I've noticed that on the main console get this
Code: [Select]
Resolution change from 762457453x757738794 to 256x224
Opengl PBO not supported.

I do not remember if it comes from all games, then I test it too.

With respect to alsa, oss when you change to alsa from the install works fine, but once you restart the configuration is lost, do not let predterminada sound card, and I have to get back to oss sound.


With respect to the other side the screen play from the 2 nd phase, and today has less echo, so I think it is to use an unstable version of mame.


Thank.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 16, 2011, 03:48:29 pm
Hello bitbytebit, with respect to toki've been testing the mame directory toki upload, looks good, but not take up his resolution, if I use switchres toki no way, I have to have the toki.ini with its resolution and take on 1 the 59.61hz, so I think the problem is the calculation that makes switchres.
Then I try the options you told me-v-v ....

Actually separate those, "-v -v -v" since together they won't do the same thing :). 

It seems like running switchres is showing a good modeline calculated, and it works here, so I'm pretty sure switchres isn't the issue, also it hasn't really changed since the last version but the kernel has.

I've noticed that on the main console get this
Code: [Select]
Resolution change from 762457453x757738794 to 256x224
Opengl PBO not supported.

I do not remember if it comes from all games, then I test it too.

Those are normal, the PBO message is just meaning your video card doesn't support OpenGL PBO methods, and that's ok.

The resolution change is just a verbose message I put in there, and doesn't matter either, just showing that the resolution wasn't initialized yet at that point in mame, so it's ok.



With respect to alsa, oss when you change to alsa from the install works fine, but once you restart the configuration is lost, do not let predterminada sound card, and I have to get back to oss sound.


With respect to the other side the screen play from the 2 nd phase, and today has less echo, so I think it is to use an unstable version of mame.


Thank.

Yeah Alsa is hard to save the configuration of and pass it into the distribution install, which is one reason I like OSS4 much better.  Hopefully OSS4 just works fine since I see it as a better system than Alsa because it's easier to do things like setup without things muted and works without any manual choosing/setup like Alsa often requires (which a lot of distributions probably do a lot of extra non-default stuff, I did have to hack at OSS4 to get it working on the LiveCD, but now it works quite nice).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 16, 2011, 04:45:44 pm
I've tested toki here and it works fine. VeS, please try snowbros, bublbobl, and rygar, which video modes are around toki's one. I think that launching mame without switchres using an ini shouldn't tell us much as the resolution you're writting there will not available unless you use switchres, so a random one must have been selected, as I understand it (?)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 16, 2011, 04:49:32 pm
I've tested toki here and it works fine. VeS, please try snowbros, bublbobl, and rygar, which video modes are around toki's one. I think that launching mame without switchres using an ini shouldn't tell us much as the resolution you're writting there will not available unless you use switchres, so a random one must have been selected, as I understand it (?)

Yeah with only an .ini like that, it'll pick the only one available (or should be unless xorg.conf isn't setup right) of 648x480@60.

Ves: What is the output of `xrandr -q --verbose` during the game, remote ssh in and see what that says and post it here.  That might show at least the details of the modeline that is failing (do this when the game is not working, without any .ini file). 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 16, 2011, 05:15:37 pm
Hi I've seen where is the bug of alsa, the problem is not properly configured gasetup inwhichthe alsa to start when loading Linux, the solution is this:

update-rc add alsasound default
update-rc del oss default

Remember that if we switch to OSS should do otherwise.

update-rc add oss default
update-rc del alsasound default

I've seen more league oss is loaded, since all load alsa modules, which has improvements over alsa oss?

Is there any program that detects the hardware you have our pc and so I pass that setup the kernel / alsa etc. .. and so only load as needed, to make it faster?

I think it should also be included in the option Gasetup the aspect switchres
mame default / switchres horizontal resolution
4:3 full screen.
3:3 larger screen, more faithful to the original
etc.......

With respect to toki, Calamity AVGA have used the 9250?
I hit that gives the options switchres

-v -v toki.

Resolution change from 762457453x757738794 to 256x224
# toki [4] 256x224@59.61 15.6774Khz
     "256x224x59.61" 5.518455 256 272 304 352 224 235 238 263 -HSync -VSync


(http://img5.imageshack.us/img5/4536/20110216222039.jpg) (http://img5.imageshack.us/i/20110216222039.jpg/)


-v -v -v toki

Resolution change from 762457453x757738794 to 256x224
# toki [4] 256x224@59.61 15.6774Khz
     "256x224x59.61" 5.518455 256 272 304 352 224 235 238 263 -HSync -VSync

(http://img198.imageshack.us/img198/2615/20110216222105.jpg) (http://img198.imageshack.us/i/20110216222105.jpg/)




Calamity've tried all these games, which I use for testing and I work without any problem, I just think about this and that is the frequency, I looked at mame.xml and on the web but is only to toki that frequency.

Thank.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 16, 2011, 05:44:12 pm
Hi I've seen where is the bug of alsa, the problem is not properly configured gasetup inwhichthe alsa to start when loading Linux, the solution is this:

update-rc add alsasound default
update-rc del oss default

Remember that if we switch to OSS should do otherwise.

update-rc add oss default
update-rc del alsasound default

Cool, I just fixed that, this patch shows the bug that was there....

Code: [Select]
diff --git a/gasetup/core/procedures/interactive b/gasetup/core/procedures/interactive
index ba20d6a..ebf386b 100644
--- a/gasetup/core/procedures/interactive
+++ b/gasetup/core/procedures/interactive
@@ -237,7 +237,7 @@ previous_setup()
                 /etc/init.d/oss stop
                 /etc/init.d/alsasound start
                 rc-update del oss default
-                rc-update add alsa default
+                rc-update add alsasound default
        fi
 
        if [ "$VOLVALUE" != "" ]; then
@@ -535,7 +535,7 @@ worker_set_alsa()
                fi
                /etc/init.d/alsasound stop
                /etc/init.d/oss start
-               rc-update del alsa default
+               rc-update del alsasound default
                rc-update add oss default
 
                cat $CONFIG_FILE | sed -e 's/alsa=.*//g'| grep -v ^$ > ${CONFIG_FILE_TMP}
@@ -555,7 +555,7 @@ worker_set_alsa()
         /etc/init.d/oss stop
         /etc/init.d/alsasound start
        rc-update del oss default
-       rc-update add alsa default
+       rc-update add alsasound default
 
        audiodev=$(aplay -l|grep ^card|grep Analog|head -1|awk '{print $2}'|sed -e s/://g)
        if [ "$audiodev" = "" ]; then


I've seen more league oss is loaded, since all load alsa modules, which has improvements over alsa oss?

Is there any program that detects the hardware you have our pc and so I pass that setup the kernel / alsa etc. .. and so only load as needed, to make it faster?

I'm not sure, That is one strange thing about Alsa setup and how it seems to need to load all modules like that (and has so many).

I think it should also be included in the option Gasetup the aspect switchres
mame default / switchres horizontal resolution
4:3 full screen.
3:3 larger screen, more faithful to the original
etc.......

Yeah I'll have to put the aspect setup into the menu, sounds good. 

With respect to toki, Calamity AVGA have used the 9250?
I hit that gives the options switchres

-v -v toki.

Resolution change from 762457453x757738794 to 256x224
# toki [4] 256x224@59.61 15.6774Khz
     "256x224x59.61" 5.518455 256 272 304 352 224 235 238 263 -HSync -VSync


(http://img5.imageshack.us/img5/4536/20110216222039.jpg) (http://img5.imageshack.us/i/20110216222039.jpg/)


-v -v -v toki

Resolution change from 762457453x757738794 to 256x224
# toki [4] 256x224@59.61 15.6774Khz
     "256x224x59.61" 5.518455 256 272 304 352 224 235 238 263 -HSync -VSync

(http://img198.imageshack.us/img198/2615/20110216222105.jpg) (http://img198.imageshack.us/i/20110216222105.jpg/)



Thank.



It does seem to setup the video mode correctly, but if output is bad and it wasn't in the last version, I'm pretty sure it's the kernel.  I'll have to take a closer look, also the next ISO will have a newer kernel 2.6.38-rc5 on it and maybe it's fixed there.  We definitely are keeping the kernel working with 15khz modes since the last version broke them on the newer Radeon cards and I caught that and got it fixed, so hopefully if this is really the kernel and doesn't get fixed by the newest version then we can report it.  Main question is narrowing down exactly what is causing it, dotclock value being below a certain value plus hardware, what seems to be the main trigger of the bug. 

Also to get more verbose console output from the /var/log/messages or dmesg, you can do this...

echo 65536 > /sys/module/drm/parameters/debug

it will show a lot of messages, might be interesting to see the log /var/log/messages after doing this and running the game.  It might show something, not sure though how much information on the clock PLL divers and stuff are printed out.


Also for switchres, you can do --logfile logfile.txt  and capture that all to a logfile too :) so easier to record/post the details that way.  I don't think it's switchres though, it seems to be the kernel PLL calculations I'm guessing.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 16, 2011, 06:00:00 pm
If snowbros works then it can't be the dotclock too low as this one is lower, maybe the new pll algo is failing right there for some reason? What's strange is that in radeon drm code they seem to be using a legacy function for older card so maybe they've modified it too in last kernel.

VeS, I haven't tested this one with the 9250 yet, only with HD4350.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 16, 2011, 06:05:03 pm
Ok bit, tomorrow I send the logs.
Could make another request for gasetup? it's just that you add keyboard language option in Spanish



Certainly in /data is still not create the snap flyer cabinet symlinks etc ....

I tried to install:
only a particon /
partition / and /data
partition /, /data and /home.

anyway I think it would be better to have data mame folder and all folders within that contain mame, and so could also include snes, nes, gen etc. .. instead of putting just roms.

Thank
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 16, 2011, 06:10:16 pm
Ok bit, tomorrow I send the logs.
Could make another request for gasetup? it's just that you add keyboard language option in Spanish



Certainly in /data is still not create the snap flyer cabinet symlinks etc ....

I tried to install:
only a particon /
partition / and /data
partition /, /data and /home.

anyway I think it would be better to have data mame folder and all folders within that contain mame, and so could also include snes, nes, gen etc. .. instead of putting just roms.

Thank

I need to look at how to add multilanguage support like that, right now I run a script which trims them down to one because else the disk space was really large.  On a LiveCD this was the way they did it in the examples I saw, but I will have to look and see if it really needs to be done.  It might not be too much space, and then could pick any language most likely.

In /data/ actually it won't anymore.  Now the way to do that would be editing the advancemame config instead, so they could be anywhere in the file system as /data/ /home/ or anywhere else actually. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 17, 2011, 05:32:03 pm
Bitbytebit Hi, I copied the rc3 kernel in the last livecd 1.455 and I've tried installing the game toki, which already works well, I've also tried the 1000 miglia great 1000 for about 4 or 5 stages and have not seen at any time the error split screen.

With regard to the command xrandr-q - verbose, with kernel version, he said it was not possible to display screen (can not remember, but it was something like that) with the previous kernel I have not tried.


So the problem we have in the kernel, pogo you here my logs, holding at various times.
logs from the install.
logs2 previous deleted without running toki.
anterior and running logs3 toki deleted.




Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 17, 2011, 05:47:11 pm
Bitbytebit Hi, I copied the rc3 kernel in the last livecd 1.455 and I've tried installing the game toki, which already works well, I've also tried the 1000 miglia great 1000 for about 4 or 5 stages and have not seen at any time the error split screen.

With regard to the command xrandr-q - verbose, with kernel version, he said it was not possible to display screen (can not remember, but it was something like that) with the previous kernel I have not tried.


So the problem we have in the kernel, pogo you here my logs, holding at various times.
logs from the install.
logs2 previous deleted without running toki.
anterior and running logs3 toki deleted.




Thanks.

Try this for the xrandr command:

xrandr -q -display :0.0 --verbose

That should allow it to work remotely.


I was wrong about the value to put into debug, actually it's this:

echo 65535 > /sys/module/drm/parameters/debug

That should output a lot more into the /var/log/messages file :)

If possible, just run the xrandr before, and during the problem game.  Run the debug messages file before starting the game on a fresh reboot (where logs were cleared before the reboot) and then right after the game is running, copy the logs right at that point (they will grow fast).  Mainly want to see what it says when setting up the modeline for the game, but want to be able to pinpoint exactly where the messages are that were happening while the game was setup.


I think I have it where in the newer ISO the keyboard will be able to get set to any other type through gasetup.  Hopefully the newer kernel version might fix this issue with the video calculation too, will have to see.  Hopefully I'll have that ready in a day or two, but the logs might be interesting from the above two tests. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Gray_Area on February 17, 2011, 08:11:26 pm
I'm still not understanding why you would need 'dummy modes' with soft15khz.

Also:

I've been working on the assumption of a monitor database of the needed settings, so you just have to say h9110 or d9800, ntsc, pal or cga etc.   There could be more monitors added with people looking up the specs and testing them, but understand it's not totally user-friendly although it'll probably take time to gather that information, which will eventually lead to being more user friendly for each monitor type.  For an h9110, d9800, generic CGA monitor it should just make the best decisions and be more user friendly than advance was because you just have to tell it your monitor type in those cases.

Advcfj had this feature, the arcade multisync of the time being the D9200.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 17, 2011, 11:07:52 pm
I'm still not understanding why you would need 'dummy modes' with soft15khz.
dummy modes is probably not the right term to explain it fully.  Anyways it's really only with ATI radeon cards, and only the older hd4xxx ones and before, quite limiting unless you buy one of those older cards.  Basically on the ATI card that is older, with a patched CCC driver, you can only have 130 custom modlines.  This number is below 30 or something with a non-hacked ATI driver, and it might have to be an older one too I guess, at least for certain ATI cards.  So when you can only have so many modelines, you might want to have a 320x240 modeline that can be dynamically altered to be any refresh rate so it takes the place of having 5-10 modelines at 320x240 but every one a different refresh rate.  So that modeline, the 320x240 one, is no longer limited to one single refresh rate or dotclock, and that is what the 'dummy mode' reference means.   With Soft15khz you can set modelines, but you can only do the 30 - 130 normally and so to match all the possibilities of refresh rates you need to dynamically alter them too.  There is a way to reload them in the ATI driver, for the older radeon cards, and that is how those modelines can be manipulated in conjunction with Soft15khz inserting them into the registry and we can do the tricks in switchres to change them while keeping the basic HxW part of the modeline the same.


Also:

I've been working on the assumption of a monitor database of the needed settings, so you just have to say h9110 or d9800, ntsc, pal or cga etc.   There could be more monitors added with people looking up the specs and testing them, but understand it's not totally user-friendly although it'll probably take time to gather that information, which will eventually lead to being more user friendly for each monitor type.  For an h9110, d9800, generic CGA monitor it should just make the best decisions and be more user friendly than advance was because you just have to tell it your monitor type in those cases.

Advcfj had this feature, the arcade multisync of the time being the D9200.

Well the d9200 is actually so much different than a d9800, I've seen how for some reason this isn't well known, but look at the spec sheets and even then it still isn't obvious.  I had to ask the Wells Gardner support guy about this, and he stated that a d9800 (and I can confirm this myself through experience) can do anything withing the whole range of 15.230Khz -> 38.00Khz.  A d9200 actually can only do fixed areas (around 1.5 khz width each) of that range around the main frequencies like 15.725, 24khz, 31.5 khz and unofficially 38khz but they won't support that and it might ruin your d9200 monitor and they seem to die frequently anyways without pushing them like that.

I've really thought lately about either using PowerStrip in Windows to truly have fully Arcade mode support for any card/driver/OS version, saying a user should pay them $30.00 (which is cheaper, cheaper than an ArcadeVGA 3000 card and you don't have to buy another video card either) and then they've got the whole deal.  Or just say use Linux, because we are truly able to do this stuff there and only should become better in the future while in Windows the door is ever closing in on supporting Arcade modelines.  I can get an ATI 5450 to do perfect arcade resolutions in Linux, in Windows it's impossible (at least without Power Strip, but I can't guarantee it will do it either). 

The modeline generation to fit the monitor sync pulses and porches is what is important, and yes AdvanceXXX programs did just that.  Unfortunately only with a few video cards, old ancient ones by todays standards, and after looking through that code quite a bit and trying to see if it could work with modern mame I realized it was a no-go to ever get it modernized.  Actually I think the whole way Advance mame tried to rewrite mame completely was the biggest problem, how could that be maintained, mame changes faster than anything I've seen in API and general structures internally.  I am looking at ways to push switchres functionality into the mainline mame through patches though, and not have it be too hard to keep up to date.  This is a long-term project though, nothing that will probably happen anytime soon.  It would be neat though to have a version of mame able to generate a modeline that could be inserted in Linux through xrandr or Windows through powerstrip and used, so no extra wrapper program needed and no real deep thinking of a user or even of the logic in the extra code (since when in mame, you would know a lot more and be able to set settings properly, none of this extra fiddling with how to send mame command line args for the specific games modeline and if it can match the refresh rate, etc...).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 17, 2011, 11:12:58 pm
Bitbytebit Hi, I copied the rc3 kernel in the last livecd 1.455 and I've tried installing the game toki, which already works well, I've also tried the 1000 miglia great 1000 for about 4 or 5 stages and have not seen at any time the error split screen.

With regard to the command xrandr-q - verbose, with kernel version, he said it was not possible to display screen (can not remember, but it was something like that) with the previous kernel I have not tried.


So the problem we have in the kernel, pogo you here my logs, holding at various times.
logs from the install.
logs2 previous deleted without running toki.
anterior and running logs3 toki deleted.




Thanks.

Ves, try this ISO and see if the modes act better with the newest kernel:

LiveCD32-Full-1.474-41df10d.iso

Also I have Spanish (and any other) keyboard support and should have the LOCALE setup possible too for Spanish and a few other languages.  So this should be mostly supporting multi-languages/keyboards now.  Also I have the Alsa issues fixed and the aspect ratio capable of being changed in the setup menu.

I am working too on having Wah!Cade easily setup itself without any user setup, just about that is at least for the Mame stuff.  There's still a few little issues there I've got to work out but it's nice to see WahCade not require tons of extra work to get it setup and basically just run like AdvanceMenu does and work immediately/find everything correctly.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 18, 2011, 08:50:25 am
If snowbros works then it can't be the dotclock too low as this one is lower, maybe the new pll algo is failing right there for some reason? What's strange is that in radeon drm code they seem to be using a legacy function for older card so maybe they've modified it too in last kernel.

VeS, I haven't tested this one with the 9250 yet, only with HD4350.

I think I found the only possible change, and yes there is a change they made in that patch to the legacy code (I've added to the bug report I filed for the AVIVO part of that patch now, so hopefully we'll get this fixed especially if this is really the code doing it)...
Code: [Select]
@@ -849,7 +951,7 @@ void radeon_compute_pll(struct radeon_pll *pll,
  max_fractional_feed_div = pll->max_frac_feedback_div;
  }
 
- for (post_div = max_post_div; post_div >= min_post_div; --post_div) {
+ for (post_div = min_post_div; post_div <= max_post_div; ++post_div) {
  uint32_t ref_div;
 
  if ((pll->flags & RADEON_PLL_NO_ODD_POST_DIV) && (post_div & 1))

Seems that in the legacy function the direction they count for the post divider is now from minimum post divider to max till they find one that works, not max to minimum anymore.  Maybe this for some reason is failing, I've asked Alex Deucher too so we will see what he does/produces to try.

Here's the original patch and explanations...

https://bugs.freedesktop.org/attachment.cgi?id=41943

Basically looks like this is the change, and I suspect it is the problem:
Quote
Also, switch
the legacy algo back to preferring lower post dividers.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: quazl on February 18, 2011, 01:10:50 pm
First of all, thanks so much for the work and the thread! Truly Epic!

I have read 90 percent and only understood 20 percent, but I have made it here.

I am going to be testing on my cab this weekend and will give my specs and results.

Macro specs are D9800 with a AVGA HD2400 with a 2.53 Dual-Core and also an onboard video to complicate things. I thought I would jump in because I haven't seen many or any mention of the HD2400 AVGA card on this thread. I hope to have a good experience but also help out with my experience if issues arise.

My intention is to have a dual boot with both partitions setup to use. Not necessary but thought I would give it a go.

One question to help me start out because this thread has pretty much the kitchen sink. :)

The HD2400 AVGA card came right before the 3000 but was intended for the d9200 which only supported up to 31KHZ I think. The d9800, as you know, goes to 38KHz. I have been trying to achieve 800x600 60Hz but the AVGA HD2400 is only able to do 800x600 FH 32.8KHZ  FV 52.3HZ which is spec.

Does any of your modelines in Linux or windows support 800X600  FH 37.8KHZ  FV 60.2HZ? This would not be for games but a nice full desktop experience.

Will the live CD work with an AVGA card or will I need to buy a "normal" ATI card? I only ask this because I have been unsure if Calamity's AVGA was flashed or not. I know that bitbytebit has a flashed 3000 but was unsure of the 9250 in Calamity's setup.

Again, Thanks so much for this. It has been a great 3 days reading this thread and getting excited about making my cab better.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 18, 2011, 01:49:01 pm
First of all, thanks so much for the work and the thread! Truly Epic!

I have read 90 percent and only understood 20 percent, but I have made it here.

I am going to be testing on my cab this weekend and will give my specs and results.

Macro specs are D9800 with a AVGA HD2400 with a 2.53 Dual-Core and also an onboard video to complicate things. I thought I would jump in because I haven't seen many or any mention of the HD2400 AVGA card on this thread. I hope to have a good experience but also help out with my experience if issues arise.



Definitely will be good to test the next ISO image, I'm getting the whole grub setup more bullet proof and also have a fix in the kernel hopefully for the older Radeon cards which the last kernel update broke for a few games modelines.


My intention is to have a dual boot with both partitions setup to use. Not necessary but thought I would give it a go.

One question to help me start out because this thread has pretty much the kitchen sink. :)

The HD2400 AVGA card came right before the 3000 but was intended for the d9200 which only supported up to 31KHZ I think. The d9800, as you know, goes to 38KHz. I have been trying to achieve 800x600 60Hz but the AVGA HD2400 is only able to do 800x600 FH 32.8KHZ  FV 52.3HZ which is spec.

Does any of your modelines in Linux or windows support 800X600  FH 37.8KHZ  FV 60.2HZ? This would not be for games but a nice full desktop experience.

Great to have another AVGA card being tested, should be interesting :).  It really should be easy to generate a modeline for that resolution with switchres, for a desktop will definitely require a customized one since we do a 648x480 for the desktop by default (progressive for the d9800, interlaced for arcade monitors).

Oddly If I run switchres like this, I get a modeline that probably will be good for your card...

mcp SwitchResC # ./switchres --calc 800 600 52.3 --monitor d9800 -v -v
#  [5] 800x600@52.30 34.0473Khz
     "800x600x52.30" 34.319678 800 832 936 1008 600 614 618 651 -HSync -VSync

Which is odd because it's not the resolution it picks as the best one, since technically it's slightly padded, but it does work.  The lower vertical refresh rate is what makes it harder to do than a normal 800x600@60 resolution it seems.  This one above should worth though, the "-v -v" args show the different possible choices, and this one is not the final pick but it should be good.

This will have to be manually placed into /etc/X11/xorg.conf for now, after the normal d9800 monitor setup with 648x480@60 progressive, since I haven't got the setup menu able to do things like this with more advanced desktop resolutions for monitors like the d9800 yet.




Will the live CD work with an AVGA card or will I need to buy a "normal" ATI card? I only ask this because I have been unsure if Calamity's AVGA was flashed or not. I know that bitbytebit has a flashed 3000 but was unsure of the 9250 in Calamity's setup.

Again, Thanks so much for this. It has been a great 3 days reading this thread and getting excited about making my cab better.

It should hopefully work with the AVGA card just fine, calamity's isn't flashed, and I'm using my AVGA 3000 now unflashed (I flashed it back) just great with all of this.  I'm curious of course that that version of the AVGA works the same as the older ones and my newer one.  If not then it might need a similar fix that I did for the 3000 model, so the Linux kernel can work with it properly.

This newer ISO I am about to upload should be the best one to test, I'll announce it here later tonight hopefully.  I'm working on the grub setup right now, so definitely should be nicer since it sounds like you'll need that improvement for dual boot.  There is an issue I'm seeing when the grub setup isn't a real basic one where /dev/sda1 is the install partition, and I've hopefully fixed that but still testing if it really is fixed.  Also again it contains the fixes for legacy radeon cards, although now looking it seems the hd2400 is not a legacy one, and if it does the same stuff the hd2600 AVGA 3000 does then you can definitely help me fix it too :).  We'll see how it works and if it has the same issues, I'll have to get some logs and information from you about it and I can make it work with some additional fixes to the kernel.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 18, 2011, 09:50:31 pm
New version is uploaded LiveCD32-Full-1.483-a8aa10a.iso and 64bit one should be up in a few hours or less.

Changelog:

    - Fixed grub setup so it chooses right drive if not the first partition on /dev/sda
    - Reverted change in legacy PLL divider calculation for legacy radeon cards
    - Controls.ini file added to /data/cat/ so Wahcade is happy
    - .xinitrc setup improved, mame.xml file same in wahcade as advmenu now
    - Linux kernel updated to 2.6.38-rc5
    - fixed grub.conf setup with proper video= line from install
    - fixed bug setting up Alsa
    - Added configuration of keyboard layout in gasetup
    - Added configuration of aspect ratio for mame in gasetup

Ves: This may fix the issue with the toki game and the radeon 9200 AVGA card.  Also curious if the last ISO (I still have it up for 32bit) I posted with this same kernel doesn't fix it, so can make sure it's that simple 1 line change from the previous patch for legacy/avivo PLL setup.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 19, 2011, 05:12:09 am
I'm still not understanding why you would need 'dummy modes' with soft15khz.
dummy modes is probably not the right term to explain it fully.  Anyways it's really only with ATI radeon cards, and only the older hd4xxx ones and before, quite limiting unless you buy one of those older cards.  Basically on the ATI card that is older, with a patched CCC driver, you can only have 130 custom modlines.  This number is below 30 or something with a non-hacked ATI driver, and it might have to be an older one too I guess, at least for certain ATI cards.

Well, actually the number of custom modes you can define with regular drivers from different cards are:

- Intel: 5 custom modes (according to Sailorsat)
- nVidia: 32 custom modes (according to Sailorsat)
- ATI: 60 custom modes (according to my experience and reverse engineering of ATI drivers)

In Windows, the list of available video modes is only read by the system at startup, so you can't add any new video mode on the fly, as you can with Linux. However, ATI drivers have a non-documented feature that allows us to modify the definition of a given video mode with inmediate effects, as long as you keep the resolution (notice the difference, resolution = WxH, video mode = resolution + refresh). That combined with the bigger amount of modes supported by ATI drivers is the reason we've focused all this stuff on ATI cards. Think of this dummy modelines as having a palette of video modes. When you have a palette, you actually choose from a limited number of items simultaneously, but if you are able to dynamically change any of those items, then with some additional work the result can be as good as if you had an unlimited number of items.

Now, my patch for ATI drivers works like this: actually you can only store 60 custom modes (in the driver they're labelled as NonStandardModes). But at the same time, the driver allows as to have a list of restricted modes of 60 elements too. Fortunately for us, both lists are stored consecutive in the same memory area. What I do is to patch the driver so that it doesn't get any restricted mode, and modify the pointers in order to use that memory room for custom modes instead, so I get 60+60 = 120 custom modes. In addition, one can increase this number at the risk of overflowing the original buffers used for these lists. What I've seen is that with Catalyst 6.5 (older cards) this can be done to achieve 200 custom modes, but with newer Catalyst 9.3, we reach a limit before where we start seeing some blue screens, so I keep that number lower. That's why sometimes a write a figure and then another, when I see an issue then I correct it. So, the situation is actually better for older cards (9250 was my test animal). Anyway, if we are able to design a mode list of 120 elements, it could be used safely with any version without overflowing anything.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 19, 2011, 06:53:10 pm
Bitbytebit Hi, I've tried the last 2 versions, with the penultimate followed it all the same, and the latest and everything is ok again, I could post that you have changed? you've changed you or is an official patch in the kernel?

I've seen that having created the partition /data does not create the folder cat, you should force the copy of that folder, and also the /home/arcade/, or at least the new files.

Because you put in the boot .xinitrc file to create mame.xml? it already does advmenu alone, and if the wah!cade, I think you should do only in the installation or configuration, as it loses some time while looking at whether or not you file.

I think it should be omitted gasetup installation option when installed, it could create the same script but without that option, and that whatever it is copied to the hd.

I'm looking to implement wimote to do as a gun, I'm with cwiid etc... when I have something on conditions, I will inform you.

Thank.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 19, 2011, 09:41:27 pm
Bitbytebit Hi, I've tried the last 2 versions, with the penultimate followed it all the same, and the latest and everything is ok again, I could post that you have changed? you've changed you or is an official patch in the kernel?

I've seen that having created the partition /data does not create the folder cat, you should force the copy of that folder, and also the /home/arcade/, or at least the new files.

Because you put in the boot .xinitrc file to create mame.xml? it already does advmenu alone, and if the wah!cade, I think you should do only in the installation or configuration, as it loses some time while looking at whether or not you file.

I think it should be omitted gasetup installation option when installed, it could create the same script but without that option, and that whatever it is copied to the hd.

I'm looking to implement wimote to do as a gun, I'm with cwiid etc... when I have something on conditions, I will inform you.

Thank.

I patched the kernel, or reversed the change they made that broke things.  Bug report I just filed for it, now that we've got testing results :), is here...

https://bugzilla.kernel.org/show_bug.cgi?id=29502

Yeah I need to do that for /data, I thought it was but I guess it's for some reason not working.  I guess moving that into /home/arcade might be good too.

The mame.xml file I'm trying to create on setup, but I think my method is only doing it when you choose a frontend and I should do it also during install too in case setup wasn't used to change the front end. (if you pick a different frontend, like wahcade, it should be done, or fvwm.  I tried to make it so when it does create it on startup, it at least shows the message now of what it's doing, but sounds good to go ahead and do it during install too and save startup time.

I'll have to look at how to exclude things in the gasetup method after install, seems possible since it's just a shell script, need to look at the menu system I'm using and how to exclude entries like that.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 20, 2011, 06:31:59 pm
Hello bitbytebit,I've seen how it works emulation of the wiimote, I tried cwii and it works, what happens to me is something I will stumble, do not know if it will be for the sensor bar or bluetooth, I have to do more tests, especially in win to see if my problem devices or not, but with this you get serious enough as it recognizes and gun mame nintendo wii.


Mame.ini
Code: [Select]
ligthgun 1

To find the mac wiimote.

Code: [Select]
lswm
This step is not necessary, but explains it is confirmed to use two remotes.


To recognize and use the wiimote to the sensor bar "IR".

Code: [Select]
wminput -d -c ir_ptr MAC
I think we can put a second MAC to play two players, but to be confirmed.


With this simple configuration and recognizes the wiimote mame
and treats it like a gun.


Thank
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 20, 2011, 08:41:08 pm
Hello bitbytebit,I've seen how it works emulation of the wiimote, I tried cwii and it works, what happens to me is something I will stumble, do not know if it will be for the sensor bar or bluetooth, I have to do more tests, especially in win to see if my problem devices or not, but with this you get serious enough as it recognizes and gun mame nintendo wii.


Mame.ini
Code: [Select]
ligthgun 1

To find the mac wiimote.

Code: [Select]
lswm
This step is not necessary, but explains it is confirmed to use two remotes.


To recognize and use the wiimote to the sensor bar "IR".

Code: [Select]
wminput -d -c ir_ptr MAC
I think we can put a second MAC to play two players, but to be confirmed.


With this simple configuration and recognizes the wiimote mame
and treats it like a gun.


Thank

This sounds interesting, definitely would be cool to be able to use the wii remote as a light gun :).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: quazl on February 21, 2011, 09:00:03 am
Well, good news!

Specs:

Motherboard:     G31M-ES2L FC
GPU:                 AVGA HD2400

Worked like a charm. Tested all the built in games and they were all performing perfectly. I only tested the 32bit, going to try 64bit tonight.

The problems that I had were in trying to get the disc to be installed. My parents visited this weekend, so I was only able to give it about an hour of my time.

My future setup will be a 2 partition NTFS drive that has windows on the first and Hyperspin setup and ROM, snaps, vids, and etc on the 2nd. There will be second hard drive (either SATA or USB drive with the Linux partition)

My questions (and I need to look through the thread again as I think that it was answered already) are "

Can this Live CD see NTFS?
What is the Home Directory?

It would not let me install the disk because it was in conflict with either the Rom directory or home directory. i Tried a few things but was unsuccessful. I will have more time tonight though.

As for display functionality, it was flawless.

I see that you have a D9800 as well. The resolution that is being used by the driving game (can not remember it now), Does it fit on your screen. I have reduced my horizontal dimensions and still can not get it to fit. I am sure there are manual adjustments by pots in the back. Just wondering if yours fits.

And great work by the way. Once I get the thing installed, I will get all the logs that you want and do whatever testing that you would like.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 21, 2011, 09:14:52 am
Well, good news!

Specs:

Motherboard:     G31M-ES2L FC
GPU:                 AVGA HD2400

Worked like a charm. Tested all the built in games and they were all performing perfectly. I only tested the 32bit, going to try 64bit tonight.

The problems that I had were in trying to get the disc to be installed. My parents visited this weekend, so I was only able to give it about an hour of my time.

My future setup will be a 2 partition NTFS drive that has windows on the first and Hyperspin setup and ROM, snaps, vids, and etc on the 2nd. There will be second hard drive (either SATA or USB drive with the Linux partition)

My questions (and I need to look through the thread again as I think that it was answered already) are "

Can this Live CD see NTFS?
What is the Home Directory?

It would not let me install the disk because it was in conflict with either the Rom directory or home directory. i Tried a few things but was unsuccessful. I will have more time tonight though.

As for display functionality, it was flawless.

I see that have a D9800 as well. The resolution that is being used by the driving game (can not remember it now), Does it fit on your screen. I have reduced my horizontal dimensions and still can not get it to fit. I am sure there are manual adjustments by pots in the back. Just wondering if yours fits.

And great work by the way. Once I get the thing installed, I will get all the logs that you want and do whatever testing that you would like.

It can see NTFS, read only support, and can be setup through either the webmin (port 80) http interface or can be specified as the 'data' or Roms/Snap partition too. 

The 'home' directory is really just useful if you want to reboot into the liveCD and save your setup each time.  It uses a drive basically mounted as /home/arcade/  (can't be the installation drive, might as well just not use a home directory if installing).

The Roms/Snap directory is mounted as /data/ and again it doesn't have to be a separate drive, but of course if your using an NTFS partition for that then you'll need to specify it (or mount it through webmin, with the liveCD each boot you'll have to use webmin to mount it again for the moment since webmin changes won't be saved with the liveCD reboots).

Yeah I use a d9800, there are some games that look like the are bordered and either Mame is wrong with the resolution, or it changes resolution (usually in this case they are bigger than the screen) and possibly the original arcade monitor was adjusted and stretched wider.  That at least are my theories currently, and Calamity might have more detailed ideas on that too.

Actually the only adjustments on my d9800 I have touched are the OSD ones, I'm not sure about the back pots, I figured they were probably a bad thing to adjust but not 100% sure :). 

Sounds really good that it works with that AVGA card, I was afraid I'd have to do the same tricks with it as the AVGA 3000 card, fortunately not.  Good deal it is working well there too, nice to see the same results I've seen here locally with it, definitely the biggest goal of all this is to get those out to others since I saw some pretty big potential using Linux with the right setup and newest kernel/Xorg stuff.

I definitely need to make the whole /home/arcade /data drive setup more clear, haven't figured a simple way to do that without allowing the complex methods of using separate partitions for / and /data/ and /home/arcade which allows for both stateful liveCD booting and separate USB/drive Rom/Snap locations. 

Thanks for testing and reporting the results, will be interested in more tests installing and any bugs that could be squashed or other things that could be made easier.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 21, 2011, 09:41:14 am
Hi bit, I was missing these steps too.

Code: [Select]
modprobe udev
modprobe uinput

chmod 666 /dev/uinput

If the command does not work, it would have to edit the file.
/etc/cwiid/wminput/ir_ptd and change this.

Code: [Select]
Plugin.ir_ptr.X = ~ABS_X
Plugin.ir_ptr.Y = ~ABS_Y

To

Code: [Select]
Plugin.ir_ptr.X = ABS_X
Plugin.ir_ptr.Y = ABS_Y


I tried to pass two wminput Mac to see if you recognize and can play two, but does not work, not whether it will do with two bluetooth, I have to prove it.

Look at this screen, mame recognizes the wiimote as a pistol.

(http://img517.imageshack.us/img517/1817/sinnombrex.jpg) (http://img517.imageshack.us/i/sinnombrex.jpg/)

Could you include in your next version Cwiid to see how it works in gentoo? I tried to install it but I is compiling the kernel and many more things that should not, all tests are conducted in ubuntu 10.10.


Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 22, 2011, 04:54:03 pm

Could you include in your next version Cwiid to see how it works in gentoo? I tried to install it but I is compiling the kernel and many more things that should not, all tests are conducted in ubuntu 10.10.


Thanks.

Sounds like it's one of those ebuilds that calls the kernel download.  I'll have to look into how it compiles on gentoo and work on getting it working there.  Looks really cool, very interesting.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 23, 2011, 09:17:39 am
Hi, bit, is that the evidence as you can see I recognize the wiimote, but itis likejoystick , and not as shirts , somita stays on the screen when you go from one place to another and not very accurate , I found this site where a demon has to start the wiimote, you can use the two and a patch for mame, I understood that is used as a gun, but I've compiled this version of mame and I have not worked, I only work as ordinary control rather than gun, or at least in Terminator 2 and Operation Wolf.

If you can and want to try it and see how you are doing to you.


http://spritesmods.com/?art=wiimote-mamegun (http://spritesmods.com/?art=wiimote-mamegun)


Config Xorg.

Code: [Select]
Section "InputDevice"
Identifier "WiiMote0"
Driver "evdev"
Option "Device" "/dev/input/event4"
Option "SendCoreEvents" "True"
EndSection

Section "InputDevice"
Identifier "WiiMote1"
Driver "evdev"
Option "Device" "/dev/input/event5"
Option "SendCoreEvents" "True"
EndSection


Section "ServerLayout"
  Identifier    "Default Layout"
  Screen        "Default Screen"
  InputDevice    "WiiMote0"
  InputDevice    "WiiMote1"
EndSection

This configuration you have to check evtest the event to see which have the Wii Remote, mine are the last two 8 and 9.

Config Mame.

Code: [Select]
lightgun_index1           auto
lightgun_index2           auto

lightgun_index1           WiiMote0
lightgun_index2           WiiMote1

joystick                  0
lightgun                  1

lightgun_device           lightgun
mouse_device            lightgun

Patch 0.137

http://spritesmods.com/wiimote-mamegun/mame-0137-wiimote.diff (http://spritesmods.com/wiimote-mamegun/mame-0137-wiimote.diff)

Init.d Scripts

Code: [Select]
#! /bin/sh
### BEGIN INIT INFO
# Provides:          wiimote
# Required-Start:    bluetooth
# Required-Stop:    
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: WiiMote startup script
# Description:       Starts two instances of wminput for two different wiimotes
### END INIT INFO

# Author: Sprite_tm

#Bluetooth addresses of the wiimotes. Find this out by using the lswm program.
#You can put these two lines in /etc/default/wminput too if you want.
WM_BDADDR1="00:1F:12:34:56:78"
WM_BDADDR2="00:1F:87:65:43:21"

PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="WiiMote userspace driver"
NAME=wminput
DAEMON=/usr/bin/wminput
DAEMON_ARGS="--options args"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
$DAEMON -d -c /etc/cwiid/wminput/default $WM_BDADDR1 >/dev/null 2>/dev/null &
#Try not to race between the two controllers
sleep 1
$DAEMON -d -c /etc/cwiid/wminput/default.2 $WM_BDADDR2 >/dev/null 2>/dev/null &
}

#
# Function that stops the daemon/service
#
do_stop()
{
#Evil but works....
killall wminput
}


case "$1" in
  start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
  stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
  restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
do_start
;;
  *)
#echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
echo "Usage: $SCRIPTNAME {start|stop|restart}" >&2
exit 3
;;
esac


Here you have to change the WM_BDADDR  by using lswm yours for the mac.

Configuration files for cwiid
http://spritesmods.com/wiimote-mamegun/wminput-config.tgz (http://spritesmods.com/wiimote-mamegun/wminput-config.tgz)


I'll try to ask the author I am doing wrong so I just run as command and not as a pot and see if you can adapt the patch to the latest version.


Hey the thing this stop lately, you're up to? have something new to say?

Thank.


Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 23, 2011, 10:39:40 pm


Hey the thing this stop lately, you're up to? have something new to say?

Thank.




I've been exploring/working on creating a mame build that has switchres built into it, also haven't felt great today too so that's been a slow down :/.  I've got a Linux version of mame, patches, that no longer need switchres and it's built in.  Also today have been pushing the Windows side of things into mame so it can alter the modelines from mame itself.  Also exploring Powerstrip to use that when it's not a Radeon, that's a bit further away.  Hopefully in a few days I might have patches which make mame fully do the switchres stuff, in Windows and Linux, without an external program.

These are the Linux patches, the build there doesn't do anything and is a Windows test so ignore that unless just wanting to see modeline generation work in Windows without it changing anything.

The Windows part of this has been quite crazy, I've been converting the registry editing code to actually compile in mingw for mame, no more cygwin kludges.  I'm close I think, although having some issues getting the modes and details out of the registry, a lot of big TCHAR conversion needed from the char* stuff I was using in cygwin.

This new version of mame has new options, in Linux these patches should make it work just the same as switchres, few things different and not as complex in the advanced options but it's all there mostly...

New Options:
Quote
# CORE SwitchRes OPTIONS
#
-modeline            Generate modelines for arcade monitors
-monitor             Monitor type (cga|generic|h9110|vga|d9200|d9800|ntsc|pal)
-monitor_connector   Video card output (VGA-0|VGA-1|DVI-0|DVI-1)
-monitor_orientation Monitor orientation (horizontal|vertical|rotate)
-monitor_aspect      Monitor aspect (4:3|3:3|3:4|16:9)
-monitor_debug       Monitor debugging

http://mario.groovy.org/GroovyMame/ (http://mario.groovy.org/GroovyMame/)   (Warning: patches aren't even alpha quality on Windows yet, probably will crash when reading the registry values,  Linux should work fine :-) report bugs )

That's mostly what I've been up to, and excited about getting the wii remote working eventually, but right now focusing on the mame switchres patching and waiting for the next version of Mame most likely before another ISO with the couple fixes from the last week I've done.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: rjpe on February 24, 2011, 04:05:23 am
Hi,

please look at this topic: http://forum.arcadecontrols.com/index.php?topic=109962.0 (http://forum.arcadecontrols.com/index.php?topic=109962.0)
will your distro solve my problem?
I'm trying to fit all native resolutions in full screen on my scart tv.
It looks like advanceMAME had a workarround.

Txs
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 24, 2011, 04:20:11 am
The Windows part of this has been quite crazy, I've been converting the registry editing code to actually compile in mingw for mame, no more cygwin kludges.  I'm close I think, although having some issues getting the modes and details out of the registry, a lot of big TCHAR conversion needed from the char* stuff I was using in cygwin.

Great to hear that, thanks for your work.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 24, 2011, 07:20:11 am
Hi,

please look at this topic: http://forum.arcadecontrols.com/index.php?topic=109962.0 (http://forum.arcadecontrols.com/index.php?topic=109962.0)
will your distro solve my problem?
I'm trying to fit all native resolutions in full screen on my scart tv.
It looks like advanceMAME had a workarround.

Txs

Yeah that's the basic goal, right now in Windows you need a radeon card that works with soft15khz and possibly the patched ATI driver allowing a lot more modelines, and create a table of possible resolutions for it to switch to and alter the refresh rate dynamically.  Closest right now we can get to directly writing the card registers like AdvanceMame did to really create modelines dynamically (unfortunately newer radeon cards and others are off limits to advancemames techniques). In the future I'm hoping to get this directly built into mame for Windows, have done this for Linux, so no external program is needed to do the work or be a wrapper for mame.  This is very early though even with the Linux version, just this week have gotten a basic working model, hopefully it'll allow more cards to work using powerstrip and other newer Windows systems that way (right now limited to what Sof15khz supports for Radeon cards and Windows versions).  The Linux version though is so far ahead of the curve here, see below.

Right now in Linux we do have the exact same functionality as advancemame because there we are able to fully create modelines exactly to the games requirements depending on the monitor, no tricky register access or registry fiddling or limited resolution tables at all.  The distribution I built basically is the only one you'll be able to use this functionality with though because  on top of kernel patches, and specific ways of setting it up, the newest kernels are needed and so I've done all that work for you basically on the LiveCD and it also can install to disk too.

  
Also note that advancemame might have been doing some work at fiddling with the modelines to stretch them out like setting the monitor pots for each resolution basically, but doing it with resolution tricks changing the values in the modeline around.  A few games were basically smaller than the screens, or certain screen sizes were used I guess possibly, and the arcade person would adjust it to get it full, and each game somewhat requires slightly different adjustments possibly.  So running all the games on one setup/monitor is going to run into that issue slightly, and that's probably the advancemame setup of tuning resolutions and possibly some tricks with the card registers to do it the best.

Also there's overscan, which needs more of an adjustment on the TV itself in the maintenence menu which is either usually a hidden OSD or inside the TV itself and dangerous to access.  There are some settings in Linux for overscan with xrandr and certain video card outputs, although I'm not sure if it'll work for your setup and I haven't really gotten to play around with that any since I don't have a TV setup that it would work on.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: rjpe on February 24, 2011, 08:52:00 am
Great! I'll try your distro this weekend on a SSD disk I have laying arround.
Right now I have 3 AGP ATI radeon cards (2x9250, 1 HD3560)
I also have an ArcadeVGA version 2 (AGP version).

Wich one would be the best to use?

Do you support ArcadeVGA v2 AGP in both 32 and 64 bit version?
(It would be nice to see the bios booting on the TV)
And the others, both 32/64?

At this moment I'm using an AMD Sempron 64bit, running XP64, Soft15Khz and HD3560.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 24, 2011, 09:03:23 am
Great! I'll try your distro this weekend on a SSD disk I have laying arround.
Right now I have 3 AGP ATI radeon cards (2x9250, 1 HD3560)
I also have an ArcadeVGA version 2 (AGP version).

Wich one would be the best to use?

Do you support ArcadeVGA v2 AGP in both 32 and 64 bit version?
(It would be nice to see the bios booting on the TV)
And the others, both 32/64?

At this moment I'm using an AMD Sempron 64bit, running XP64, Soft15Khz and HD3560.


It should support any of those cards equally, I think the ArcadeVGA one would be fine in 32 or 64 bit (both versions are equal).  Interested in seeing how any/all the cards work, The 9250 cards are well tested but I'm not sure anyone has tested the HD3560 card yet.  Any issues with certain cards I can usually get worked out with the AMD Linux driver developer and he's pretty good at fixing all the issues we've run into yet :).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 24, 2011, 09:21:56 am
Hi bit, this property constituting switchres in mame, but now I had become accustomed to using an external program to suck, and as you said is better than be independent, because we depend on mame, as we could go just as with advmame , to change all the code and did not work, it would have to completely rewrite again, if you feel like you;)
That will give us advantages that is included in mame? being outside could stop working if the code change as well in mame?

I have not done anything about the gun in mame, but when you hear from the I will tell you.

Thanks for all your work.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 24, 2011, 09:40:03 am
Hi bit, this property constituting switchres in mame, but now I had become accustomed to using an external program to suck, and as you said is better than be independent, because we depend on mame, as we could go just as with advmame , to change all the code and did not work, it would have to completely rewrite again, if you feel like you;)
That will give us advantages that is included in mame? being outside could stop working if the code change as well in mame?

I have not done anything about the gun in mame, but when you hear from the I will tell you.

Thanks for all your work.

It's actually quite interesting how it seems to be fitting into mame.  There's actually little change to the mame code, just calling the functions I have in switchres files but all separated from the main mame files.  So that way, it's minimal to keep up with mame, since the places I've fitted it won't ever really change and if so it'll just be changing the machine class/structure call slightly (and all around the places are similar calls so it'll be easy to know what to do).  The Linux side was easy really because nothing much changed besides rewriting how I call the basic switchres modeline functions and monitor selection, and it's all in a separate file still.  In Windows the issue I'm right now dealing with is reading values of the actual modeline data from the registry, which now I'm having to change the data types and it seems to be somewhat close but something is still just not reading the values properly.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Gray_Area on February 24, 2011, 02:36:39 pm
You're really cooking now bitbytebit. Well done.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 24, 2011, 02:41:34 pm
It should support any of those cards equally, I think the ArcadeVGA one would be fine in 32 or 64 bit (both versions are equal).  Interested in seeing how any/all the cards work, The 9250 cards are well tested but I'm not sure anyone has tested the HD3560 card yet.  Any issues with certain cards I can usually get worked out with the AMD Linux driver developer and he's pretty good at fixing all the issues we've run into yet :).

Those HD3560 are known to only accept dotclocks higher than 7 MHz with Window drivers, it will be good to check if Linux can do better with them, and if it's a software issue after all.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 24, 2011, 07:04:13 pm
Hi I got it, I've been able to use wiimote as a gun in mame no problems, must be used as a joystick, no need to patch any, as I suck above and acknowledges, the key to not stand in the middle the display is changed.

joystick_deadzone 0.3

by

joystick_deadzone 0

Tomorrow I explain a little more to do, I need to prove the reload shots when shooting off the screen.

Confirmed reload shots works perfect .
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: quazl on February 25, 2011, 03:07:43 pm
Very Exciting. I wish I could code. I wish could actually contribute to this community that I love so much.

Making switchres work within Mame on windows is great news. Would I need to have a normal ATI card or will this work with an AVGA card? I am going to test your mamebuild this weekend on Windows (and Linux if I can figure it out) as well as the 64 bit Linux that I haven't gotten around to yet. I have had hardware die at work. 70 hours already this week.

Anyways, hope you get to feeling better, bit :)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 25, 2011, 05:15:46 pm
Very Exciting. I wish I could code. I wish could actually contribute to this community that I love so much.

Making switchres work within Mame on windows is great news. Would I need to have a normal ATI card or will this work with an AVGA card? I am going to test your mamebuild this weekend on Windows (and Linux if I can figure it out) as well as the 64 bit Linux that I haven't gotten around to yet. I have had hardware die at work. 70 hours already this week.

Anyways, hope you get to feeling better, bit :)

In windows a normal ATI card or possibly older AVGA cards I think, since the Soft15khz and newer AVGA 3000 do not play together and you can't set ATi custom registry modelines with those cards.  In Linux of course any ATI card just about except possibly newer HD6xxx ones. 

Yeah the GroovyMame version is looking good, might be working now, Calamity is double checking but I think it's no longer needed switchres in Windows and might just do something.  I would recommend using my Windows builds in the GroovyMame directory now, because there's some other bugs I fixed in the patch and even if not using the modeline functionality it's find to just not enable that (disabled by default) and use switchres instead.  I should have more information on the /GroovyMame/ directory on how to use it, working on that side of things partly now, and hopefully all the command option settings are being done right when in switchres mode.

I'm feeling a little better today, dang cold got me, at least my head feels mostly better and I think in a day or two it'll be fully cleared up. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 25, 2011, 06:36:12 pm
I confirm the new GroovyMame for Win is working fine here, calculating and updating the modelines on the fly, so this is actually the first Mame binary since AdvanceMame v0.106 capable of doing modelines.

Hopefully tomorrow I'll upload a new version of VMMaker that automatically creates a mode table suitable for GroovyMame to work as good as in Linux.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 26, 2011, 06:29:10 am
Hello, already running from ubuntu, I need gentoo, you could include cwiid for the next version? order to have the wiimote working as gun we need the following.

Uinput support in kernel.

Code: [Select]
chmod 666 /dev/input/uinput
Support for Bluetooth (bluez) and load them from the beginning.

Cwiid (lswm, wminput libcwiid1).

Script init.d wiimote.

Remembers to put the WM_BDADDR1 of your wiimote in the scritps
To know the BDADDR you have it is with lswm

Code: [Select]
#! /bin/sh
### BEGIN INIT INFO
# Provides:          wiimote
# Required-Start:    bluetooth
# Required-Stop:    
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: WiiMote startup script
# Description:       Starts two instances of wminput for two different wiimotes
### END INIT INFO

# Author: Sprite_tm

#Bluetooth addresses of the wiimotes. Find this out by using the lswm program.
#You can put these two lines in /etc/default/wminput too if you want.
WM_BDADDR1="00:1F:12:34:56:78"
WM_BDADDR2="00:1F:87:65:43:21"

PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="WiiMote userspace driver"
NAME=wminput
DAEMON=/usr/bin/wminput
DAEMON_ARGS="--options args"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
$DAEMON -d -c /etc/cwiid/wminput/default $WM_BDADDR1 >/dev/null 2>/dev/null &
#Try not to race between the two controllers
sleep 1
$DAEMON -d -c /etc/cwiid/wminput/default.2 $WM_BDADDR2 >/dev/null 2>/dev/null &
}

#
# Function that stops the daemon/service
#
do_stop()
{
#Evil but works....
killall wminput
}


case "$1" in
  start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
  stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
  restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
do_start
;;
  *)
#echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
echo "Usage: $SCRIPTNAME {start|stop|restart}" >&2
exit 3
;;
esac


Cwiid set to put two wimote.

You can use these configuration files replacing the original
http://spritesmods.com/wiimote-mamegun/wminput-config.tgz (http://spritesmods.com/wiimote-mamegun/wminput-config.tgz)

or do the following.

Code: [Select]
/etc/cwiid/wminput

rm default

cp ir_ptr ir_ptr.2

ln -s ir_ptr default
ln -s ir_ptr.2 default.2

If the wiimote was not working as going, to change in ir_ptr/ir_ptr.2

Code: [Select]
Plugin.ir_ptr.X = ~ABS_X
Plugin.ir_ptr.Y = ~ABS_Y

To

Code: [Select]
Plugin.ir_ptr.X = ABS_X
Plugin.ir_ptr.Y = ABS_Y

Configuration for mame.

Code: [Select]
joystick 1
joystick_deadzone 0


Now playing ;)


Links with documentation.

http://abstrakraft.org/cwiid/wiki/Gentoo (http://abstrakraft.org/cwiid/wiki/Gentoo)
http://pelican.rsvs.ulaval.ca/mediawiki/index.php/Wiimote_on_Gentoo (http://pelican.rsvs.ulaval.ca/mediawiki/index.php/Wiimote_on_Gentoo)
http://spritesmods.com/?art=wiimote-mamegun (http://spritesmods.com/?art=wiimote-mamegun)
http://www.movimientolibre.com/articulos/cwiid-0.6.00.html (http://www.movimientolibre.com/articulos/cwiid-0.6.00.html)


Thank.


Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 26, 2011, 08:40:53 am
Ves, 

I got my wii remote working :), really cool, quite amazed.  I fortunately had an old bluetooth dongle laying around and a wii.

Here's what I did in the Gentoo Arcade Linux to do it, everything else is not necessary besides these steps in Groovy Arcade Linux, so somewhat simpler since don't need to edit xorg.conf.  The Gentoo overlay doesn't exist, it's merged but requires the kernel source, so I just downloaded the gentoo archive of it and built it manually...
Code: [Select]
# Bluez install
autounmask net-wireless/bluez-4.82
USE=consolekit emerge -av bluez

# Cwiid
cp /usr/portage/app-misc/cwiid/files/60-cwiid.rules /etc/udev/rules.d/
wget http://dev.gentoo.org/~lxnay/cwiid/cwiid-20110107.tar.bz2
# unpack and enter directory
sed -i "s:--disable-ldconfig:--without-ldconfig:g" configure.ac
sed -i "s:enable_ldconfig:with_ldconfig:g" configure.ac
autolocal
autoconf
./configure --prefix=/usr --sysconfdir=/etc

make install

cd /usr/etc/cwiid/wminput/
rm default
cp ir_ptr ir_ptr.2
ln -s ir_ptr.2 default
wminput -d -c /usr/etc/cwiid/wminput/default 00:24:1E:A3:08:2D &


So I've got it working, but I have a problem.  I have to stand way to the left side of my cabinet to get the mouse cursor to work :-).  So how do I tune it to the screen like you do on the Wii?

Looks really exciting, and I've got the nintendo old style controller attachment, so the NES emulator should be fun now :D, thanks for figuring all this out.  It should be pretty easy to make the installation contain the above changes, and will have to look at how to have some sort of setup for it in the menu system I guess (do we really need the MAC if only using one remote?).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 26, 2011, 10:03:14 am
Ves,  

I got my wii remote working :), really cool, quite amazed.  I fortunately had an old bluetooth dongle laying around and a wii.

Here's what I did in the Gentoo Arcade Linux to do it, everything else is not necessary besides these steps in Groovy Arcade Linux, so somewhat simpler since don't need to edit xorg.conf.  The Gentoo overlay doesn't exist, it's merged but requires the kernel source, so I just downloaded the gentoo archive of it and built it manually...
Code: [Select]
# Bluez install
autounmask net-wireless/bluez-4.82
USE=consolekit emerge -av bluez

# Cwiid
cp /usr/portage/app-misc/cwiid/files/60-cwiid.rules /etc/udev/rules.d/
wget http://dev.gentoo.org/~lxnay/cwiid/cwiid-20110107.tar.bz2
# unpack and enter directory
sed -i "s:--disable-ldconfig:--without-ldconfig:g" configure.ac
sed -i "s:enable_ldconfig:with_ldconfig:g" configure.ac
autolocal
autoconf
./configure --prefix=/usr --sysconfdir=/etc

make install

cd /usr/etc/cwiid/wminput/
rm default
cp ir_ptr ir_ptr.2
ln -s ir_ptr.2 default
wminput -d -c /usr/etc/cwiid/wminput/default 00:24:1E:A3:08:2D &


So I've got it working, but I have a problem.  I have to stand way to the left side of my cabinet to get the mouse cursor to work :-).  So how do I tune it to the screen like you do on the Wii?

Looks really exciting, and I've got the nintendo old style controller attachment, so the NES emulator should be fun now :D, thanks for figuring all this out.  It should be pretty easy to make the installation contain the above changes, and will have to look at how to have some sort of setup for it in the menu system I guess (do we really need the MAC if only using one remote?).


Hello, regarding to stay on the left side because the wiimote is not, you are using the sensor bar for wii? you got the right direction? have proven this right on the wii? I guess I'll be stoked with the wii sensor bar, if it is original, and if it is battery or USB, no? mame.ini off the mouse on, if you can upload some photos to see what is wrong, that will happen only in arcade and also on your pc?

With regard to the steps, I find autolocal, correct? does not come out to emerge.

I'm testing with a virtual machine if it works go to the arcade to see if it works well.

I have installed Bluez, and then I dropped the code of web cwiid I libcwiid/bluetooth.c changing  this “hci_remote_name” to “hci_read_remote_name”  file and let me compile it and install it, but I get error ImportError: No module named cwiid, I need to prove your steps from zero.


The Mac is set for not having to synchronize the remote always, you pass the PARAMETER to wminput this expecting to see the command, not a new one, once you press the buttons 1 +2 is activated and ready.

Have you tried to change this in ir_ptr?

Plugin.ir_ptr.X = ~ABS_X
Plugin.ir_ptr.Y = ~ABS_Y

To

Plugin.ir_ptr.X = ABS_X
Plugin.ir_ptr.Y = ABS_Y

You can put the configuration files you have in /etc/cwiid/wminput/ ?


Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 26, 2011, 10:16:26 am
Ves,  

I got my wii remote working :), really cool, quite amazed.  I fortunately had an old bluetooth dongle laying around and a wii.

Here's what I did in the Gentoo Arcade Linux to do it, everything else is not necessary besides these steps in Groovy Arcade Linux, so somewhat simpler since don't need to edit xorg.conf.  The Gentoo overlay doesn't exist, it's merged but requires the kernel source, so I just downloaded the gentoo archive of it and built it manually...
Code: [Select]
# Bluez install
autounmask net-wireless/bluez-4.82
USE=consolekit emerge -av bluez

# Cwiid
cp /usr/portage/app-misc/cwiid/files/60-cwiid.rules /etc/udev/rules.d/
wget http://dev.gentoo.org/~lxnay/cwiid/cwiid-20110107.tar.bz2
# unpack and enter directory
sed -i "s:--disable-ldconfig:--without-ldconfig:g" configure.ac
sed -i "s:enable_ldconfig:with_ldconfig:g" configure.ac
autolocal
autoconf
./configure --prefix=/usr --sysconfdir=/etc

make install

cd /usr/etc/cwiid/wminput/
rm default
cp ir_ptr ir_ptr.2
ln -s ir_ptr.2 default
wminput -d -c /usr/etc/cwiid/wminput/default 00:24:1E:A3:08:2D &


So I've got it working, but I have a problem.  I have to stand way to the left side of my cabinet to get the mouse cursor to work :-).  So how do I tune it to the screen like you do on the Wii?

Looks really exciting, and I've got the nintendo old style controller attachment, so the NES emulator should be fun now :D, thanks for figuring all this out.  It should be pretty easy to make the installation contain the above changes, and will have to look at how to have some sort of setup for it in the menu system I guess (do we really need the MAC if only using one remote?).


Hello, regarding to stay on the left side because the wiimote is not, you are using the sensor bar for wii? you got the right direction? have proven this right on the wii? I guess I'll be stoked with the wii sensor bar, if it is original, and if it is battery or USB, no? mame.ini off the mouse on, if you can upload some photos to see what is wrong, that will happen only in arcade and also on your pc?

With regard to the steps, I find autolocal, correct? does not come out to emerge.

I'm testing with a virtual machine if it works go to the arcade to see if it works well.

I have installed Bluez, and then I dropped the code of web cwiid I libcwiid/bluetooth.c changing  this “hci_remote_name” to “hci_read_remote_name”  file and let me compile it and install it, but I get error ImportError: No module named cwiid, I need to prove your steps from zero.


The Mac is set for not having to synchronize the remote always, you pass the PARAMETER to wminput this expecting to see the command, not a new one, once you press the buttons 1 +2 is activated and ready.

Have you tried to change this in ir_ptr?

Plugin.ir_ptr.X = ~ABS_X
Plugin.ir_ptr.Y = ~ABS_Y

To

Plugin.ir_ptr.X = ABS_X
Plugin.ir_ptr.Y = ABS_Y

You can put the configuration files you have in /etc/cwiid/wminput/ ?


Thanks.


I'm just using a bluetooth dongle, not sure about how the original wii sensor would work.  The controllers work with the wii fine.  I have to stand with my hand out to the right and the controller sort of sideways for it to work.  All the buttons work fine and the config ir_ptr stuff I changed and it goes the right directions, just seems to not allow me to point directly but have to be out to the right.  At first it was needing to have me also stand to the far left, now I can stand directly in front, also my usb bluetooth adaptor is on the right side of the screen at the lower corner (everything else seems worse).  My screen is slanted, it's a PGA Golf Tour cabinet, 27" WG9800, not sure if that changes things, does the screen have to be straight up/down for it to work best?  I can play duckhunt ok, but of course it's real flaky and having my hand out to the right side makes it weird, no direct pointing works. 

Yeah the default version of cwiid doesn't compile, but the one I have the link for above does, Gentoo must have grabbed a better build and it's a bit newer than the current stable version I think.  I'm not sure if perhaps part of the issue would be the version, but for some reason the 0.6.00 one has issues I guess like you saw with Gentoo too. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 26, 2011, 10:26:00 am
Hello,  if you do not use the wii sensor bar, it will not have to work well, I say this because I tried many things and will not work if you do not.
If you do not have the sensor bar, you can try with 2 sails, no kidding, you can look and see.


With respect to command autolocal, is well given, or is a bug and wanted to give another command? I have not found this command to emerge, apt-get or the web.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 26, 2011, 10:30:46 am
Hello,  if you do not use the wii sensor bar, it will not have to work well, I say this because I tried many things and will not work if you do not.
If you do not have the sensor bar, you can try with 2 sails, no kidding, you can look and see.


With respect to command autolocal, is well given, or is a bug and wanted to give another command? I have not found this command to emerge, apt-get or the web.

Ah, it's aclocal :) I mistyped that.

Oh, how does the wii sensor bar plugin, it isn't USB is it?  Yeah that makes sense how, didn't realize it needed that.  Are you saying two usb bluetooth devices will be better?  I do have two of these, interesting.  Would be interested in getting the wii sensor bar hooked up but seems like it has some strange plug on it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 26, 2011, 10:41:37 am
Hello, wii sensor bar need not be connected to the pc, only to pick up the signal better command and return to Him, to know which part is when I said usb was not to connect to the pc, but that has Power supply, either with USB or batteries.

Only need 1 bluetooth to use the 2 wiimote.

Thanks for the howto so that it can install, just install the virtual machine, but when I run vminput fails.

ImportError: /usr/lib/python2.6/site-packages/cwiid.so undefined symblo: cwiid_get_balance_cal.

I guess its gonna be cwiid trying to install several times, in different ways, or you need to install something else in GroovyArcade? I'll do this later in the arcade.

I have to try this, but right now I'm out, if you want to see if it works, edit the files ir_ptr ir_ptr.2 and add this

/etc/cwiid/wminput/ir_ptr
Plugin.led.Led4 = 1

/etc/cwiid/wminput/ir_ptr.2
Plugin.led.Led4 = 2

To see if the controls identified.

It works, but you have to put so

/etc/cwiid/wminput/ir_ptr
Plugin.led.Led1 = 1

/etc/cwiid/wminput/ir_ptr.2
Plugin.led.Led2 = 1

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 26, 2011, 06:28:58 pm
Hi, I've tried cwiid in GroovyArcade, works pretty well, so if it's not like a real gun arcade.
The wiimote script does not work with gentoo, it has to change, will watch tomorrow.

first you said that is not fully focused the Wiimote, right? happened to me a little, but not if cells will be for the sensor bar that are the minimum or the short distance that I have tomorrow proves it better, it's too late, I've also noticed that in several games to make reload gun, returning the pointer on your position, but shifted a bit more ..

I have to do more tests using mouse lightgun options etc. ..

Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 27, 2011, 02:33:13 am
Hi, I've tried cwiid in GroovyArcade, works pretty well, so if it's not like a real gun arcade.
The wiimote script does not work with gentoo, it has to change, will watch tomorrow.

first you said that is not fully focused the Wiimote, right? happened to me a little, but not if cells will be for the sensor bar that are the minimum or the short distance that I have tomorrow proves it better, it's too late, I've also noticed that in several games to make reload gun, returning the pointer on your position, but shifted a bit more ..

I have to do more tests using mouse lightgun options etc. ..

Thanks.

I'm going to get one of these:
http://www.walmart.com/ip/Nyko-Wireless-Sensor-Bar-Wii-Wii/5607973 (http://www.walmart.com/ip/Nyko-Wireless-Sensor-Bar-Wii-Wii/5607973)

Looks like it should do the trick.  Does your nunchuck part work?  Mine doesn't, and my classic controller doesn't work either, they claim they should work.  As a basic mame controller it works well right now, although it's hard to use the normal buttons in games because it also is listening to the movement sensing too so it seems to cause the left/right movements to get triggered constantly.  I'm guessing turning off joystick support in mame ini files for games I don't want the motion to work with, or only turning it on for games with light guns possibly.  I'm guessing the classic controller would be hard to use, if it worked, with the motion sensing also influencing the movement.

Here's a button mapping I made that allows me to use it to navigate through advmenu and games in general:
Code: [Select]
#buttons

Wiimote.A = KEY_LEFTALT
Wiimote.B = KEY_LEFTCTRL
Wiimote.Up = KEY_UP
Wiimote.Down = KEY_DOWN
Wiimote.Left = KEY_LEFT
Wiimote.Right = KEY_RIGHT
Wiimote.Minus = KEY_5
Wiimote.Plus = KEY_6
Wiimote.Home = KEY_ESC
Wiimote.1 = KEY_1
Wiimote.2 = KEY_2

Nunchuk.C = BTN_LEFT
Nunchuk.Z = BTN_RIGHT

Classic.Up = KEY_UP
Classic.Down = KEY_DOWN
Classic.Left = KEY_LEFT
Classic.Right = KEY_RIGHT
Classic.Minus = KEY_BACK
Classic.Plus = KEY_FORWARD
Classic.Home = KEY_HOME
Classic.A = BTN_LEFT
Classic.B = BTN_RIGHT
#Classic.X =
#Classic.Y =
#Classic.ZL =
#Classic.ZR =
#Classic.L =
#Classic.R =

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on February 27, 2011, 06:37:54 am
Hello to use the classic controller, you have to use file  nunchuck_stick2btn and not the ir_ptr, because if you say fails to detect the movement of the wiimote.
I've seen you put cwii gif, but you need to put the ir_ptr.2 and add the option for you to know that this command is running Plugin.led.Led1 = 1 Plugin.led.Led2 = 1

I've had to change the buttons in buttons so that when you put the command in a shot gun trigger is the B and not A.

Wiimote.A               = BTN_LEFT
Wiimote.B               = BTN_RIGHT

To

Wiimote.A               = BTN_RIGHT
Wiimote.B               = BTN_LEFT

I have not been able to prove the gun well, but I think we will have little problems with the calibration of the wiimote, because there is no such option linux: (, and all the projects I see are already dead, just still in windows.
I have to try in windows to confirm.

You could see something to load at startup the wminput?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 27, 2011, 09:00:56 am
Hello to use the classic controller, you have to use file  nunchuck_stick2btn and not the ir_ptr, because if you say fails to detect the movement of the wiimote.
I've seen you put cwii gif, but you need to put the ir_ptr.2 and add the option for you to know that this command is running Plugin.led.Led1 = 1 Plugin.led.Led2 = 1

I've had to change the buttons in buttons so that when you put the command in a shot gun trigger is the B and not A.

Wiimote.A               = BTN_LEFT
Wiimote.B               = BTN_RIGHT

To

Wiimote.A               = BTN_RIGHT
Wiimote.B               = BTN_LEFT

I have not been able to prove the gun well, but I think we will have little problems with the calibration of the wiimote, because there is no such option linux: (, and all the projects I see are already dead, just still in windows.
I have to try in windows to confirm.

You could see something to load at startup the wminput?

I can't believe they wouldn't have a calibration utility like in the wii, that seems like the biggest part of it. 

I got my classic controller working great with mame, here's my updated config with all the buttons mapped out to match mame ones.  works pretty nice, will have to play with trying to calibrate when I get that wireless sensor.
Code: [Select]
#buttons

#Plugin.ir_ptr.X = ABS_X
#Plugin.ir_ptr.Y = ABS_Y

Wiimote.A = KEY_LEFTALT
Wiimote.B = KEY_LEFTCTRL
Wiimote.Up = KEY_UP
Wiimote.Down = KEY_DOWN
Wiimote.Left = KEY_LEFT
Wiimote.Right = KEY_RIGHT
Wiimote.Minus = KEY_5
Wiimote.Plus = KEY_6
Wiimote.Home = KEY_ESC
Wiimote.1 = KEY_1
Wiimote.2 = KEY_2

Nunchuk.C = BTN_LEFT
Nunchuk.Z = BTN_RIGHT

Classic.Up = KEY_UP
Classic.Down = KEY_DOWN
Classic.Left = KEY_LEFT
Classic.Right = KEY_RIGHT
Classic.Minus = KEY_5
Classic.Plus = KEY_6
Classic.Home = KEY_ESC
Classic.A = KEY_LEFTALT
Classic.B = KEY_LEFTCTRL
Classic.X = KEY_SPACE
Classic.Y = KEY_LEFTSHIFT
Classic.ZL = KEY_1
Classic.ZR = KEY_2
Classic.L = BTN_LEFT
Classic.R = BTN_RIGHT

#Classic.Dpad.X = ABS_X
#Classic.Dpad.Y = ABS_Y
Classic.LStick.X = ABS_HAT0X
Classic.LStick.Y = ABS_HAT0Y
Classic.RStick.X = ABS_HAT1X
Classic.RStick.Y = ABS_HAT1Y

#Nunchuk.C               = KEY_C
#Nunchuk.Z               = KEY_SPACE

#plugin for nunchuk stick
Plugin.nunchuk_stick2btn.Up = KEY_UP
Plugin.nunchuk_stick2btn.Down = KEY_DOWN
Plugin.nunchuk_stick2btn.Left = KEY_LEFT
Plugin.nunchuk_stick2btn.Right = KEY_RIGHT


So we would want this as a player 1 config I guess, and then another for a player 2 config with the right keys mapped there.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 27, 2011, 03:34:57 pm
I've attached a new test version of VMMaker and ArcadeOSD (1.2). This VMMaker version is capable of creating and installing a video mode list suitable for Switchres or Groovymame. By now you'll need to download one of the previous CRT_Emudriver packages (6.5 or 9.3 depending on your Radeon model, download from http://postback.geedorah.com/foros/viewtopic.php?id=1424 (http://postback.geedorah.com/foros/viewtopic.php?id=1424)) and replace the files there with the newer ones attached to this post. Then edit VMMaker.ini to point to your Mame path. The rest of options are already set up for you. I've translated the whole thing into English. Hopefully in some days I'll have the CRT_Emudriver packages updated and the rest of documentation translated.

This VMMaker 1.2 has a new option called ModeTableMethod, that specifies if we're creating a static or dynamic mode table. There's also a new option called VerticalAspect that accounts for the aspect ratio of vertical games and must be set up with the same value we will use in Switchres or GroovyMame.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: quazl on February 27, 2011, 05:48:05 pm
Hey Calamity,

I have the AVGA 2400. I am trying out your drivers. Before I start doing alot of troubleshooting, will this work with my card? I lost video on the VGA side after uninstalling AVGA drivers and trying yours.

By the way, Arcade_OSD is amazing! Great job on that tool!
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 27, 2011, 05:55:05 pm
I'm afraid that AVGA model is not tested and probably won't work, I've only tested it with 9250 based models. However, just out of curiosity, you mean you have no video at all or only on the vga connector?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: quazl on February 27, 2011, 06:34:02 pm
I have video on the dvi but not on the VGA to my d9800.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 28, 2011, 04:20:35 am
I have video on the dvi but not on the VGA to my d9800.

Interesting, have you tried to connect your d9800 to the dvi with an adapter or are you connecting a lcd to that one?
For some reason, these drivers only enable output to the primary device (dvi in your case), even if modelines are installed to both of them. VMMaker only installs modelines to the primary device as for now. Something that could be happening is that modelines are not working at all and you are only having picture on the dvi thanks to the monitor built in modes or something. You may try to enable VGA from Screen Properties (extend desktop).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 28, 2011, 04:54:47 am
I have video on the dvi but not on the VGA to my d9800.

Interesting, have you tried to connect your d9800 to the dvi with an adapter or are you connecting a lcd to that one?
For some reason, these drivers only enable output to the primary device (dvi in your case), even if modelines are installed to both of them. VMMaker only installs modelines to the primary device as for now. Something that could be happening is that modelines are not working at all and you are only having picture on the dvi thanks to the monitor built in modes or something. You may try to enable VGA from Screen Properties (extend desktop).

The HD2400 card is the same basic R600 GPU as the HD2600 card which both the AVGA 2400 and AVGA 2600 are based off of these cards.  That being the case, I'm pretty certain they would both be using the same type of method, which is totally different than previous AVGA cards.  So basically I suspect the card is hardwired in the actual video bios to not use the regular VGA port normally, instead it's stuck with a static modetable internally and you can't touch it with drivers without knowing some proprietary methods of talking to it which only the AVGA drivers know.  I know that this card supposidly works with my Linux fix, odd though because I thought the two would require a slightly different fix being different cards and I check the cards device id/manufacturer id before I do the changes for them.  I get the feeling that no regular ATI driver other than AVGA driver would get the 2400 as well as the 3000 working out the VGA port, at least that is what a guy from AMD said the ATI vbios team told him.  The vbios firmware is supposed to be completely different in the pixelclock routines it uses and so normal drivers are just not going to know how to do things right, and there's obviosuly some funny stuff done to the VGA port on top of that.  At least if it really is in the same area as the 3000, I really don't see how it couldn't be since it's the same model GPU basically and makes sense it would be the same vbios type.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on February 28, 2011, 05:10:48 am
The HD2400 card is the same basic R600 GPU as the HD2600 card which both the AVGA 2400 and AVGA 2600 are based off of these cards.  That being the case, I'm pretty certain they would both be using the same type of method, which is totally different than previous AVGA cards.  So basically I suspect the card is hardwired in the actual video bios to not use the regular VGA port normally, instead it's stuck with a static modetable internally and you can't touch it with drivers without knowing some proprietary methods of talking to it which only the AVGA drivers know.  I know that this card supposidly works with my Linux fix, odd though because I thought the two would require a slightly different fix being different cards and I check the cards device id/manufacturer id before I do the changes for them.  I get the feeling that no regular ATI driver other than AVGA driver would get the 2400 as well as the 3000 working out the VGA port, at least that is what a guy from AMD said the ATI vbios team told him.  The vbios firmware is supposed to be completely different in the pixelclock routines it uses and so normal drivers are just not going to know how to do things right, and there's obviosuly some funny stuff done to the VGA port on top of that.  At least if it really is in the same area as the 3000, I really don't see how it couldn't be since it's the same model GPU basically and makes sense it would be the same vbios type.

Yes, I agree bitbytebit here. What surprises me is that the AVGA 2400 was not refused by the driver installation at first hand. Actually, though not documented, my patched drivers (6.5) should install with any AVGA 9200/9250/X600/X1050, but only 9200/9250 have been tested afaik.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: quazl on February 28, 2011, 01:51:05 pm
Going to try the DVI tonight.

Also, found this
http://derrick.mameworld.info/docs/Tutorial/VideoModes/Custom_Video_Modes.html (http://derrick.mameworld.info/docs/Tutorial/VideoModes/Custom_Video_Modes.html)
while purusing the WIP pages. I am sure you have seen this, but I thought I would post just in case it might be applicable.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on February 28, 2011, 09:34:47 pm
Groovy Arcade Linux ISO version 1.495

Quote
         - Mame ebuild updated with groovymame patch to have switchres builtin
         - Added Cwiid and Bluez, allows wii remotes to work as light guns/controllers
         - Updated kernel to 2.6.38-rc6-git4+ now does vblank timestamps in interlaced mode too
         - Mouse setup with xset in xinit and usbhid module set to 512ms polling
         - Improved mouse/trackball sensitivity
         - Really copy /data/ information to installation

To enable a wii remote, for now you'll manually have to run `wminput -d &` at the console or remote through ssh.

Mouse and trackball/spinner handling should be very nice compared to before, or in most other Linux distributions.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: rjpe on March 01, 2011, 06:15:06 am
Hi calamity, does your driver work with Windows XP 64 bit?

bitbytebit, I tried your distro but had some problems. I'll be back to that when I have more time.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 01, 2011, 06:40:27 am
Hi calamity, does your driver work with Windows XP 64 bit?

bitbytebit, I tried your distro but had some problems. I'll be back to that when I have more time.

wtf. i was JUST clicking on the thread to ask the same question. Get out of my head! (:


I tried the driver on my Xp64 cab about 50 minutes ago; did an 'update driver' from the control panel, and it booted into 640x480x4bit and wouldn't change resolution. I wasn't sure if it was an issue with the driver or if I needed to do a full uninstall/reinstall.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: rjpe on March 01, 2011, 06:48:57 am
Yeah, very weird!   :)
BTW, the question about the driver in XP64 is for 9250 (ArcadeVGA2 agp and all the other ATI), the driver based in Catalyst 6.5.
The other one I'm almost sure it will work.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 01, 2011, 07:20:05 am
Hi there, I notice there's a sudden interest for the XP64 thing :) Current support is only for XP32. Being targeted for the arcade context, I thought it would be enough for a decade, but I see many people moving to the 64 bits XP so I'm actually going to try and patch Catalyst 9.3 for XP64. Be aware there's no official support for the 9250 and older Radeon chipsets for XP64, for what I'm seeing in the AMD support site, so this will only support the newer cards (I might be wrong, if someone has better info on this please let me know!).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 01, 2011, 07:26:52 am
Hi calamity, does your driver work with Windows XP 64 bit?

bitbytebit, I tried your distro but had some problems. I'll be back to that when I have more time.

When you have time, tell me everything that went wrong, I actually enjoy the negative feedback best because it always results in lots of improvements and bug fixes :D. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 01, 2011, 08:11:55 am
I tried the driver on my Xp64 cab about 50 minutes ago; did an 'update driver' from the control panel, and it booted into 640x480x4bit and wouldn't change resolution. I wasn't sure if it was an issue with the driver or if I needed to do a full uninstall/reinstall.

I always do a full uninstall/reinstall, and even use Catalyst Uninstaller in the middle, with my fingers crossed. There are MANY problems I've seen here and there that turned out to be produced by drivers not installing properly or just installing partially with no error message from the system. That's unfortunately a dirty area in Windows. This driver should actually not install itself in XP64 if run from its setup, I believe...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 01, 2011, 08:39:10 am
Well I'll look forward to seeing you have a patched up XP64 driver. On my setup I've got a 4350, so its a relatively newer card.

XP64, to me, seems like the ideal OS for a cabinet running an actual arcade monitor; you get the speed boost of 64bit mame along with proper support for Soft15kHz.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: rjpe on March 01, 2011, 08:59:33 am
Hi calamity, does your driver work with Windows XP 64 bit?

bitbytebit, I tried your distro but had some problems. I'll be back to that when I have more time.

When you have time, tell me everything that went wrong, I actually enjoy the negative feedback best because it always results in lots of improvements and bug fixes :D. 

I tried AVGA 9250, and installed the system to a 32GB SSD. I went the hard way, using my scart-tv as the monitor... so I had geometry problems and couldn't see the whole screen. I tried to lauch the free roms, but then the keyboard didn't respond anymore - that happens when the resolutions/sync are not ok. I didn't invest much time (It was late ...). As a first impression, the distro looks very good. I'd not consider the net config mandatory - my cabinet lies on the garage, without internet or network access, I think that I'm not the only one. It is my first Gento Linux experience  :D I stopped investing in Linux when Fedora arrived due to professional changes. I might have installed ubuntu and fedora a couple of times, but that was it! I've to refresh my Linux skills!  ;)

I was using my current cabinet has the ginny pig (using dual boot). I have an old PIV 1.5GHz waiting for some action, I'll use this one as the testing suite machine.
Next weekend I'll be more patient, and start with a computer monitor, then test the TVs.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: rjpe on March 01, 2011, 09:12:02 am
Well I'll look forward to seeing you have a patched up XP64 driver. On my setup I've got a 4350, so its a relatively newer card.

XP64, to me, seems like the ideal OS for a cabinet running an actual arcade monitor; you get the speed boost of 64bit mame along with proper support for Soft15kHz.

You're reading my mind!  ;D
Just kidding - I agree that XP64 + Soft15Khz is great for 64-bit CPU's, mame64 works much better than regular 32-bit. It is a shame that 9250 (and AVGA AGP) doesn't have 64-bit support. I imagine that many members of this forum would LOVE to have a 64-bit driver for any RADEON 9xxx.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 01, 2011, 09:55:58 am
Hi calamity, does your driver work with Windows XP 64 bit?

bitbytebit, I tried your distro but had some problems. I'll be back to that when I have more time.

When you have time, tell me everything that went wrong, I actually enjoy the negative feedback best because it always results in lots of improvements and bug fixes :D. 

I tried AVGA 9250, and installed the system to a 32GB SSD. I went the hard way, using my scart-tv as the monitor... so I had geometry problems and couldn't see the whole screen. I tried to lauch the free roms, but then the keyboard didn't respond anymore - that happens when the resolutions/sync are not ok. I didn't invest much time (It was late ...). As a first impression, the distro looks very good. I'd not consider the net config mandatory - my cabinet lies on the garage, without internet or network access, I think that I'm not the only one. It is my first Gento Linux experience  :D I stopped investing in Linux when Fedora arrived due to professional changes. I might have installed ubuntu and fedora a couple of times, but that was it! I've to refresh my Linux skills!  ;)

I was using my current cabinet has the ginny pig (using dual boot). I have an old PIV 1.5GHz waiting for some action, I'll use this one as the testing suite machine.
Next weekend I'll be more patient, and start with a computer monitor, then test the TVs.


Cool thanks, yeah the scart support with a TV isn't well tested or even tested at all actually.  So suspect there's issues there to be figured out.

Yeah I need to definitely redo some of the menu dependencies, thanks, I'll make the network one non-mandatory and look into some other similar changes there.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: dmarcum99 on March 01, 2011, 08:57:18 pm
I don't know if anyone has looked, but GURU3D has some 64-bit XP drivers that work with the 9200 series. 

I've used them and they're OK.  I can't remember which one worked though....somewhere between the 6.2's and 6.6 CATS.  YMMV  All of these said they work, but I only got one to install....and it wasn't signed.  But I bounced back to 32bit again and I can't remember which version it was.

Maybe CALAMITY can use one of these and make it work for the 64 bit'ers.

I've got both cards....a 9250 and a 4350 so I'm good either way when a CALAMITY'D 64 bit driver surfaces.    :)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 02, 2011, 05:58:58 am
I don't know if anyone has looked, but GURU3D has some 64-bit XP drivers that work with the 9200 series. 

I've used them and they're OK.  I can't remember which one worked though....somewhere between the 6.2's and 6.6 CATS.  YMMV  All of these said they work, but I only got one to install....and it wasn't signed.  But I bounced back to 32bit again and I can't remember which version it was.

Maybe CALAMITY can use one of these and make it work for the 64 bit'ers.

I've got both cards....a 9250 and a 4350 so I'm good either way when a CALAMITY'D 64 bit driver surfaces.    :)

dmarcum99, thanks a lot for pointing that. I've found these ones:

http://downloads.guru3d.com/ATI-Catalyst-6.4-%28x64%29-download-1375.html#download (http://downloads.guru3d.com/ATI-Catalyst-6.4-%28x64%29-download-1375.html#download)
http://downloads.guru3d.com/Catalyst-6.5-Windows-XP-Pro-%2864-bit%29-download-1408.html (http://downloads.guru3d.com/Catalyst-6.5-Windows-XP-Pro-%2864-bit%29-download-1408.html)

The Radeon 9200/9250 are not officially supported but I've read some people have managed to make them work by adding those models to the .inf file, so I think I'll be able to do that too. So there's a chance we can have that for x64, provided the binary patch actually works (have never patched 64bits binaries so this is new to me).

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: rjpe on March 02, 2011, 10:41:19 am
Hi Calamity,

If you need, I can test 3 different RADEON 9250 on XP64 (Asus 128MB, Powercolor 256MB and Arcade VGA 128MB).
Waiting for your developments! :)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 02, 2011, 10:57:18 am
Hi Calamity,

If you need, I can test 3 different RADEON 9250 on XP64 (Asus 128MB, Powercolor 256MB and Arcade VGA 128MB).
Waiting for your developments! :)

That will be great. Testing drivers requires to have a system with the specific hardware/software and sometimes it's hard for a single hobbyist man to have every variant ready for testing. I'll post the links in this thread when I have something done, may take me a while yet anyway.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 03, 2011, 06:26:14 am
I've been tinkering with the newest build with switchres incorporated. I do not have calamity's drivers installed since we're waiting on him to see if he can patch the 64bit drivers, but it should still generate and switch to modes correctly, right?

It still seems to be stretching the image in some instances. Bubble Bobble should run at 256x224. Once it's up and running the screen is set to 256x240, but the image is stretched to fill the extra lines, resulting in some ugly artifacting.

I've deleted and recreated my mame.ini, what setting should I check so it doesn't do this?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 03, 2011, 08:35:37 am
I've been tinkering with the newest build with switchres incorporated. I do not have calamity's drivers installed since we're waiting on him to see if he can patch the 64bit drivers, but it should still generate and switch to modes correctly, right?

It still seems to be stretching the image in some instances. Bubble Bobble should run at 256x224. Once it's up and running the screen is set to 256x240, but the image is stretched to fill the extra lines, resulting in some ugly artifacting.

I've deleted and recreated my mame.ini, what setting should I check so it doesn't do this?

It's a bug that happened in porting the code.  I just fixed it, hopefully really is fixed, but at least from what I can tell it should be.  There were some useless height/width checks that set virtualization to happen, in the old code they were actually thrown away and in the new code I fixed that issue.  Well I guess in the old code the throw them away part was actually good, and so now I removed them completely.

It'll be up in a few minutes as version .004, the patches are updated already.

Thanks for finding that
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 03, 2011, 03:18:13 pm
Very nice. I'll be sure to check it on my cab as soon as I can. I only really have time to tinker with settings early in the morning, between 5:30am and 6:00am, before the family wakes up. Sometimes it's just too early to be motivated (:
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 03, 2011, 04:01:11 pm
Very nice. I'll be sure to check it on my cab as soon as I can. I only really have time to tinker with settings early in the morning, between 5:30am and 6:00am, before the family wakes up. Sometimes it's just too early to be motivated (:

Reading this forum from GMT+1 time zone, messages timestamps are somehow disconcerting, sometimes you wonder if some people have any sleep at all  ;D

This weekend hopefully I'll have some time to install x64 in my cab and try to do some patches to the drivers.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 04, 2011, 12:30:48 am
http://mame.groovy.org/0141u3/ (http://mame.groovy.org/0141u3/)

I've rewritten the cabmame patches completely, no longer really have any extra mame options and they automatically just enable themselves.  You can turn off soundsync though, and this has the separate changes to the hiscore patch from MKChamp that allow it to work with Linux.  Definitely aimed at Arcade Monitors and avoiding need for triplebuffer, utilizing the vsync of the ATI Radeon video cards.  Also the cleanstretch/changeres support should be better now, at least done in a way that seems to do a bit better than previously.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 04, 2011, 05:41:52 am
Looks good so far, with one issue.. When I exit from a game, Hyperspin doesn't seem to notice that it's exited until I've alt-tabbed off and back to it. I'll do more experimenting with it in the next few minutes to see what I can figure out.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 04, 2011, 08:44:51 am
Looks good so far, with one issue.. When I exit from a game, Hyperspin doesn't seem to notice that it's exited until I've alt-tabbed off and back to it. I'll do more experimenting with it in the next few minutes to see what I can figure out.


Odd, might try to double check with using nomodeline in the config file too, and see if it also does the same when the code is disabled basically.  Not sure how it would cause it to do that on exit, might be a slight bit of extra time exiting because of having to reset the registry modeline, although I know that hyperspin does have an odd check at exit that might try and kill off the emulator instead of letting it exit peacefully :). 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 04, 2011, 09:20:43 am
The 'kill off' feature is using Hyperlaunch, I think, which I am not using. I'll try with the modeline option off when I can.

I didn't get a chance to actually play a game with it, but I ran World Class Bowling before shutting it down for the day and it looked like it was having vsync speed issues.. It looked like it was running too fast. I'll follow up on this when I can.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 04, 2011, 09:34:02 am
The 'kill off' feature is using Hyperlaunch, I think, which I am not using. I'll try with the modeline option off when I can.

I didn't get a chance to actually play a game with it, but I ran World Class Bowling before shutting it down for the day and it looked like it was having vsync speed issues.. It looked like it was running too fast. I'll follow up on this when I can.
Yeah might want to try turning off multithreading see if that makes a difference, otherwise vsync issues of course could be the card having issues with vblank working properly.  Also might try recreating the mame.ini to make sure the defaults, which are different, are mostly set right.  Will see how this version works for Calamity too since he has a working Windows setup known to work with previous versions, so can double check to make sure I've gotten everything working still in the latest patches/builds.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 04, 2011, 05:42:34 pm
I've tested the new GroovyMame and it's working perfectly here when launching it from AdvanceMenu. I have created a new mame.ini for testing. The new soundsync option is working great too, now it needs to be enabled from mame.ini.

There is a problem with games that switch their resolution, like Golden Axe II, for some reason the resolution switch fails and I have to shut the program from the taskbar. This already happened in the previous version, so it seems there is a bug with the changeres and ddraw combination, I'll keep testing.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 04, 2011, 05:52:49 pm
I've tested the new GroovyMame and it's working perfectly here when launching it from AdvanceMenu. I have created a new mame.ini for testing. The new soundsync option is working great too, now it needs to be enabled from mame.ini.

There is a problem with games that switch their resolution, like Golden Axe II, for some reason the resolution switch fails and I have to shut the program from the taskbar. This already happened in the previous version, so it seems there is a bug with the changeres and ddraw combination, I'll keep testing.



Yeah I've wondered about the resolution switching, seems odd how that's done in windows, did that really work smoothly in the past?  I am not actually repeating the modeline setup when the change happens, I'm not fully sure if that's necessary or what goes on but just know the ddraw instance is destroyed from being signaled by the change of resolution in the render/emu core. Right now it really should basically follow the same as cabmame would do it, I changed around the general structure and also now fixed the problems with it not allowing scaling to work (cleanstretch and changres together or separate should really be working better now, I completely recoded that a lot different than it had been done in cabmame).  If it doesn't work either in the last version, the at least good to know the current change didn't break it, but suspect it wouldn't and seems to possibly be something more to do with how that tear down of the drawing layer is supposed to bring it back up at a new resolution (does the logic really get redone to pick a new resolution, not sure how any of that would just happen in the code as I see it in mame).  I know in the Linux side it's a big headache to figure out what to do, how to exit/re-enter SDL which is required to get a new resolution into SDL to work.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 04, 2011, 06:13:46 pm
I'll have a look at the changeres option code and patches, I never really looked at that thoroughly. I believe I've seen it working in CabMame, but there was always the problem of not being able to recalculate the new modeline, and maybe the pick best mode logic used was the default one in Mame so you had no control on the results.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 04, 2011, 06:17:12 pm
I'll have a look at the changeres option code and patches, I never really looked at that thoroughly. I believe I've seen it working in CabMame, but there was always the problem of not being able to recalculate the new modeline, and maybe the pick best mode logic used was the default one in Mame so you had no control on the results.

Yeah to recalculate the modeline, shouldn't be difficult now at all, but of course there is the question of when to do so and when to let go and delete the old one.  So in the code it's pretty hard to tell what really will happen, but I'll look at it closer too since once understanding and getting the Windows side working, that would help me figure out the SDL/Linux side of things possibly. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 05, 2011, 05:48:17 am
Hi, I'm testing the new version 1495, passing logs.

Do not install if you do not set the network and sound.
At the Disco Option gasetup, I think the definition of Livecd Stateful, is confusing and should be home.
You should put one to reset the settings on the menu.

If groovymame included because it is still used and switchres.conf switchres?
Not in mame.ini switchres options, if you create the new mame.ini if there are options.

Fails to duplicate Wminput absolute axis, the error is in mamebuttons
Cassic.lstick.X / Y

I saw that you put on the git support suckle cwiid gun, have modified some of the code?
Because you have not put the gun to use 2 players?


Thank
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 05, 2011, 06:08:37 am
Hi bitbytebit. I'm having problems applying the new patches. I think I'm following the right order, I'm applying u1 -> u2 -> u3 -> hi_141u3 -> u3_hilinux and here is where the problems start. I normally use two trees: \a and \b, (\a for the original source, \b for the patched source). For some reason your new patches are creating a subfolder \b inside \b if I point to the same paths I use for the other patches. If I don't point to \b but to the parent folder where \b is, then the files seem to be properly targeted but I get some files patched in my \a folder! So maybe you're using a different logic there, anyway I'm not very good using these diff tools.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 05, 2011, 08:54:42 am
Hi bitbytebit. I'm having problems applying the new patches. I think I'm following the right order, I'm applying u1 -> u2 -> u3 -> hi_141u3 -> u3_hilinux and here is where the problems start. I normally use two trees: \a and \b, (\a for the original source, \b for the patched source). For some reason your new patches are creating a subfolder \b inside \b if I point to the same paths I use for the other patches. If I don't point to \b but to the parent folder where \b is, then the files seem to be properly targeted but I get some files patched in my \a folder! So maybe you're using a different logic there, anyway I'm not very good using these diff tools.


I usually create the patches using a git repository.  If you go into the directory of mame (where the makefile is) itself, the run 'cat ../patch1.diff | patch -p1' for each patch in order (after the original uX patches and then the hiscore patch, which will require -p0), they should apply clean.  I'm not sure what it's doing, odd, but should work right if doing it this way instead. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 05, 2011, 09:03:28 am
Hi, I'm testing the new version 1495, passing logs.

Do not install if you do not set the network and sound.
At the Disco Option gasetup, I think the definition of Livecd Stateful, is confusing and should be home.
You should put one to reset the settings on the menu.

If groovymame included because it is still used and switchres.conf switchres?
Not in mame.ini switchres options, if you create the new mame.ini if there are options.

Fails to duplicate Wminput absolute axis, the error is in mamebuttons
Cassic.lstick.X / Y

I saw that you put on the git support suckle cwiid gun, have modified some of the code?
Because you have not put the gun to use 2 players?


Thank


Yeah I've changed that already for the next ISO, i'll no longer require sound/network setup to install.  The live stateful directory is kinda weird sounding, mostly was trying to say that it isn't really necessary unless your just wanting to use a liveCD and really a home directory is not necessary if your doing an install.

Switchres will be there for the other emulated games still, so it's necessary.  Mame will be the groovymame and eventually just be that, because I'm not going to maintain the old mame patches since they aren't really necessary now that it is built into mame, so mame itself won't use switchres anymore probably in the next ISO (but the option in the setup will setup mame in the mame.ini with the correct monitor and orientation still).

The cwiid support right now is really just to get it in there to allow setup and testing manually, I know there's definitely more to do with that but I haven't had time to figure out the setup for things like 2 players in the ISO.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 05, 2011, 02:26:52 pm
Note that the git repository has now changed.  The main mario.groovy.org page reflects the changes if wanting to checkout through git, or see the changelog or browse the repository.

http://git.groovy.org/trac/groovy_groovyarcade/log/ (http://git.groovy.org/trac/groovy_groovyarcade/log/)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 06, 2011, 06:02:15 pm
Yesterday I finally installed x64 for testing, I've patched Catalyst 9.3 for XP64, I'm testing it here and seems to work well. The patch is slightly different from the other one, it allows up to 127 custom modes. It also has the other fix to disable doublescan for 320x and 400x modes. I've updated this .rar with the new VMMaker and ArcadeOSD. Although it's working here, bear in mind this is a beta version so in case you get a blue screen or something just restart with f8 and unistall. Try this link:

http://www.megaupload.com/?d=LXF3NDHL (http://www.megaupload.com/?d=LXF3NDHL)

The only problem I'm seeing is the usual with Hyperspin not loading. For some reason the patch has some side effect when the number of modes is above some limit, that prevents Hyperspin from loading.

If I get this version working I'll go on with the 6.5 one, to support the older cards.

Update: I updated the link, uploaded it to megaupload as my server is failing when downloading large binary files.

I've trying GroovyMame with this driver and it works great. You can just use the default mode table that the driver installs, no need to run VMMaker unless you want to tweak something. So just install the driver, restart and run GroovyMame, it will recognize the installed modes and recalculate modelines as required.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 07, 2011, 04:21:17 am
Yesterday I finally installed x64 for testing, I've patched Catalyst 9.3 for XP64, I'm testing it here and seems to work well. The patch is slightly different from the other one, it allows up to 127 custom modes. It also has the other fix to disable doublescan for 320x and 400x modes. I've updated this .rar with the new VMMaker and ArcadeOSD. Although it's working here, bear in mind this is a beta version so in case you get a blue screen or something just restart with f8 and unistall. Try this link:

http://www.megaupload.com/?d=LXF3NDHL (http://www.megaupload.com/?d=LXF3NDHL)

The only problem I'm seeing is the usual with Hyperspin not loading. For some reason the patch has some side effect when the number of modes is above some limit, that prevents Hyperspin from loading.

If I get this version working I'll go on with the 6.5 one, to support the older cards.

Update: I updated the link, uploaded it to megaupload as my server is failing when downloading large binary files.

I've trying GroovyMame with this driver and it works great. You can just use the default mode table that the driver installs, no need to run VMMaker unless you want to tweak something. So just install the driver, restart and run GroovyMame, it will recognize the installed modes and recalculate modelines as required.


Sounds really cool, I like having the modeline table built in, will be great to have this and the 32 bit driver available to download with groovymame and make it simple as possible for people to use. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 07, 2011, 05:36:53 am

The only problem I'm seeing is the usual with Hyperspin not loading. For some reason the patch has some side effect when the number of modes is above some limit, that prevents Hyperspin from loading.



Well that's certainly a dealbreaker there. Any clue what's going on? Why would Hyperspin even be polling video modes?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 07, 2011, 07:07:44 am
Quote
Well that's certainly a dealbreaker there. Any clue what's going on? Why would Hyperspin even be polling video modes?

Yes I'm afraid it is, many people here using Hyperspin. I have no clue why that happens. The patch I do of course is not the cleanest thing possible, so it must be overflowing some memory buffers but surprinsingly it works and the only application that seems to be affected with each new version is Hyperspin. The workaround is to define less video modes but then the fun is over. I don't know much of the Hyperspin project or if it's even possible to contact the developers, anyway I'll have a look at it, the solution could be to patch Hyperspin itself...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 07, 2011, 08:13:44 am
Yeah the developers are very active on the forum over at www.hyperspin-fe.com (http://www.hyperspin-fe.com) and Dazz is active here a good bit:

Profiles:
http://forum.arcadecontrols.com/index.php?action=profile;u=8047 (http://forum.arcadecontrols.com/index.php?action=profile;u=8047)
http://www.hyperspin-fe.com/forum/member.php?u=2 (http://www.hyperspin-fe.com/forum/member.php?u=2)


Care to share some of the technical bits about what you're actually patching?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 07, 2011, 11:02:02 am
I've written to Dazz, hopefully he can figure out what is happening. It could be the buffer they use to retrieve the system video modes is not big enough, just to think of a possible reason...

The file I'm patching is ati2mtag.sys. Basically what I do is to increase the number of modes the driver polls from the registry, like this:

Code: [Select]
 '.text:0000000000052EE7                 lea     r8d, [rsi+3Ch]
  '.text:0000000000052EEB                 lea     rdx, aDalnonstandard ; "DALNonStandardModes"

  PatchFileByte ( TargetFile, &h000424EA, 127 )

So that replaces 3Ch (60) by 127. I can't use a bigger number there cause it's a signed char so 128 is already negative.

Then I patch the instances where 140h and 190h are checked (320 and 400) to disable doublescan for those modes. There many of them, look like this:

Code: [Select]
 '.text:00000000000D1369                 cmp     r8d, 140h
  '.text:00000000000D1379                 cmp     r8d, 190h

  DATA 000C096C, 40, 00,  000C096D, 01, 00
  DATA 000C097C, 90, 00,  000C097D, 01, 00

I wouldn't mind uploading the full patch code at some point so someone else can help with this.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 07, 2011, 11:21:11 am
Updated the Groovy Arcade ISO, mostly just using 0141u3 now, but also utilizes groovymame instead of switchres for mame too, rest of the emulators still use switchres.

Quote
07032011 - 1.500 Release
         - Improved menu setup logic for install
         - Gasetup modifed to configure mame.ini for groovymame settings
         - Use groovymame directly instead of switchres for mame, renamed to groovymame
         - Mame version 0141u3 update
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 07, 2011, 11:23:47 am
Neat, that's fairly straight forward then.. Are you actually disassembling the .sys, or do you have some tool to view it like that?


One thing I'm still a little fuzzy on is why exactly the patched drivers are being suggested to be used with Groovymame if it's generating the modelines and updating the registry itself on the fly. Did I miss a post somewhere that spells it out?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 07, 2011, 11:42:18 am
Neat, that's fairly straight forward then.. Are you actually disassembling the .sys, or do you have some tool to view it like that?


One thing I'm still a little fuzzy on is why exactly the patched drivers are being suggested to be used with Groovymame if it's generating the modelines and updating the registry itself on the fly. Did I miss a post somewhere that spells it out?

Some time ago I coded some tools for a specific reverse engineering project but now for this driver stuff I use a normal disassembler. The problem with drivers is that you can't use a normal debugger as they run in the system layer, so it's terribly hard to find what they're doing.

The main reason this drivers are suggested and not the regular Catalyst is: 120 vs 60 custom video modes. 60 is just not enough to accomodate a decent video mode table for emulation. Bear in mind we can't really add new resolutions (HxW), what we do is to recalculate the existing ones for the refresh rate we want. That's why we need more than 100 resolutions available to have plenty of different resolutions to tweak. So, remember:

Resolution: [xres, yres] -> (we can't define new (xres, yres) pairs on the fly, we need to have them available when the system starts)
VideoMode: [xres, yres, vfreq] -> (using the (xres, yres) pairs available, we can define an infinite number of (xres, yres, vfreq) triads)

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 07, 2011, 11:42:44 am
Neat, that's fairly straight forward then.. Are you actually disassembling the .sys, or do you have some tool to view it like that?


One thing I'm still a little fuzzy on is why exactly the patched drivers are being suggested to be used with Groovymame if it's generating the modelines and updating the registry itself on the fly. Did I miss a post somewhere that spells it out?
It can only change the refresh rate of an existing modeline, just like with powerstrip you must first have one with the same height and width in there as a resolution to alter the refresh rate.  I am not adding new modelines from groovymame itself, just utilizing existing ones custom added via another app like Soft15khz, VMMaker, PowerStrip or with the new driver from Calamity which is nice because it avoids adding them manually at all.  I really didn't want to mess with the registry that much, and it'd have to be a separate command to mame to generate the modeline table and you'd have to reboot to activate it.  I figured trying to manage the custom modelines in the registry for the user is getting a bit too overbearing, they can set it up  or have another program do so.  With a default Soft15khz install, things still work ok, just not fully amazing as when you have many more modelines to play with and alter refresh rates and match the height width more accurately.  
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 07, 2011, 11:49:49 am
I see I was totally misinterpreting what the software was doing then. That makes much more sense; thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 08, 2011, 08:42:10 am
Hi bitbytebit, I'm thinking we have an alternative source for resolutions information looking at the size HxW of snap bitmaps, provided we have them available (usual). Snaps are normally taken from the game itself so the size will probably be the right one. That way you can have the information beforehand to setup SDL already with it.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 08, 2011, 06:10:46 pm
Hi bitbytebit, I'm thinking we have an alternative source for resolutions information looking at the size HxW of snap bitmaps, provided we have them available (usual). Snaps are normally taken from the game itself so the size will probably be the right one. That way you can have the information beforehand to setup SDL already with it.


The place it gets that information for those is window->target->compute_minimum_size(newwidth, newheight);, the compute_minimum_size() function.  That in theory, or at least I thought, would return the same size I get from what I'm doing which is basically asking the game driver what resolution it uses.  Now I do see that there is more complex layer checking in the compute_minimum_size() function so are you saying it'll give us the best resolution  or maximum the game  will switch to, and provide it at startup?  That would be cool if it did, although then the question is how to access it before the actual window layer is built and before things startup for the OSD.  I need to study it more, although if it doesn't calculate that information before the actual resolution switch occurs then it's basically the same information I'm using currently.  I'm not totally understanding how/where the resolution switch information is stored so we could access it ahead of time, maybe that function is the answer and those layers have it, or would it be something possibly in the rom and the request is sent from there to the driver and so it's more buried and harder to extract ahead of time.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 08, 2011, 06:19:10 pm
Well I didn't explain the idea properly, what I meant is a much more rudimentary approach. We usually have folder with snapshots of the game. Those png files actually contain the info for the main game's resolution (their HxW size), you can get that easily using Windows api, may be easy in Linux too. So, it that resolution is different from the one you get from the xml, then you can create both modelines at startup and have them ready for the resolution change when invoked.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 08, 2011, 06:29:27 pm
Well I didn't explain the idea properly, what I meant is a much more rudimentary approach. We usually have folder with snapshots of the game. Those png files actually contain the info for the main game's resolution (their HxW size), you can get that easily using Windows api, may be easy in Linux too. So, it that resolution is different from the one you get from the xml, then you can create both modelines at startup and have them ready for the resolution change when invoked.
That gives me an idea, we actually could avoid any need for images and just when a game switches resolutions write it out to a .ini file for the game with some new config name like switchres=640x480@60 which we can have as many of those as we need and at startup switchres can check for those .ini file settings and add those as extra resolutions for the game to use.  First run of the game would generate them, and after that any later run of the game would be able to switch resolutions and it'd work for both Windows and Linux. I'll have to do some tests, it really shouldn't be too hard but I will need to have an array of modelines which might prove interesting at least with the registry stuff in Windows.  Hopefully easier than I'm thinking, could be some oddities but in Linux it's probably going to be pretty simple actually using xrandr.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 09, 2011, 05:00:37 am
I just checked my snaps collection here to see how accurate it is, and I'm seeing it's not such a reliable source of information as I expected, some snaps don't have the right size at all so the behaviour would be a bit unpredictable. I will check for a better collection in the internet. However your approach using inis will work for sure, at least after you run the game once.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 13, 2011, 01:55:28 pm
Hi I have already tested the new version 1,500, for the time being perfect, I have not found errors.
I created a tutorial in Spanish, and a video, if calamity or another person can be encouraged tradrucir and you can put on your website or forum.
I also want to ask for help from the people, have the courage to try to make the ini file's if necessary or you think it will not be necessary? I say this because these games like Golden Axe 2 etc. .. not catch your correct resolution and you have to create the ini.
In this way I think we'll have more testers to help you make mistakes.

Developments that have or where are you now?

Tutorial.

http://www.retrovicio.org/foro/showthread.php?14969-GroovyArcade-Por-fin-100-Pixel-Perfect-y-mucho-mas (http://www.retrovicio.org/foro/showthread.php?14969-GroovyArcade-Por-fin-100-Pixel-Perfect-y-mucho-mas)

Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 13, 2011, 02:56:10 pm
Hi I have already tested the new version 1,500, for the time being perfect, I have not found errors.
I created a tutorial in Spanish, and a video, if calamity or another person can be encouraged tradrucir and you can put on your website or forum.
I also want to ask for help from the people, have the courage to try to make the ini file's if necessary or you think it will not be necessary? I say this because these games like Golden Axe 2 etc. .. not catch your correct resolution and you have to create the ini.
In this way I think we'll have more testers to help you make mistakes.

Developments that have or where are you now?

Tutorial.

http://www.retrovicio.org/foro/showthread.php?14969-GroovyArcade-Por-fin-100-Pixel-Perfect-y-mucho-mas (http://www.retrovicio.org/foro/showthread.php?14969-GroovyArcade-Por-fin-100-Pixel-Perfect-y-mucho-mas)

Thanks.

Cool, I've been working on getting the linux SDL to resolution switch properly and Windows to hopefully do it too.  I'm close, Windows might work and Calamity is testing for me.  In Linux I'm close, hopefully, but there's a few issues there and I'm trying to work them out.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 15, 2011, 10:05:21 am
Hello bitbytebit, I have created scripts that automatically loads the wiimotes GroovyArcade once you start.

Code: [Select]
#!/sbin/runscript
# Author: Ves
# Date:   14/03/11
# Version 0.1
# Created for GroovyArcade
# You must change the parameters wiimote1 and wiimote2
# It uses lswm to identify your wiimote

Wiimote1="00:19:1D:00:00:00"
Wiimote2="00:1E:A9:00:00:00"

start() {
   ebegin "Starting Wiimote"

wminput -d -c ir_ptr $Wiimote1 >/dev/null 2>/dev/null &
sleep 1
wminput -d -c ir_ptr.2 $Wiimote2 >/dev/null 2>/dev/null &

}

stop() {
ebegin "Shutting down Wiimote"
killall -9 wminput

}




For those who want to try:

touch /etc/init.d/wiimote
chmod +x /etc/init.d/wiimote
edit and copy the above text in the file /etc/init.d/wiimote
update-rc add wiimote default
reboot

Remember to change directions Wiimote1 and Wiimote2, you can find using the command lswm and synchronizing.

Thank.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 17, 2011, 09:59:27 am
Bitbytebit Hi, I saw that you included the script for the next version, but I've noticed that only work a Wiimote.
You should include this several more files, and also change the button A and B, that is the shot so the pumps B and A, in the gun games, I put my configuration files.


ir_ptr
Code: [Select]
#ir_ptr

include buttons   
Plugin.led.Led1 = 1       <<<<< This option identifies the wiimote and put the LED in 1
Plugin.ir_ptr.X = ~ABS_X
Plugin.ir_ptr.Y = ~ABS_Y

ir_ptr.2
Code: [Select]
#ir_ptr

include buttons
Plugin.led.Led2 = 1     <<<<< This option identifies the wiimote and put the LED in 2
Plugin.ir_ptr.X = ~ABS_X
Plugin.ir_ptr.Y = ~ABS_Y

mamebuttons
Code: [Select]
Wiimote.A = BTN_RIGHT
Wiimote.B = BTN_LEFT

Or

Wiimote.A               = KEY_LEFTALT
Wiimote.B               = KEY_LEFTCTRL

Have you tried the script, do you think? I like how the wiimote as a gun? you had any error or failure?


Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 17, 2011, 10:10:12 am
Bitbytebit Hi, I saw that you included the script for the next version, but I've noticed that only work a Wiimote.
You should include this several more files, and also change the button A and B, that is the shot so the pumps B and A, in the gun games, I put my configuration files.


ir_ptr
Code: [Select]
#ir_ptr

include buttons   
Plugin.led.Led1 = 1       <<<<< This option identifies the wiimote and put the LED in 1
Plugin.ir_ptr.X = ~ABS_X
Plugin.ir_ptr.Y = ~ABS_Y

ir_ptr.2
Code: [Select]
#ir_ptr

include buttons
Plugin.led.Led2 = 1     <<<<< This option identifies the wiimote and put the LED in 2
Plugin.ir_ptr.X = ~ABS_X
Plugin.ir_ptr.Y = ~ABS_Y

mamebuttons
Code: [Select]
Wiimote.A = BTN_RIGHT
Wiimote.B = BTN_LEFT

Or

Wiimote.A               = KEY_LEFTALT
Wiimote.B               = KEY_LEFTCTRL

Have you tried the script, do you think? I like how the wiimote as a gun? you had any error or failure?


Thanks.

Cool, I updated the scripts to those settings and added the player two script.  I plan on eventually creating a setup that enabled the init.d startup script to run if chosen and has a user choose the wii remotes MAC settings hopefully automated.  I haven't had time to look at it closely lately, when I did it mostly worked as a normal controller and the gun/pointer part of it was decent yet would kind of get jittery towards the edges of the screen.  Having the classic controllers setup definitely adds fun to the NES emulator though, and even nice for a few arcade games too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 19, 2011, 11:24:47 am
Hi, I also happened to me once that the pointer shakes too, but I think if you can sync the 2 wiimotes at a time, and is connected to the sensor bar, the tremor is much lower.

Follow your git almost every day, and I saw that you are upgrading the data folder, with folders snap roms, etc of each emulator, but as I've said many times better than I are data folders for each emulator and within all subfolders of configurations snap roms etc, because I'm seeing so very, very chaotic.

As you bear the test with the new groovymame? if you need help tell me anything, and I also get tested.
For when a new version?

Thanks to titles included in the wiimote, but it is not necessary, just create the script for you and so try to contribute something however small.

Thanks
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 19, 2011, 11:30:33 am
Hi, I also happened to me once that the pointer shakes too, but I think if you can sync the 2 wiimotes at a time, and is connected to the sensor bar, the tremor is much lower.

Follow your git almost every day, and I saw that you are upgrading the data folder, with folders snap roms, etc of each emulator, but as I've said many times better than I are data folders for each emulator and within all subfolders of configurations snap roms etc, because I'm seeing so very, very chaotic.

As you bear the test with the new groovymame? if you need help tell me anything, and I also get tested.
For when a new version?

Thanks to titles included in the wiimote, but it is not necessary, just create the script for you and so try to contribute something however small.

Thanks

I've basically made the /data/ drive contain directories already setup and changed the structure to less of a tree and basically EMULATOR_roms and EMULATOR_snaps type formats.  This seems simplest because then a person can browse to the ROMS share on a windows network and see the right folders to drop roms and snaps into automatically.

Right now I'm working on auto-partitioning and getting grub-install to work right without any need for the user to do any extra work, also trying to slim down the amount of work to install. 

I have added the midnight commander console file manager to help make it easier for people to do file manager things, seems that's a popular file manager.

I'm not sure when the next release will be, maybe in a day or so, depends on if I can nail down this grub setup issue, it seems to not always work correctly.

In the next version, games that automatically change resolution in mid-game will work, so that's pretty cool, so now the -changeres option fully works with the modeline generation and setup in groovymame. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 20, 2011, 06:34:31 am
New Groovy Arcade Linux ISO images are up, version 1.515, contain full modeline resolution switching for games changing resolution to test and hopefully enjoy.  Also a few other major installation improvements so no longer have to deal with manual partitioning and manual grub setup... 

http://forum.arcadecontrols.com/index.php?topic=107620.msg1170720#msg1170720 (http://forum.arcadecontrols.com/index.php?topic=107620.msg1170720#msg1170720)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 20, 2011, 07:11:26 am
Thanks, I'm down to try it, as you have it report my impressions.

By the way where you want to keep the post, here or in the section of linux?

Where is the groovymame code 008, do not see it in the git?

bitbytebit remember that if it sounds bad any comments sentence is automatic translator google
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 20, 2011, 07:22:15 am
Thanks, I'm down to try it, as you have it report my impressions.

By the way where you want to keep the post, here or in the section of linux?

Where is the groovymame code 008, do not see it in the git?

bitbytebit remember that if it sounds bad any comments sentence is automatic translator google

I think it is good to keep the monitor switchres stuff here, and linux leaning stuff in the Linux section, although since the distributions main purpose is to center around the capability of switchres/modelines I figure it's important to announce here the releases of the ISO.  Also discuss the monitor specific technical stuff here, any Linux specific stuff in the Linux thread.  Seems like a nice way to keep it organized.

Sounds great, can't wait to see how it goes testing, I'm hoping this one really makes the installation seamless.  I'm sure there's still rough edges, so hopefully this gets the biggest issue of grub install and partitioning out of the way for the finer details.

I'm not sure about groovymame 008, the version numbering hasn't been as clean right now unfortunately, but it's at 011 currently and 008 was probably buggy :) Will see how Calamity does on 011, and you can test it too, hopefully I fixed the major issues in Windows there now with resolution changes in-game and in Linux it should work now too. (same but different, quite interesting in both cases what is required, SDL was not a great help but a one line change in SDL makes it able to see new modelines added with xrandr without restarting mame).

Yeah google translate isn't so bad it seems for Spanish, I've been reading Japanese blogs lately about the earthquake and for that, google translate is so much worse :)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 20, 2011, 05:43:44 pm
Hi, I have already tested the new version 64bit 1.515:

Automatic partitioning works well, but only created 2 partitions swap and root, because it creates home? and that first creates the swap partition rather than the root?

GroovyMame works perfectly with games in different resolutions like Golden Axe 2, ghost chasea etc or at least where tested, have not been many, and try it again.

Grub works fine, but for quite some time, new problems arose?

If the data partition is created, does not create or copy folders snap roms and emulators and the various cat.

Scripst wiimote does not start at the beginning, it lacks the update-rc add wiimote default

Do not know if it will be a failure to download the iso, the record or is a real error GroovyArcade, but if I run the wiimote or do you load from the beginning to put a game in mame always takes the characters to the left may not play But advmenu not pass, so that also could be for groovymame? tomorrow I will go back down, will write and proves again.

You have to edit the file and change the option ir_ptr.2 that identifies with the led, because it identifies the two controls with LED 1.

ir_ptr
Quote
Plugin.led.Led1 = 1       <<<<< This option identifies the wiimote and put the LED in 1

ir_ptr.2
Quote
Plugin.led.Led2 = 1       <<<<< This option identifies the wiimote and put the LED in 1


A colleague reminded me of a project to use the LPT port as a ipac, making a very very simple little invention. It created the Openppjoy, I put the links because it would be interesting to include it, it's just a small module for the kernel.

https://code.google.com/p/openppjoy/ (https://code.google.com/p/openppjoy/)
http://david.dantoine.org/destacado/6/ (http://david.dantoine.org/destacado/6/)


A couple of suggestions may be included in the section gasetup configure the network for static? and also in the emulators section edit the wiimote to change wiimote1 wiimote2?

Will report more things remember when, but I think there are no more.  ;)




Thank you very much.  :notworthy:




Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 20, 2011, 10:25:24 pm
Hi, I have already tested the new version 64bit 1.515:

Automatic partitioning works well, but only created 2 partitions swap and root, because it creates home? and that first creates the swap partition rather than the root?

GroovyMame works perfectly with games in different resolutions like Golden Axe 2, ghost chasea etc or at least where tested, have not been many, and try it again.

Grub works fine, but for quite some time, new problems arose?

If the data partition is created, does not create or copy folders snap roms and emulators and the various cat.

Scripst wiimote does not start at the beginning, it lacks the update-rc add wiimote default

Do not know if it will be a failure to download the iso, the record or is a real error GroovyArcade, but if I run the wiimote or do you load from the beginning to put a game in mame always takes the characters to the left may not play But advmenu not pass, so that also could be for groovymame? tomorrow I will go back down, will write and proves again.

You have to edit the file and change the option ir_ptr.2 that identifies with the led, because it identifies the two controls with LED 1.

ir_ptr
Quote
Plugin.led.Led1 = 1       <<<<< This option identifies the wiimote and put the LED in 1

ir_ptr.2
Quote
Plugin.led.Led2 = 1       <<<<< This option identifies the wiimote and put the LED in 1


A colleague reminded me of a project to use the LPT port as a ipac, making a very very simple little invention. It created the Openppjoy, I put the links because it would be interesting to include it, it's just a small module for the kernel.

https://code.google.com/p/openppjoy/ (https://code.google.com/p/openppjoy/)
http://david.dantoine.org/destacado/6/ (http://david.dantoine.org/destacado/6/)


A couple of suggestions may be included in the section gasetup configure the network for static? and also in the emulators section edit the wiimote to change wiimote1 wiimote2?

Will report more things remember when, but I think there are no more.  ;)




Thank you very much.  :notworthy:






Yeah the ability to create more than 2 partitions gets complicated because we really need to know the full hard drive size and decide for the user how much they need, anyways I figure in non-LiveCd setups a home directory isn't really needed, just one main partition should technically be good.  Know that saving some data on there would be nice, avoid having to backup on re-install, so am planning on possibly making it so a 1 gig or more home drive is setup, but hard to tell what is best for a user.

The grub setup was failing for some users, so I now use a more fail-safe method and no longer require a separate manual setup of grub.  It worked before mostly, but now should work always, I hope.  Now I'm using grub-install on the basic drive name like /dev/sda plus setting up the grub mapping file properly too, so it's much more 'correct' in how it sets up grub.

Yeah the /data/ directories are not created if you have a drive already with roms/snaps, figure if already there then the user is going to have to edit advance menu config anyways and point to them.  Really don't need a separate partition/drive unless already have a drive with the roms/snaps, and again it's just a basic suggestion of names of directories, otherwise they can setup advance menu and put roms into the directories they setup there manually, or let the default setup exist and just drop them into the windows network share.

Yeah the wii remote isn't setup to start by default, will have a menu option to enable it eventually.  Since it doesn't seem like something to run by default unless a person has a wii remote, and they'll need an actual MAC address in the startup anyways, so should be some user chosen setup for that else it just seems like it'll be running something extra by default.

I'll have to look at the lpt port kernel module, sounds interesting, but again would be something I would want to let the user enable manually, to conserve an extra resources being used by running daemons.

Definitely good feedback, thanks!
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 23, 2011, 10:03:22 am
Hi, I confirm that when running wminput, whether or not synchronized controls, makes the game suck always move in one direction left, if you change the value from 0 to 0.35 joystick_deadzone goes right, the code can be something that has changed in the sdl? as the joystick uses sdl, I need to confirm if it happens also in the 32-bit version.

If you disable the joystick mame.ini works smoothly, but does not work as gun control, just as a normal joystick.

Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 23, 2011, 10:13:39 am
Hi, I confirm that when running wminput, whether or not synchronized controls, makes the game suck always move in one direction left, if you change the value from 0 to 0.35 joystick_deadzone goes right, the code can be something that has changed in the sdl? as the joystick uses sdl, I need to confirm if it happens also in the 32-bit version.

If you disable the joystick mame.ini works smoothly, but does not work as gun control, just as a normal joystick.

Thanks.
It wouldn't be in SDL, it hasn't changed at all besides a one line alteration in the ListModes() call, so couldn't be that. 

If you look at the recent git updates, you'll see some of the changes I am making that might be interesting, I'm completely reworking the location of the roms and the automated partitioning.  basically setups up /home /boot / as separate partitions, puts roms under /home/roms/ now (including /roms/roms/roms/ for mame which will maybe become /home/roms/Mame_roms/ to avoid redundancy).  Throws away the whole idea of a /home/arcade/ partition unless using a LiveCD only, else it's /home/ that's separate.  Can have /home/roms/ be a separate drive to use USB or other types of media.  Basically trying to also make the install simpler, and liveCD setup simpler, so the menu is being redone completely in how it presents things.  So by the end of this week, should have ISO's up with those changes, and hopefully separate out the LiveCD setup from the Install and simplify things quite a bit.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 23, 2011, 10:34:26 am
Bitbytebit, you can try if you so with cwiid?

Later looking at the git, the whole kernel source or diff and git groovymame in?

Another thing that could help the usbmount, automatically mounts the usb and it would be much easier for beginners.

Openppjoy going to include in the end?

Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 23, 2011, 10:48:41 am
Bitbytebit, you can try if you so with cwiid?

Later looking at the git, the whole kernel source or diff and git groovymame in?

Another thing that could help the usbmount, automatically mounts the usb and it would be much easier for beginners.

Openppjoy going to include in the end?

Thanks.
The latest Git check ins should show the changes, mainly in the gasetup directory.

Yeah I will get to those, but right now focusing my time I have on the initial setup still, trying to get it so more users can do the basic install.  There are issues with grub setup that this should fix, having a smaller /boot directory that is ext2 hopefully solves that issue.  Also the windows NTFS mapping to /home/roms should work now with my latest changes.  Just the basic simplistic install too, getting that so a user that doesn't want to go into details can just run the install choice and it'll lead them through all setup.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 25, 2011, 10:35:47 am
Hello, you step report of what I've seen in virtual machine.

I think the installation is now much more confused, because when you install asks you to configure almost everything again.

When you run the auto partitioning hd from the installation option, it tells you which are the partitions (logical) but asks you going to use partition for / home and / roms which do not know, because it creates the following.
sda1 / boot 100mb
sda2 / Swap XXgb.
sda3 / XXgb.

By asking the partition where you are going to install groovyarcade out sda1 and sda3, and you might think because it is for groovyarcade sda1 and sda3 is for roms / home, but it is not so, which is not done well and grub installation failure .

I think you should make only 3 automatic partitioning
sda1 / root for all
sda2 /home/  this could be optional, and do that when you install a backup groovyarcade is hiciese in /data of the user's home.
sda3 / swap



And leave the choice to put the partition /data as before to have the roms, especially if you use a ntfs partition, which I do not think there will let you put the home, do you?

I was once more clean and clear way to make the installation and configuration of everything.


Well after seeing this, I have started to install again, but once the installation has failed grub, and I have not been able to get away.
I've changed a thousand times the options from grub to sda2 Label ram .. etc but it has not worked.

I think I should not ask in the installation of the HD, you set all the parameters Anteriror if you already have configured.


Then I will continue and you will report more things.


Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 25, 2011, 12:31:51 pm
Hello, you step report of what I've seen in virtual machine.

I think the installation is now much more confused, because when you install asks you to configure almost everything again.

When you run the auto partitioning hd from the installation option, it tells you which are the partitions (logical) but asks you going to use partition for / home and / roms which do not know, because it creates the following.
sda1 / boot 100mb
sda2 / Swap XXgb.
sda3 / XXgb.

By asking the partition where you are going to install groovyarcade out sda1 and sda3, and you might think because it is for groovyarcade sda1 and sda3 is for roms / home, but it is not so, which is not done well and grub installation failure .

I think you should make only 3 automatic partitioning
sda1 / root for all
sda2 /home/  this could be optional, and do that when you install a backup groovyarcade is hiciese in /data of the user's home.
sda3 / swap



And leave the choice to put the partition /data as before to have the roms, especially if you use a ntfs partition, which I do not think there will let you put the home, do you?

I was once more clean and clear way to make the installation and configuration of everything.


Well after seeing this, I have started to install again, but once the installation has failed grub, and I have not been able to get away.
I've changed a thousand times the options from grub to sda2 Label ram .. etc but it has not worked.

I think I should not ask in the installation of the HD, you set all the parameters Anteriror if you already have configured.


Then I will continue and you will report more things.


Thanks.

The /boot partition is needed actually in some cases of bios's out there which the grub MBR on a large partition doesn't work and it needs to be ext2 type to work.

I really guess the setup option could be moved into the LiveCD section, but yet it is good for after setup has been done, I just have it ask again in Install to make sure the user has really went through the setup parts.  I can do something to check and not ask again if they already entered those menus, was going to do that, but didn't get around to it yet and figured for now it just makes sure they did it.

Actually the /home is pretty important now, and to have the roms under /home/roms/ because that will allow us to upgrade in the future by preserving /home and not reformatting it on an update.  So just the /boot and / drives will be installed to, and they save all the /home/ and /home/roms/ information.

I'm not sure why it's failing, are you choosing a roms drive or possibly something else, I've done lots of tests and installed it on a system, so something is odd, the grub installation always has been working so far.  Have you tried it just running the install option and rebooting, possibly more details of exactly which paths lead to failure, since I'm guessing there's some part of setup or variable failing.  How big is the virtual disk drive your using to install to? 

I'll do some more tests later when I can and try to see what is going on, also will work on getting the install to check and not ask about setup options if you've already done them in the menu.

Do you have the output of 'fdisk -l' after install, or autopartitioning, and output of 'df -h' too, possibly the output of 'cat /groovyarcade/boot/grub/grub.conf' to see how grub.conf got configured?  Those might help figure some things out.

Thanks
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 26, 2011, 06:18:22 am
So I've switched my monitor over to a new Makvision 29" SVGA CRT. It's a 31kHz monitor. I'm still trying to pin down exactly what resolutions it does and how many modes it will store, but it certainly does 640x480 and 800x600. the label on the chassis says hfreq 30-40kHz, vsync 47-90hz.

How would you recommend setting up groovymame to take advantage of this monitor best? I've been tinkering with settings myself, but so far I've been unable to get it to correctly fill the screen without turning on hardware stretching, which I'd like to avoid as I don't like the soft look of the filtering.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 26, 2011, 06:45:51 am
Hi, I've had more time to do the tests I mention that this was.

Virtual Machine and automatic partitioning.

to install asks if you have a directory of roms if you say yes, and do not have a partition dedicated to roms you fail.

If you install and you say you do not have a partition dedicated to roms installed fine but then fails to boot, is not Ga-home, it makes sense because no home partition is created automatically.
If you see fstab shows / = LABEL = Ga-home / sda2 ....


Remember that just automatically creates 3 ​​partitions boot, root and swap, when you should create 4 partitions to take home, in the menu have not found anything that refers to using a partition as home, or in the installation asks you for a home partition, but a partition for roms.
Well I've seen an option where I do not remember saying something to save the data, may be the option to create home? if so should be more visible and the partition section and also be present in the hard disk installation.

Truly arcade machine partitions.

sda1 / root 10gb.
sda2 / roms 450GB
sda3 / swap 2GB

Installed and everything works fine.
In the clear version Anteriror home since formatted and was always backing up home, so I decided to remove it and follow those steps for now.

I think if you create a partition of about 10GB for root, no need to use the boot partition as this is small and I've always works well with grub.

Do not think that when you do the installation to the hard drive if you ask the network of sound, etc. should not ask for the configuration of the orientation and aspect of the video?

Could you explain, that option is really worth the Video Card KHz output?

Start the Frontend option you should put it in the main menu.



You need to change this option for the second wiimote led out in position 2.

ir_ptr.2
Code: [Select]
Plugin.led.Led2 = 1      
I have seen the bug that causes cwiid wminput when running, that moves the character on one side of the screen is the option of mame joystick, the maps will be active all directions up down left right etc with its appropriate letter keyboard but also with the joi 0 1 2 3 etc, there is also an error when entering the mame menu you can not go up or use the menu left to right in because that button is annoying and you have to map it again, this me going on in my normal pc, but do not remember how to solve it, I look and I mention as it was, anyway, so that error does not occur when you play you have to enter the mapping of player 1 and 2 and map the directions above again left right and down, it will not move the character and you can only play.

It can be a mame error and you are using versions of tests, which version you used before launching the livecd 1,515 or 1.5 as it was at this particular version when the error occurred

Just like that I have the h9110 mame.ini for my monitor out of sync a few games I can sync with the potentiometer and others (so I could try are the vertical sync I can not ever) there are also games that are repeated throughout the game mini screen windows of sync, I have changed many mame options and did not work, only VGA, and why opengl for soft switching is used to solve.

If I put the option in mame.ini of VGA1:
Horizontal games are working but I have narrowed the option to change the section full video in mame to cropped and stretched so the entire screen.
The vertical games do not work, does nothing the option of 3:4 4:3 etc. .. in mame.ini are always flattened, the only thing I can do is stretch them, but they look like 16:9
And games like dragon ball z using various resolutions are always focused on very small screen but like a tv 9 "


An observation more direct links to your web livecd do not work always go to a web page not found error 404.


Thank





Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 26, 2011, 07:39:14 am
Hello bitbytebit , I have seen in the diff you have changed this option in relation to the joystick mame, it may be that by changing that parameter, which when compiled mame needed for some of sync etc? from when you changed that option?


Code: [Select]
- { "joystick_deadzone;joy_deadzone;jdz",      "0.3",  0,          "center deadzone range for joystick where change is ignored (0.0 center, 1.0 end)" },

+ { "joystick_deadzone;joy_deadzone;jdz",      "0",  0,          "center deadzone range for joystick where change is ignored (0.0 center, 1.0 end)" },
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on March 26, 2011, 10:07:55 am
Guys...

Amazing thread.  Very technical.  I've spent the last four hours skimming through this thread...

I have a 29" tri-sync monitor in my Big Century cabinet.  On the chasis sticker, it lists:

H-Freq: 15/24/31khz
V-Freq: 47-70hz

I believe it is a wei-ya monitor from googling.  Last summer, I spent ALOT of time trying to get MAME as perfect as I could.  It looked wonderful using a combination of Soft15khz, Quickres and an ATI 4350, however, I had to keep making too many manual adjustments to the v/h-size/position when switching between different games, and by nature, I was reluctant to play it due to this.  I wanted to be able to play a different game, and for it to adjust and fit the screen automatically.

Whilst I appreciate there is no 'one size fits all' resolution and you need to find a happy medium, I was hoping for something a little better to avoid having to manually change the v/h-size/position quite so often and quite so radically.

For example, using Hyperspin, set to 640x480, some games fitted the screen perfectly, whereas others were way off and needed to major an adjustment to get them to fill the screen, and as a consequence, when I exited back to Hyperspin, the Hyperspin front-end screen position was then way off and the next game that was loaded up was more than likely way off...

I researched modelines and the like, but could never really get my head around them completely.

In the end, I just gave up and the cab has been lying, neglected for the last 6 months.  Hey, I'm a perfectionist!  I want to be able to show it off to my friends and play different games, but without the hassle of adjusting the screen each and every time I changed games.  Obviously, this detracts from the whole gaming experience somewhat...



Soooooo, this thread sounds exactly what I have been waiting for.  I am tempted to spend today trying to get this setup but I have a few questions:

I would rather stick to Windows, because I want to use Hyperspin.  If I could get MAME running near perfect, which if I'm not mistaken - is what this thread is all about, without having to manually adjust quite so much, that would be fantastic.

1.  What operating system is recommended.  I currently have Windows 7 64-bit on my PC, but I could dual-boot it no problem, with either XP32 or XP64, if they will work better with the hacked ATI drivers.  I'd prefer 64-bit obviously, but I'm not sure how far developed the hacked 64-bit drivers are.

2. Which files do I need do download/install, and where do I place these files.  This makes me appear lazy and useless, but I'm genuinely stumped as I've looked for a 'How To' guide for Windows in the thread and I've been unable to locate one.

Answers to those two questions would be enough to get me under way.  I like to tinker and try and work things out for myself, so that should keep me occupied for the next few hours!

TIA
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 26, 2011, 11:06:01 am
In the end, I just gave up and the cab has been lying, neglected for the last 6 months.  Hey, I'm a perfectionist!  I want to be able to show it off to my friends and play different games, but without the hassle of adjusting the screen each and every time I changed games.  Obviously, this detracts from the whole gaming experience somewhat...

Yeah I share your point completely. However, be aware that vertical amplitude adjustment is usually only possible by tweaking your controls/potenciometers. On the other hand, horizontal amplitude can be calculated by the modeline generator to be very similar from game to game, slight differences will exist however due to the discrete nature of modeline elements.

1.  What operating system is recommended.  I currently have Windows 7 64-bit on my PC, but I could dual-boot it no problem, with either XP32 or XP64, if they will work better with the hacked ATI drivers.  I'd prefer 64-bit obviously, but I'm not sure how far developed the hacked 64-bit drivers are.

2. Which files do I need do download/install, and where do I place these files.  This makes me appear lazy and useless, but I'm genuinely stumped as I've looked for a 'How To' guide for Windows in the thread and I've been unable to locate one.

You shouldn't use Windows 7 for serious CRT stuff. Get XP-64 instead and try my last hacked drivers. Still beta but have tried them for some weeks with no problem at all on a HD4350.

http://postback.geedorah.com/foros/viewtopic.php?id=1424 (http://postback.geedorah.com/foros/viewtopic.php?id=1424)
This one link-> http://www.megaupload.com/?d=LXF3NDHL (http://www.megaupload.com/?d=LXF3NDHL)

Install the drivers, restart and you should already be outputting 15Khz though the dvi connector (use a dvi-vga adapter). If you like, go to your download folder, try Arcade_OSD to navigate through your installed modelines and test modes.

Now get GroovyMame for XP-64: http://mario.groovy.org/GroovyMame/0141u3/ (http://mario.groovy.org/GroovyMame/0141u3/)
Install it in a clean folder, then in the command line run "groovymame -createconfig"
Edit Mame.ini with your roms folder and go down to the "# CORE SwitchRes OPTIONS" and edit the "monitor cga" option to match yours (I'd try d9800 for yours).

Now try "groovymame rom" to run the games... that's all.

On the Hyperspin fronted subject, there's a confirmed interaction among Hyperspin and my drivers, well for what I could see if the number of modelines defined in the system is bigger that a given amount (around 100) then Hyperspin won't load. There's the possiblity of using less modelines but then the fun is over. I wrote to Hyperspin's creator and fortunately he said he'll look at that and maybe fix it for next version 2.0.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 26, 2011, 11:23:56 am
So I've switched my monitor over to a new Makvision 29" SVGA CRT. It's a 31kHz monitor. I'm still trying to pin down exactly what resolutions it does and how many modes it will store, but it certainly does 640x480 and 800x600. the label on the chassis says hfreq 30-40kHz, vsync 47-90hz.

How would you recommend setting up groovymame to take advantage of this monitor best? I've been tinkering with settings myself, but so far I've been unable to get it to correctly fill the screen without turning on hardware stretching, which I'd like to avoid as I don't like the soft look of the filtering.
Sounds like there needs to be a monitor type specifically for that monitor, with those ranges setup.  The best way to do that would be adding also the front porch back porch and sync pulse values exactly from the monitor specs, then it would be the most centered and results would be the most predictable.  That's how I got my d9800 looking best, when those values were correct, else things were not always right at certain calculations.  If you can get those technical specs, I can use them and make a new monitor definition, and basically it's mostly up to the calculations and monitor specs to see what the possibilities are.  It's probably going to require doublescan I'm guessing for many of the resolutions I think, then again it's really up to the logic and calculations in the switchres code, Calamity probably can be more specific about the detailed outcome of if and how much stretching is going to be necessary.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 26, 2011, 12:17:22 pm
Hi, I've had more time to do the tests I mention that this was.

Virtual Machine and automatic partitioning.

to install asks if you have a directory of roms if you say yes, and do not have a partition dedicated to roms you fail.

If you install and you say you do not have a partition dedicated to roms installed fine but then fails to boot, is not Ga-home, it makes sense because no home partition is created automatically.
If you see fstab shows / = LABEL = Ga-home / sda2 ....


Remember that just automatically creates 3 ​​partitions boot, root and swap, when you should create 4 partitions to take home, in the menu have not found anything that refers to using a partition as home, or in the installation asks you for a home partition, but a partition for roms.
Well I've seen an option where I do not remember saying something to save the data, may be the option to create home? if so should be more visible and the partition section and also be present in the hard disk installation.

Truly arcade machine partitions.

sda1 / root 10gb.
sda2 / roms 450GB
sda3 / swap 2GB

Installed and everything works fine.
In the clear version Anteriror home since formatted and was always backing up home, so I decided to remove it and follow those steps for now.

I think if you create a partition of about 10GB for root, no need to use the boot partition as this is small and I've always works well with grub.

Do not think that when you do the installation to the hard drive if you ask the network of sound, etc. should not ask for the configuration of the orientation and aspect of the video?

Could you explain, that option is really worth the Video Card KHz output?

Start the Frontend option you should put it in the main menu.



You need to change this option for the second wiimote led out in position 2.

ir_ptr.2
Code: [Select]
Plugin.led.Led2 = 1      
I have seen the bug that causes cwiid wminput when running, that moves the character on one side of the screen is the option of mame joystick, the maps will be active all directions up down left right etc with its appropriate letter keyboard but also with the joi 0 1 2 3 etc, there is also an error when entering the mame menu you can not go up or use the menu left to right in because that button is annoying and you have to map it again, this me going on in my normal pc, but do not remember how to solve it, I look and I mention as it was, anyway, so that error does not occur when you play you have to enter the mapping of player 1 and 2 and map the directions above again left right and down, it will not move the character and you can only play.

It can be a mame error and you are using versions of tests, which version you used before launching the livecd 1,515 or 1.5 as it was at this particular version when the error occurred

Just like that I have the h9110 mame.ini for my monitor out of sync a few games I can sync with the potentiometer and others (so I could try are the vertical sync I can not ever) there are also games that are repeated throughout the game mini screen windows of sync, I have changed many mame options and did not work, only VGA, and why opengl for soft switching is used to solve.

If I put the option in mame.ini of VGA1:
Horizontal games are working but I have narrowed the option to change the section full video in mame to cropped and stretched so the entire screen.
The vertical games do not work, does nothing the option of 3:4 4:3 etc. .. in mame.ini are always flattened, the only thing I can do is stretch them, but they look like 16:9
And games like dragon ball z using various resolutions are always focused on very small screen but like a tv 9 "


An observation more direct links to your web livecd do not work always go to a web page not found error 404.


Thank







I just fixed the ir_ptr.2 file and also changed the joystick option back to .03 so those should be right now.

Is it VGA-1, I am pretty sure VGA1 won't work, unless you left out the - part, which is definitely important there.  I'm not sure, I haven't seen the games have issues with the different aspect values, are you using the monitor_aspect option?  I do need to have it able to setup the right monitor_connector in mame.ini or automatically in groovymame and guess it like switchres did.  This is something I hopefully will do soon, and possibly part of the issue?

The home partition should be created, I'm not sure what is happening, here's what the partitions look like when I install...

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          14      112423+  83  Linux
/dev/sda2              15         270     2056320   82  Linux swap / Solaris
/dev/sda3             271        2311    16394332+  83  Linux
/dev/sda4            2312      243197  1934916795   83  Linux

That is what it is trying to do, I'm not sure what is happening though there, is the drive big enough, or possibly something else odd going on? 

I changed it so the Video option is asked for now too, before I just checked for xorg.conf and only did that, but now ask for the section instead. 

I'm not sure about the roms drive setup, which has to be on a different physical disk drive, else it wouldn't be necessary anyways.  The drive must be completely empty too, else it won't make all 4 partitions, could that be the possible problem?  Basically the idea of the roms drive is that your main drive is not large enough, so it would be a separate drive, not the same as the main installation partitions above. 

I will do more testing and try to figure out what is going on, there might be a bug when the right/wrong options are picked, but if you just first off go into Installation and only do that, then what happens?  It in theory, since that's what I do mostly, should just work.

What does your fstab look like exactly, and output of `fdisk -l`?


The front end change is something that seems right for the System menu, and helps keep the menus from growing, I'm trying to keep the main menu as small as possible, hopefully the front end option isn't really necessary but for advanced cases.

The Video card Khz output option basically edits grub.conf and addes the video= lines for connector outputs, or removes them, can change it after an install that way.  You of course can't change it on the LiveCD since it can't save that and even during an install it shouldn't be changed since if you booted up to install that should be the same way you first reboot into it.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on March 26, 2011, 02:19:41 pm
You shouldn't use Windows 7 for serious CRT stuff. Get XP-64 instead and try my last hacked drivers. Still beta but have tried them for some weeks with no problem at all on a HD4350.

Hi Calamity,

Thanks for the swift reply.  I've just installed XP64 (forgot how much of a pain it was without native SATA support), and I'm now having problems installing your hacked 64-bit ATI drivers.  They just hang PC at the black screen, with cursor flashing in the top left corner...

I've tried forcing the install manually, but still no go...

any ideas?

also, one other question - where does soft15khz and quickres fit into the equation?  Do I even need to install these?  Fired up soft15khz just out of curiousity and it didn't detect the 4350 card, even though rebooting in safe mode (only way to get to desktop after hacked driver install) showed the 4350 in device manager...


edit: just tried the original 9.3 drivers, and same issue...  back to the drawing board!
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 26, 2011, 03:28:36 pm
Hello bitbytebit in the virtual machine is 8 gb hd, and the real machine I have not let the the HD format, otherwise you would lose all roms ;)

df -hT

sda3 ext4 6.9gb /
sda1 ext2 107mb /boot
udev devtmpfs 10mb /dev
shm tmpfs 504 /dev/shm

cat fstab

label=/GA       /     ext4 noatime
label=Gahome        /home    ext4 noatime (booting error, but rather the system load)
shm /dev/shm tmpfs
label=SwapSpace none swap




I've seen you've changed the option in the mame.ini joystick, but I'm not sure that works, I do not understand me when I ask if he could be about to change that option in the source code, and from that version groovymame have you changed? because that error is from 1515, before that version did not pass.



Thank.





Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 26, 2011, 05:08:12 pm
Hi Calamity,

Thanks for the swift reply.  I've just installed XP64 (forgot how much of a pain it was without native SATA support), and I'm now having problems installing your hacked 64-bit ATI drivers.  They just hang PC at the black screen, with cursor flashing in the top left corner...

I've tried forcing the install manually, but still no go...

any ideas?

also, one other question - where does soft15khz and quickres fit into the equation?  Do I even need to install these?  Fired up soft15khz just out of curiousity and it didn't detect the 4350 card, even though rebooting in safe mode (only way to get to desktop after hacked driver install) showed the 4350 in device manager...


edit: just tried the original 9.3 drivers, and same issue...  back to the drawing board!

Maybe it's a driver installation issue, I forgot to say it's convenient to run Catalyst Uninstaller before doing any new driver install:
http://downloads.guru3d.com/download.php?det=1275 (http://downloads.guru3d.com/download.php?det=1275)

Sometimes default Windows drivers can have a newer timestamp that the ones we are trying to install, and that could be an issue if Windows decides to mess them up with ours.

Of course I'm assuming your using your dvi output.

If my drivers are properly installed then you don't need to use Soft-15khz at all. You can run Soft-15Khz with my drivers and it will overwrite the already installed modelines (both methods use the registry to store the modelines, so they are actually the same method, it's only that my drivers have the modelines ready from the installation moment). So in case you can't finally get my drivers working you can go for the normal Catalyst and install Soft-15Khz on them, the difference is that you'll have a maximum of 60 possible modelines simultaneously while with my driver you have up to 128 modelines available, and the installed mode table is specially designed to be used together with GroovyMame, so the results will be much richer.

Update: make sure to run CatUninstaller booting in safe mode, and if needed run it several times (yes, sometimes for some reason it works that way). Cross fingers...

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 26, 2011, 08:17:57 pm
Hello bitbytebit in the virtual machine is 8 gb hd, and the real machine I have not let the the HD format, otherwise you would lose all roms ;)

df -hT

sda3 ext4 6.9gb /
sda1 ext2 107mb /boot
udev devtmpfs 10mb /dev
shm tmpfs 504 /dev/shm

cat fstab

label=/GA       /     ext4 noatime
label=Gahome        /home    ext4 noatime (booting error, but rather the system load)
shm /dev/shm tmpfs
label=SwapSpace none swap




I've seen you've changed the option in the mame.ini joystick, but I'm not sure that works, I do not understand me when I ask if he could be about to change that option in the source code, and from that version groovymame have you changed? because that error is from 1515, before that version did not pass.



Thank.







I see what the problem is, it's the way I'm partitioning and choosing the sizes, 8 gig is too small for my current method I am guessing.  I will have to make the / drive smaller in that case and put more towards /home/.  I'm guessing it's actually label=/GAhome /home above, else that might be an issue too.  Try to use a 16 gig virtual drive and see if that works, I'm guessing it will, I hadn't tested it for 8 gig or smaller but now see that might be an issue, but I'll fix it so it'll work.

Oh what value should the joystick be, is it 0?  I had thought .03 was what you said was better, but just let me know what works best and I'll change it. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on March 26, 2011, 08:38:25 pm
...so the results will be much richer.

You can say that again!!!

WOW... Just WOW!!

I'm gobsmacked by what you guys have achieved!

Turns out I have a dodgy PCI-E socket.  Swapped the card into the other socket and your drivers loaded first time.  Then I had an issue getting the picture to stop rolling at the desktop.  Couldn't quite get it to stay perfectly still, and I remembered I had to tick a box in ATI CCC to enable 'Composite Sync'...  Off the top of your head, is this normal?  I've googled it and it seems like it can be dangerous, but it's ticked at the moment, and as soon as I ticked it, the picture flickered briefly and became perfect...  btw, I have a J-pac installed, but I'm running the monitor VGA lead straight to my video card (using VGA-DVI connector), bypassing the J-pac altogether...

Anyway, it all appears to be working perfectly and just as I have always dreamed of!  I've just spent the last hour trying to catch it out, but not once did I have to manually adjust any V or H-size.  Every game I threw at it fired up in it's native resolution and maxed out my screen right to the edges without me having to do anything!

Amazing work guys!

It's just a shame about Hyperspin though.  I guess the holy grail would be having this AND Hyperspin running together, but I suppose that will happen in time...

A couple of questions:

1.  In the mame.ini, I have done as you said, and set monitor to 'd9800', but should I also change monitor_connector to 'DVI'?

Are there any other settings you'd recommend setting for optimal performance?  I noticed a few games seemed to play rather slowly, and I have a beast of a PC running MAME.

2.  In Progear, can you confirm the screen is higher than it is wider?  I thought it would have been more widescreen considering the type of game...  Sorry for having to use layman's terms, but it's best if I describe it how I see it!



Thanks again for this amazing piece of software!
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 26, 2011, 08:46:13 pm
...so the results will be much richer.

1.  In the mame.ini, I have done as you said, and set monitor to 'd9800', but should I also change monitor_connector to 'DVI'?

Are there any other settings you'd recommend setting for optimal performance?  I noticed a few games seemed to play rather slowly, and I have a beast of a PC running MAME.

2.  In Progear, can you confirm the screen is higher than it is wider?  I thought it would have been more widescreen considering the type of game...  Sorry for having to use layman's terms, but it's best if I describe it how I see it!



Thanks again for this amazing piece of software!

The monitor_connector setting is actually just a Linux specific setting, so no need to worry about it in Windows.

Calamity may know more about progear, calculating it in switchres shows it would use a modeline like this...

# progear 384x224@59.63 15.2651Khz
   ModeLine          "384x224x59.63" 7.693624 384 400 440 504 224 231 234 256 -HSync -VSync

It depends on the games, if they've played slowly before, some in Mame are just like that because imperfect emulation for them currently (like Radikal Bikers) or else it might be other issues, which Calamity can test in Windows and I can test in Linux to see if given games and the behavior they show there.

Thanks, definitely awesome to see this working well for you, and thanks for helping improve it in the future by giving feedback.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on March 26, 2011, 10:26:14 pm
cheers bitbytebit...  great software!

got progear sorted - not sure what i was doing wrong.

i found a few games that won't sync - donpachi and flying shark being two of them that i can remember.  can any of you point me in the right direction to get these running?  flying shark was one of my favourite games when i was a boy!  i'm guessing i need to play about with the arcade_osd, but i'm scared of it!  

btw, slightly off topic, but when i launch a game via the GroovyMame executable, it seems different than when i launch it via the command-line.  with command line, the colours seem much more vibrant and crisper and there is a CLEAR difference in quality between the two methods of launching.  not sure why this is so...  which method uses the mame.ini i created via the mame -cc command? the executable or the command line?

edit:  just remembered, i changed d3d to ddraw - would this be what is making it look nicer?

tia
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 27, 2011, 05:29:29 am
Hi MonkeyJug,

Thanks for your words and feedback.

If you solved the sync issue by using ticking the composite sync it's just ok. It could be either your monitor just requires that, your vga cable is wired for that, or your monitor's sync polarity needs to be setup for positive/negative. I can't be more specific as I have never met this problem myself and always worked for me with negative polarity, but I remember bitbytebit needed to set some of the polarities to possitive for his monitor in the modeline generator.

Games that run slow usually do that with normal Mame too. What happens is that if a given game was reaching the cpu limit without vsync and still working fluently, if we set vsync on (we need to) the fps may drop to 50%, as a consequence of the Mame not being able to render the whole frame between two vsync periods, so it will require two integer periods to render it and thus it'll drop fps to 50% normally. There's nothing you can do about it but disabling waitvsync and syncrefresh and shoulder with the tearing.

You should always use ddraw with this build. If you run from command line, GroovyMame will use the right options for that specific game, that's why it looks nice, but if you select from Mame's inner frontend then there's a high possibility that the right options are not applying, it could even default to your desktop resolution, etc.

My drivers at the moment are optimized for the H9110 monitor, so most resolutions will be just ok for yours, but a few of them could not match the ones GroovyMame expects to find when the D9800 is selected in Mame.ini. Vertical games like twincobr or donpachi my suffer from that. You could try those games by using the -monitor H9110 option from command line, to see if it works like that. I'm planning to extend my drivers eventually to do all monitor modelines to perfectly match the ones GroovyMame expects, it's only that you are one of the first ones trying this in Windows, I highly appreciate your feedback.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 27, 2011, 07:37:09 am
Hello bitbytebit in the virtual machine is 8 gb hd, and the real machine I have not let the the HD format, otherwise you would lose all roms ;)

df -hT

sda3 ext4 6.9gb /
sda1 ext2 107mb /boot
udev devtmpfs 10mb /dev
shm tmpfs 504 /dev/shm

cat fstab

label=/GA       /     ext4 noatime
label=Gahome        /home    ext4 noatime (booting error, but rather the system load)
shm /dev/shm tmpfs
label=SwapSpace none swap
I've seen some more issues, and it's odd but basically I now agree that there shouldn't be a /home/ partition and just / /boot and then possibly /home/roms.  I am finding that in the virtualbox VM an 8 gig partition is too tricky to divide up between / and /home, if the / drive is 4 gig the install fails, even though it shouldn't and doesn't take up 4 gig to install.  So I'm just giving up on that, and it's easier to keep things simpler like you've thought.    I think part of the issue, from what I can tell, the virtual disk drives in the VM are not able to fully hold capacity so my 4 gig virtual drive only held 2.4 gig of data or something like that.  I'm still not sure why, and doing some tests now with the changes to make sure, but seems like that was the issue with an 8 gig drive (and with my fixed setup, the current ISO definitely will fail on 8 gig drives or less still).

Hopefully I have new ISO's in the next day or two with these changes, plus the improved install without asking about settings if you've already set them.

If you are able, you can always checkout/git the gasetup directory from git and boot the live cd, do `rm /opt && cp -rpda /mnt/livecd/opt /` then copy it into /opt/gasetup, to basically update the gasetup with the current ISO before running Install.  This is what I do to test, so don't have to burn new ISO's over and over and can work on the setup script much quicker.  Really the only script/file in there that changes is /opt/gasetup/core/procedures/interactive so if you get that from the git repository then can just copy it over, the /opt directory normally on the CD is non-writable and just a symlink to /mnt/livecd/opt/ so that's why you have to do the rm /opt trick above and copy it over into the in-ram tmpfs file system.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 27, 2011, 08:13:40 am
Ok, if I have time proves it, but it is difficult because the arcade where I have no internet.

I've seen that you have not changed the value of the joystick_dead_zone in mame source code, it would be interesting to see if it makes everything
work well.

Code: [Select]
{ "joystick_deadzone;joy_deadzone;jdz",      "0.3",  0,          "center deadzone range for joystick where change is ignored (0.0 center, 1.0 end)" },
Since the version you changed the value of the joystick? is to see whether related or not that change, since the problem was from the version 1.151.




Thank.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 27, 2011, 08:23:26 am
Ok, if I have time proves it, but it is difficult because the arcade where I have no internet.

I've seen that you have not changed the value of the joystick_dead_zone in mame source code, it would be interesting to see if it makes everything
work well.

Code: [Select]
{ "joystick_deadzone;joy_deadzone;jdz",      "0.3",  0,          "center deadzone range for joystick where change is ignored (0.0 center, 1.0 end)" },
Since the version you changed the value of the joystick? is to see whether related or not that change, since the problem was from the version 1.151.


At the end you could not include Openppjoy, no?

Thank.

It should be the same as setting it in mame.ini, either way in the source or in the config it won't be different.  What is the best option that works there, setting it in mame.ini?

Yeah I need to do that still, haven't gotten around to it but I'll look at it.  Right now am focusing the time I have on this installation setup, figure adding extra stuff will come later when we get the install fully nailed down and work up from there. 

I'm building/and uploading ISO's in the next day, so the basic installation fixes and they will have fixes for the ATI 9200/9250 cards that aren't AVGA based.  I need to look at a way to make an upgrade/update path when installing a new version over an old version, but after that if nothing else comes up may be able to start looking at the different joystick type options to add. 

Thanks
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on March 27, 2011, 09:00:43 am
My drivers at the moment are optimized for the H9110 monitor, so most resolutions will be just ok for yours, but a few of them could not match the ones GroovyMame expects to find when the D9800 is selected in Mame.ini. Vertical games like twincobr or donpachi my suffer from that. You could try those games by using the -monitor H9110 option from command line, to see if it works like that. I'm planning to extend my drivers eventually to do all monitor modelines to perfectly match the ones GroovyMame expects, it's only that you are one of the first ones trying this in Windows, I highly appreciate your feedback.


quick update:

i've now got donpachi syncing without having to adjust the h-hold, but part of the screen is missing at the top and bottom, probably about an inch and a half both ends...

when i tried it with the h9110 switch, it fitted the screen perfectly!

i'm loving this!  may eventually be able to lock down the control panel and never have to touch the h/v knobs again!
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 27, 2011, 09:42:52 pm
Groovy Arcade Linux fixes for the ATI Radeon 9200/9250 cards in 15khz modes, with lower dotclocks.  Also some other good fixes, turns out the vbios in these cards needed one setting changed to make those lower dotclocks work correctly...

http://forum.arcadecontrols.com/index.php?topic=107620.msg1172781#msg1172781 (http://forum.arcadecontrols.com/index.php?topic=107620.msg1172781#msg1172781)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on March 28, 2011, 01:27:23 pm
hi bitbytebit, can you explain how to perform the quote below, and will it work on a 4350 card or is it radeon only?

"Windows SwitchRes compile will dynamically create modelines for Radeon
  cards.  You need Soft15khz by SailorSat and create a list of "dummy modelines" with
  the usermodes option, up to 60 (more than 16 needed to reload dynamically)."

Other questions:

Is 60 the limit due to Hyperspin no longer launching?

Regards...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 28, 2011, 01:35:44 pm
hi bitbytebit, can you explain how to perform the quote below, and will it work on a 4350 card or is it radeon only?

"Windows SwitchRes compile will dynamically create modelines for Radeon
  cards.  You need Soft15khz by SailorSat and create a list of "dummy modelines" with
  the usermodes option, up to 60 (more than 16 needed to reload dynamically)."

Other questions:

Is 60 the limit due to Hyperspin no longer launching?

Regards...

Well, actually that quote is a bit old now, better use the soft supplied with my hacked drivers if using GroovyMame. 60 is the limit of normal Catalyst. Hyperspin will launch with around 100 video modes defined, I've seen it launching with 160, others need a lower figure, it's actually a bug it seems and it depends on the system. If you're using my hacked drivers, better edit your VMMaker.ini file in the download folder and look for the "TotalModes" value and modify it to a lower value (make sure to also disable the option "GenerateInis" as you don't want to do that if using GroovyMame), then run VMMaker, restart your system. This way you'll still have a GroovyMame compatible mode list but somewhat shorter, to allow Hyperspin to work.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on March 28, 2011, 03:05:09 pm
great stuff, i'll give this a bash later...

also, i have been unable to get hiscore support to work with groovymame.  i can see it is enabled in the .ini, but it just will not work for me.

i've even compiled a fresh mame and it works perfectly, then when i switch back to groovymame, it no longer works.  i'm stumped!

sorry to go off topic...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on March 28, 2011, 04:18:21 pm
Well, actually that quote is a bit old now, better use the soft supplied with my hacked drivers if using GroovyMame. 60 is the limit of normal Catalyst. Hyperspin will launch with around 100 video modes defined, I've seen it launching with 160, others need a lower figure, it's actually a bug it seems and it depends on the system. If you're using my hacked drivers, better edit your VMMaker.ini file in the download folder and look for the "TotalModes" value and modify it to a lower value (make sure to also disable the option "GenerateInis" as you don't want to do that if using GroovyMame), then run VMMaker, restart your system. This way you'll still have a GroovyMame compatible mode list but somewhat shorter, to allow Hyperspin to work.


i had to reduce it to 80 to get it to launch hyperspin, but it's all really starting to take shape.  hopefully i'll be able to close the lid soon and start to enjoy my cabinet!

i noticed in the wmmaker.ini file, the hyperspin tolerance levels were much higher for the 6.5 driver.  what benefits, if any, are there of using the 9.3 driver over that one?

also, one final question:

1. i scrolled through the list of games in hyperspin quickly, launching about 50 games.  i'm very happy with the way they are all displayed and how they look, EXCEPT vertical shooters, like donpachi and stikers 1945 won't sync (same issue as before), but this time, as i'm not using command line, i can't think of a way to get them to run inside hyperspin...

can i adjust the vmmaker.ini to make modelines for these types of games?  i am a vertical shooter fan, and these will be my main focus of attention once up and running...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 28, 2011, 05:22:26 pm
Hopefully soon I'll have VMMaker ready for multisync monitors, I'm seeing it's a must have.

Vertical shooters are my favourite games too. It's possible to do what you want for vertical shooters now, although a bit complicated, as you'll need to manually add the needed modeline. You can get it by running the game with the Linux live-cd, launching it from the command line with -v -v -v -v params and copying it (you might do that also in Windows but I'm not sure it will prompt the right one for not being installed in the system). Then add that line to the modelines.txt file produced by VMMaker, and run Soft-15khz using this modelines.txt file as the custom resolution file, that will install the old modelines plus the new one. I see that it would be a nice option to have VMMaker allow for raw modelines by now.

Unfortunately version 6.5 won't support your 4350 card, it's for older cards only. I'd wait until Hyperspin is fixed, you can use some simple frontend AdvMenu by now, 80 is just too low to get a good experience imho.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 28, 2011, 10:01:42 pm
great stuff, i'll give this a bash later...

also, i have been unable to get hiscore support to work with groovymame.  i can see it is enabled in the .ini, but it just will not work for me.

i've even compiled a fresh mame and it works perfectly, then when i switch back to groovymame, it no longer works.  i'm stumped!

sorry to go off topic...
You'll need the hiscore.dat file in the hi directory, it doesn't set in the local current working directory for groovymame.  I put it there so it's in a fixed location, makes it work in both Linux and Windows the same that way and I like the hiscore.dat file being in the same place as the hi scores.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 28, 2011, 10:19:14 pm

This project really needs its own subforum.

I havnt found any documentation on that svga monitor i mentioned earlier, but so far trying to run games at 649x480 and stretching has been less than ideal.

Would it be reasonable to generate modelines from SailorSat's 15khz list and double the HxV so long as it doesn't go over 600 lines?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 28, 2011, 10:52:05 pm

This project really needs its own subforum.

I havnt found any documentation on that svga monitor i mentioned earlier, but so far trying to run games at 649x480 and stretching has been less than ideal.

Would it be reasonable to generate modelines from SailorSat's 15khz list and double the HxV so long as it doesn't go over 600 lines?

I've added a monitor type for this monitor, m2929, next version build 011c will have it.  I'm not sure the values are right for the front porch and stuff, but I just used the ones in that range from the d9800.  This at least should show basically what the monitor can do, and if any results are better.  It'll try to use doublescan if possible and it has too for those resolutions.

Basically calculating with switchres using the -mrange 30000.00-40000.00,47.00-90.00,0.636,3.813,1.906,0.020,0.106,0.607,0,0,576.0,768 argument is what I did, but it's built in now to groovymame (haven't got it so it can take dynamic ranges like switchres can, yet).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 29, 2011, 05:40:30 am
Cool.

I'm surprised I haven't found more information on this monitor yet since it's the one that XArcade is selling on their site. Maybe I'm not looking in the right places.

One thing I was trying to ask in the previous post, which wasn't very clear, was that I'm asking about the available resolutions on the computer... for groovymame/switchres to select from to modify. At the moment I've only got 640x480, 720x576, 848x480, and 800x600.

What I'm asking about is taking the modes like:
Code: [Select]
240 x 240
256 x 240
256 x 256
256 x 264
304 x 240
321 x 240
321 x 256
336 x 240
352 x 256
352 x 264
352 x 288
368 x 240
384 x 288
392 x 240
401 x 256
448 x 240

and doubling them to
Code: [Select]
480 x 480
512 x 480
512 x 512
512 x 528
608 x 480
642 x 480
642 x 512
672 x 480
704 x 512
704 x 528
704 x 576
736 x 480
768 x 576
784 x 480
802 x 512
896 x 480

Is there any reason that wouldn't work?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 29, 2011, 06:11:32 am
Quote
Is there any reason that wouldn't work?

Actually that should work, the only problem by now is that you'll have to do that manually as our tools don't support that yet.

I think it's a good idea to have that, as unfortunately Windows Catalyst drivers have a problem with doublescan in custom modes that makes it unusable. What I mean is that usually, for a svga monitor, the ortodox workaround would be to enable doublescan for those modes, so scaling wouldn't be needed.

So, for 240x240 you would enable 240x240 doublescanned, that uses the same framebuffer, but it's the videocard the one responsible for doubling each line producing a 31Khz mode.

But having our doublescan broken, your approach can be the right way to go, as it will benefit from Mame's automatic scaling for resolutions that are integer multiples of the target one.

In order to have that ready and automatic, I'll need to implement some new options in VMMaker, and probably at the same time GroovyMame will need to be tweaked to search for those double resolutions when required.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 29, 2011, 06:34:56 am
I was just trying to use Soft15kHz to insert the following modelines:
Code: [Select]
Modeline "352x256@60d" 14.31 352 384 408 440 256 261 264 269 doublescan
Modeline "256x240@60d" 10.31 256 288 304 336 240 245 248 253 doublescan
Modeline "240x240@60d" 9.79 240 272 288 320 240 245 248 253 doublescan
Modeline "256x256@60d" 11.00 256 288 304 336 256 261 264 269 doublescan
Modeline "256x264@61d" 11.40 256 288 304 336 264 269 272 278 doublescan
Modeline "304x240@61d" 11.86 304 336 352 384 240 245 248 253 doublescan
Modeline "320x240@61d" 12.37 320 352 368 400 240 245 248 253 doublescan
Modeline "320x256@60d" 13.21 320 352 376 408 256 261 264 269 doublescan
Modeline "336x240@60d" 12.89 336 368 392 424 240 245 248 253 doublescan
Modeline "352x256@60d" 14.31 352 384 408 440 256 261 264 269 doublescan
Modeline "352x264@60d" 14.82 352 384 408 440 264 269 272 278 doublescan
Modeline "352x288@60d" 16.25 352 384 408 440 288 294 297 303 doublescan
Modeline "368x240@60d" 13.92 368 400 424 456 240 245 248 253 doublescan
Modeline "384x288@60d" 17.50 384 416 448 480 288 294 297 303 doublescan
Modeline "368x240@60d" 13.92 368 400 424 456 240 245 248 253 doublescan
Modeline "384x288@60d" 17.50 384 416 448 480 288 294 297 303 doublescan
Modeline "392x240@60d" 14.69 392 424 448 480 240 245 248 253 doublescan
Modeline "400x256@60d" 15.96 400 432 456 488 256 261 264 269 doublescan
Modeline "416x312@60d" 20.42 416 448 480 512 312 318 321 328 doublescan
Modeline "448x240@60d" 16.50 448 480 504 536 240 245 248 253 doublescan
Modeline "512x240@60d" 18.56 512 544 576 608 240 245 248 253 doublescan
Modeline "512x288@60d" 22.50 512 544 584 616 288 294 297 303 doublescan
Modeline "632x264@60d" 24.79 632 664 704 736 264 269 272 278 doublescan
Modeline "640x240@60d" 22.68 640 672 712 744 240 245 248 253 doublescan
Modeline "640x288@60d" 27.50 640 672 720 752 288 294 297 303 doublescan
Modeline "512x488@60" 20.08 512 544 616 648 488 498 503 513
Modeline "512x512@60" 21.19 512 544 624 656 512 522 527 538
Modeline "640x480@60" 24.11 640 672 760 792 480 490 495 505
Modeline "720x480@60" 26.85 720 752 848 880 480 490 495 505
Modeline "800x600@60" 38.21 800 832 976 1008 600 612 618 631

Didn't seem to work. I guess I'll go with my original idea of doubling the dimensions and trying that.

Edit: Added -hsync -vsync to the end of the lines and now windows locks on bootup. Restarted in safe mode, used the registry backups, and windows still crashes on boot. Whoops.
Guess it's time to reinstall the drivers.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 29, 2011, 09:42:01 am
Hello, report the new version 1.536.

Installation with automatic partitioning, make the partitions, boot root and swap, not create home gives no errors on startup pc.

Installation with the partitions created, Razia home swap roms and it works well, but not in the installation asks for the partition of home.
Then it can indicate the option of saving state, but not included in the fstab.

Once installed you can not change the roms and home partitions, not loaded on the fstab.

I think you should return to the previous state of partitions, as it was much lighter and works better, you could create a new paragraph to make an automatic partitioning for a simple installation, we note that with this facility shall formatting when you want to install a new version .

With respect to the static network configuration does not configure the network mask, you could force to include / 24.

Wminput Cwiid fails axasi duplicate what I have now no hand where the error was after I tell you.

Cwiid wminput continues with the same problem, move the character, the error does suck to automatically configure the joystick, one solution I could find is remap the arrow keys.

Since you have included live version of mame u3? or changes have you made ​​to the live version from 1500?

Other colleagues have already tried the ati 9250 and it works fine, I've tried the avga 9250 time without problems, then try to prove the ati 7000.

I hope these comments help you, if it were so or not see it necessary to tell me.


Thank
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 29, 2011, 11:18:50 am
Hello, report the new version 1.536.

Installation with automatic partitioning, make the partitions, boot root and swap, not create home gives no errors on startup pc.

Installation with the partitions created, Razia home swap roms and it works well, but not in the installation asks for the partition of home.
Then it can indicate the option of saving state, but not included in the fstab.

Once installed you can not change the roms and home partitions, not loaded on the fstab.

I think you should return to the previous state of partitions, as it was much lighter and works better, you could create a new paragraph to make an automatic partitioning for a simple installation, we note that with this facility shall formatting when you want to install a new version .

With respect to the static network configuration does not configure the network mask, you could force to include / 24.

Wminput Cwiid fails axasi duplicate what I have now no hand where the error was after I tell you.

Cwiid wminput continues with the same problem, move the character, the error does suck to automatically configure the joystick, one solution I could find is remap the arrow keys.

Since you have included live version of mame u3? or changes have you made ​​to the live version from 1500?

Other colleagues have already tried the ati 9250 and it works fine, I've tried the avga 9250 time without problems, then try to prove the ati 7000.

I hope these comments help you, if it were so or not see it necessary to tell me.


Thank

I might need to recompile the cwiid stuff with the newer kernel, guessing that could be an issue when updating the kernel.

The home partition and roms partition setup are something that I'll look at when figuring out how to make upgrading smoother.  Right now I like the /boot and / partition setup.  I'll look at the manual partition setup, since it should be smoother than it sounds.  I basically see the /home/arcade and /home/roms directories as when setup should allow upgrading by not touching those on an upgrade.  So I'll add a method where probably a person can just say upgrade at the main menu and it'll reinstall everything and save those 2 partitions.  The old method required people to know too much about partitioning, but the new method does need to have a way to setup the structure of fstab and partitions for installation which were made in cfdisk if not doing automatic partitioning.  Right now it should, if no automatic partitioning is chosen, just use a / drive and do it the old way.  Although I see that the swap might not happen, and some other issues.  So definitely the automatic partitioning has set back the manual partitioning somewhat, although I like the automatic partitioning because otherwise it starts getting really tricky to know how to upgrade and what exactly the partition layout is.  It's easier to just know that a drive is completely dedicated and how that drive is divided up.  It is lacking the /home/arcade partition support without manually doing it though, well it should work in theory but might not yet, and that is a key for upgrading capabilities. 

I'll look at the network setup for a static IP, I probably forgot to ask about the network subnet. 

The newer mame build, just has changes to the patch for the same 141u3 version to automatically detect the video card output connector name, so it's no longer needed in mame.ini. 

I'm curious about other ATI cards now, definitely will be interesting, some might just never work if they don't now, like more older odd exotic ones, but it all depends on feedback/logs bug reports on them and luck with the Linux Kernel ATI guy Alex and if he can see what is going on with them himself.  Hopefully more work now though, because the changes that fix the 9200 cards might just also fix those other older ATI cards too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 29, 2011, 02:16:49 pm
Went ahead and generated a 2X table of SailorSat's 15kHz table:

Code: [Select]
Modeline "704x512@60" 28.26 704 736 840 872 512 522 527 538
Modeline "512x480@60" 19.72 512 544 616 648 480 490 495 505
Modeline "480x480@60" 18.63 480 512 576 608 480 490 495 505
Modeline "512x512@60" 21.19 512 544 624 656 512 522 527 538
Modeline "512x528@60" 21.96 512 544 624 656 528 538 544 555
Modeline "608x480@60" 23.01 608 640 720 752 480 490 495 505
Modeline "640x480@60" 24.11 640 672 760 792 480 490 495 505
Modeline "640x512@60" 25.90 640 672 768 800 512 522 527 538
Modeline "672x480@60" 25.20 672 704 792 824 480 490 495 505
Modeline "704x512@60" 28.26 704 736 840 872 512 522 527 538
Modeline "704x528@60" 29.28 704 736 840 872 528 538 544 555
Modeline "704x576@60" 32.34 704 736 856 888 576 587 593 605
Modeline "736x480@60" 27.39 736 768 872 904 480 490 495 505
Modeline "768x576@60" 35.03 768 800 928 960 576 587 593 605
Modeline "784x480@60" 29.04 784 816 920 952 480 490 495 505
Modeline "768x576@60" 35.03 768 800 928 960 576 587 593 605
Modeline "736x480@60" 27.39 736 768 872 904 480 490 495 505
Modeline "800x512@60" 31.79 800 832 952 984 512 522 527 538
Modeline "832x624@60" 41.47 832 864 1016 1048 624 637 643 656
Modeline "896x480@60" 32.87 896 928 1048 1080 480 490 495 505
Modeline "1024x480@60" 37.26 1024 1056 1192 1224 480 490 495 505
Modeline "1024x576@60" 45.81 1024 1056 1224 1256 576 587 593 605
Modeline "1264x528@60" 50.63 1264 1296 1488 1520 528 539 544 555
Modeline "1280x480@60" 46.02 1280 1312 1480 1512 480 490 495 505
Modeline "1280x576@60" 56.59 1280 1312 1520 1552 576 587 593 605
This uses the methods over at http://xtiming.sourceforge.net/cgi-bin/xtiming.pl, (http://xtiming.sourceforge.net/cgi-bin/xtiming.pl,) using it's default values of Horizontal Sync Time of 3.8 microseconds and VST of 150 microseconds.

I'll dump these into usermodes.txt after I reinstall the video drivers. Sure is easier to fix that when you can boot into safemode and see something :P
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 29, 2011, 02:39:51 pm
I'll dump these into usermodes.txt after I reinstall the video drivers. Sure is easier to fix that when you can boot into safemode and see something :P

Your Catalyst registry must have got messed at some point when adding modes. It could also have happened that you're added more than 128 modes, that can make the drivers crash at startup. It is possible to repair it without reinstalling the driver, by manually editing the registry and deleting all instances of these keys: DALNonStandardModes, DALDTMCRTBCD and probably DALR6 CRT. I see it will help to eventually have an option to do this automatically in case of emergency. Hopefully soon I'll have my program modified to help you guys add modelines more easily... it actually does right now but only for standard arcade monitors, it seems most people here own really fancy crts :)
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 29, 2011, 03:54:09 pm
I'll dump these into usermodes.txt after I reinstall the video drivers. Sure is easier to fix that when you can boot into safemode and see something :P

Your Catalyst registry must have got messed at some point when adding modes. It could also have happened that you're added more than 128 modes, that can make the drivers crash at startup. It is possible to repair it without reinstalling the driver, by manually editing the registry and deleting all instances of these keys: DALNonStandardModes, DALDTMCRTBCD and probably DALR6 CRT. I see it will help to eventually have an option to do this automatically in case of emergency. Hopefully soon I'll have my program modified to help you guys add modelines more easily... it actually does right now but only for standard arcade monitors, it seems most people here own really fancy crts :)


I'm sure they did. But I only added the above listed modes, around 25 or so. Personally uninstalling/reinstalling the video driver sounds much simpler than editing the registry that much... Doing the drivers will take at most a few clicks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: ves on March 29, 2011, 06:15:18 pm
Hello bitbytebit, the error in CWID wminput axi duplicate, deleting these lines is resolved.

mamebuttons
Code: [Select]
Classic.LStick.X = ABS_X
Classic.LStick.Y = ~ABS_Y


I confirm that ATI 7000 works well, tested with dragon ball 1 and 2, donkey kong, pacman, 1942, Golden Axe 2, 1000 migl, 1942, toki, esprade etc. ..

I need to try several graphs that have left more ati x1300 fx5000.


You could try the games ghost chasel, it has a resolution problems or strange, if it's not mame or the resolution.



Thanks.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 30, 2011, 05:39:45 am
I probably need to branch this to a new thread, but I'll still ask--

With the doubled modelines I posted above, Soft15kHz was able to add them no problem and the monitor seems to display them just fine EXCEPT for the right most edge of the screen. On almost every mode the first several dozen pixels of a line are 'curled' back onto themselves, even on modes that should be no issue like 640x480. Previously with the default values that resolution displayed just fine.

Is this a modeline issue or a monitor issue?


Edit: It must be a modeline issue; I installed Calamity's driver and ran VMMaker, and it's modes do not exhibit the issue.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 30, 2011, 07:45:41 am
With the doubled modelines I posted above, Soft15kHz was able to add them no problem and the monitor seems to display them just fine EXCEPT for the right most edge of the screen. On almost every mode the first several dozen pixels of a line are 'curled' back onto themselves, even on modes that should be no issue like 640x480. Previously with the default values that resolution displayed just fine.

That usually happens when the front porch is too short, the right side of the picture folds back as the beam returns to the origin, I'd try using more generous porches.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on March 30, 2011, 09:51:19 am
Hopefully soon I'll have VMMaker ready for multisync monitors, I'm seeing it's a must have.

Vertical shooters are my favourite games too. It's possible to do what you want for vertical shooters now, although a bit complicated, as you'll need to manually add the needed modeline. You can get it by running the game with the Linux live-cd, launching it from the command line with -v -v -v -v params and copying it (you might do that also in Windows but I'm not sure it will prompt the right one for not being installed in the system). Then add that line to the modelines.txt file produced by VMMaker, and run Soft-15khz using this modelines.txt file as the custom resolution file, that will install the old modelines plus the new one. I see that it would be a nice option to have VMMaker allow for raw modelines by now.

Unfortunately version 6.5 won't support your 4350 card, it's for older cards only. I'd wait until Hyperspin is fixed, you can use some simple frontend AdvMenu by now, 80 is just too low to get a good experience imho.


it was too complicated unfortunately... my linux experience is limited to installing ubuntu a couple of times to see what the fuss was about.

i did manage to get the live cd installed onto a separate hard drive to try and mess about with it, but struggled to find a way to change the rompath once it was installed.  i was able to run the few roms that come bundled, and they all seemed to play fine.  i know there was an option during the install to point to the rom folder, but the warning about the possibility of deleting data spooked me a bit.

just out of interest, before i browse through the soft15khz thread again, do you know is there a maximum number of modelines it will accept?

one other point while i'm going to be tinkering - my chassis is a wei-ya 3129db.  i think it's pretty common, and i was wondering what values, if any, you would recommend changing in the vmmaker.ini file.  the sticker on the chasis states:

H-Freq: 15/24/31khz
V-Freq: 47-70hz

i googled your monitor, and see that you have set the vertical frequencies slightly inside what the limits are for that monitor, so i was wondering if you'd advise against me setting those values to 47-70 in the .ini file...

regards
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on March 30, 2011, 10:25:01 am
Hopefully soon I'll have VMMaker ready for multisync monitors, I'm seeing it's a must have.

Vertical shooters are my favourite games too. It's possible to do what you want for vertical shooters now, although a bit complicated, as you'll need to manually add the needed modeline. You can get it by running the game with the Linux live-cd, launching it from the command line with -v -v -v -v params and copying it (you might do that also in Windows but I'm not sure it will prompt the right one for not being installed in the system). Then add that line to the modelines.txt file produced by VMMaker, and run Soft-15khz using this modelines.txt file as the custom resolution file, that will install the old modelines plus the new one. I see that it would be a nice option to have VMMaker allow for raw modelines by now.

Unfortunately version 6.5 won't support your 4350 card, it's for older cards only. I'd wait until Hyperspin is fixed, you can use some simple frontend AdvMenu by now, 80 is just too low to get a good experience imho.

it was too complicated unfortunately... my linux experience is limited to installing ubuntu a couple of times to see what the fuss was about.

i did manage to get the live cd installed onto a separate hard drive to try and mess about with it, but struggled to find a way to change the rompath once it was installed.  i was able to run the few roms that come bundled, and they all seemed to play fine.  i know there was an option during the install to point to the rom folder, but the warning about the possibility of deleting data spooked me a bit.  i have a batch of sample roms, including a few vertical shooters on a usb drive, but i don't know how to get the linux install to point to it...

just out of interest, before i browse through the soft15khz thread again, do you know is there a maximum number of modelines it will accept?

one other point while i'm going to be tinkering - my chassis is a wei-ya 3129db.  i think it's pretty common, and i was wondering what values, if any, you would recommend changing in the vmmaker.ini file.  the sticker on the chasis states:

H-Freq: 15/24/31khz
V-Freq: 47-70hz

i googled your monitor, and see that you have set the vertical frequencies slightly inside what the limits are for that monitor, so i was wondering if you'd advise against me setting those values to 47-70 in the .ini file...

regards
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 30, 2011, 11:08:38 am
just out of interest, before i browse through the soft15khz thread again, do you know is there a maximum number of modelines it will accept?

The limit is set by the driver, not by the program that stores the modelines in the driver's registry (Soft-15Khz, VMmaker, Winmodelines, etc.). However, regular Catalyst only accept up to 60 modes.

one other point while i'm going to be tinkering - my chassis is a wei-ya 3129db.  i think it's pretty common, and i was wondering what values, if any, you would recommend changing in the vmmaker.ini file.  the sticker on the chasis states:

H-Freq: 15/24/31khz
V-Freq: 47-70hz

i googled your monitor, and see that you have set the vertical frequencies slightly inside what the limits are for that monitor, so i was wondering if you'd advise against me setting those values to 47-70 in the .ini file...

regards

You won't be able to produce modelines for a multisync model using VMMaker by now. It only works with a single hfreq range, so all the modelines you're seeing possibly belong to the lower range. I need to move the multisync stuff bitbytebit has done for Switchres into VMMaker, so it can catch up GroovyMame. You could try to calculate each range separately and then use the output with Soft-15Khz, but it's going to be complicated and painful if you haven't done that before. You can also use Switchres to produce those modelines I'm thinking, maybe it's the best option actually, as it can calculate the same modelines GroovyMame uses and prompts them. Another typical way to install those modelines manually is by using Winmodelines.

The problem with all this manual stuff (that has always been there, it's nothing new) is that you won't probably do a rational use of your mode table limited space, which is the main aim of VMMaker.

Hopefully in a week or two I can have something useful already, at the moment I'm collapsed with work and thinking of possibly throwing my phone by the window. All the required stuff to have fully automatic support for GroovyMame and multisync monitors in Windows is in my head already, also working on a graphic user interface for VMMaker that will simplify the process a lot and make it more accesible and easy to understand how each program is tied with the other, I admit that now it's a mess, just need a little time.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 30, 2011, 11:17:20 am
With the doubled modelines I posted above, Soft15kHz was able to add them no problem and the monitor seems to display them just fine EXCEPT for the right most edge of the screen. On almost every mode the first several dozen pixels of a line are 'curled' back onto themselves, even on modes that should be no issue like 640x480. Previously with the default values that resolution displayed just fine.

That usually happens when the front porch is too short, the right side of the picture folds back as the beam returns to the origin, I'd try using more generous porches.


I used your VMMaker with the values from my monitor (30-40 hfreq, 40-90 vfreq), set a minimum resolution of 480x480 and let it run. Came up with around 25 or so resolutions, and added them to the registry. The lines generated by your program did not have the curl over. I didn't know appropriate frontporch numbers for the generator I used, so I used the default.

However when I rebooted there were still several entries in the QuickRes list that were unwanted (either too low like 320x240, or too high like 1280x1024). Any idea on how to remove those?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 30, 2011, 12:16:38 pm
I used your VMMaker with the values from my monitor (30-40 hfreq, 40-90 vfreq), set a minimum resolution of 480x480 and let it run. Came up with around 25 or so resolutions, and added them to the registry. The lines generated by your program did not have the curl over. I didn't know appropriate frontporch numbers for the generator I used, so I used the default.

The ReslList.txt file is used as a manual resolution source (vs or + Mame.xml), so edit that file if you want to add any desired modeline to be generated. Default porch values should be safe enough for most arcade monitors and tv sets. It's the hfreq/vfreq range where the important decisions are based on, as well as the ActiveLinesLimit/VirtualLinesLimit pair.

However when I rebooted there were still several entries in the QuickRes list that were unwanted (either too low like 320x240, or too high like 1280x1024). Any idea on how to remove those?

You don't need to remove those resolutions actually, they're default native vesa modes the driver creates, and can be handy to have them there just in case you need to plug an LCD to fix things. I'd use Arcade_OSD instead of Quickres, it will show you which of these modes are actually custom modes created by VMMaker and which are native modes. GroovyMame with the modeline option will only pick modes from the custom created ones so they won't get mixed.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 30, 2011, 03:04:19 pm
The ReslList.txt file is used as a manual resolution source (vs or + Mame.xml), so edit that file if you want to add any desired modeline to be generated. Default porch values should be safe enough for most arcade monitors and tv sets. It's the hfreq/vfreq range where the important decisions are based on, as well as the ActiveLinesLimit/VirtualLinesLimit pair.

What should I base the active/virtual limits on? I set 600/600 since that's the maximum lines the default specs for the monitor list (800x600).


You don't need to remove those resolutions actually, they're default native vesa modes the driver creates, and can be handy to have them there just in case you need to plug an LCD to fix things. I'd use Arcade_OSD instead of Quickres, it will show you which of these modes are actually custom modes created by VMMaker and which are native modes. GroovyMame with the modeline option will only pick modes from the custom created ones so they won't get mixed.

If groovy mame will not be selecting them, then it won't be an issue.

bitbytebit:
Since I'm aiming for the system to scale everything 2x to fill the screen, how exactly do I need to have Groovymame configured? You had mentioned including d2929 into the newest build, is that posted yet?

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 30, 2011, 03:49:42 pm
What should I base the active/virtual limits on? I set 600/600 since that's the maximum lines the default specs for the monitor list (800x600).

Use 600/601, that means all modes until 600 included will be progressive, and from 601 on they'll be calculated as interlaced (probably none).

GroovyMame won't select your x2 scaled resolutions automatically, you'll need to manually create an ini for each game by now, unfortunately. No extra option should be needed appart from the resolution, Mame should scale it if your resolution is a multiple (I might be wrong!).
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 30, 2011, 04:58:10 pm
If I already have .inis per game set up for controls and what not, will it append/update, or overwrite?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on March 30, 2011, 05:16:40 pm
It will overwrite them! Be careful. But I didn't mean you used VMMaker to generate the inis by now, the logic you need for those inis is not implemented either in VMMaker or Switchres, that's why you'd need to make them manually, doing that will involve a lot of pain in my opinion, it's a madness, you could create several ones for testing only.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 30, 2011, 09:14:42 pm
yeah i duplicated my ini folder and noticed that vmmaker's ini's all set most of them to my lowest specified res of 480x480.

I suppose I'll go back to my custom generated modeline list and tinker with the frontporch.

Ironically using VMMaker most of the modes generated I couldn't get to stretch all the way across the monitor, even ones that could using mine that curled over. I guess it's using too conservative of values?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 31, 2011, 12:58:41 am
The ReslList.txt file is used as a manual resolution source (vs or + Mame.xml), so edit that file if you want to add any desired modeline to be generated. Default porch values should be safe enough for most arcade monitors and tv sets. It's the hfreq/vfreq range where the important decisions are based on, as well as the ActiveLinesLimit/VirtualLinesLimit pair.

What should I base the active/virtual limits on? I set 600/600 since that's the maximum lines the default specs for the monitor list (800x600).


You don't need to remove those resolutions actually, they're default native vesa modes the driver creates, and can be handy to have them there just in case you need to plug an LCD to fix things. I'd use Arcade_OSD instead of Quickres, it will show you which of these modes are actually custom modes created by VMMaker and which are native modes. GroovyMame with the modeline option will only pick modes from the custom created ones so they won't get mixed.

If groovy mame will not be selecting them, then it won't be an issue.

bitbytebit:
Since I'm aiming for the system to scale everything 2x to fill the screen, how exactly do I need to have Groovymame configured? You had mentioned including d2929 into the newest build, is that posted yet?


It's in the newest builds, its 'm2929' for that monitor model name/number that you have.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: torino on March 31, 2011, 07:36:04 am
So this software beside authentic resolutions can also set all those refresh rates which are not exactly 60Hz, like Galaga: 224x288 @ 60.606061Hz, right? Is that X-windows based application, and so does it use desktop video drivers, or can it perhaps work without X-windows from the console via VESA or frame-buffer drivers maybe? If it only works with X-windows, does it then only work in some 'full-screen" mode or maybe the whole X-windows desktop changes to set resolution?

What version and kind of MAME you testing this with?
Is performance better, same or worse than on Windows?

If you can set the exact refresh rates as MAME, then you should have no problems to perfectly sync all those games with monitor V-sync, right? But can you get smooth scrolling and fluid animation even with the latest MAME and what are the important settings to make it all work nicely without any scroll tearing or choppiness, if possible? Finally, can this be used with PC CRT monitors, and are there any similar tool for DOS or Windows?



Thank you.

By the way, do you rememberer "Scitech Display Doctor"?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 31, 2011, 07:58:41 am
So this software beside authentic resolutions can also set all those refresh rates which are not exactly 60Hz, like Galaga: 224x288 @ 60.606061Hz, right? Is that X-windows based application, and so does it use desktop video drivers, or can it perhaps work without X-windows from the console via VESA or frame-buffer drivers maybe? If it only works with X-windows, does it then only work in some 'full-screen" mode or maybe the whole X-windows desktop changes to set resolution?

What version and kind of MAME you testing this with?
Is performance better, same or worse than on Windows?

If you can set the exact refresh rates as MAME, then you should have no problems to perfectly sync all those games with monitor V-sync, right? But can you get smooth scrolling and fluid animation even with the latest MAME and what are the important settings to make it all work nicely without any scroll tearing or choppiness, if possible? Finally, can this be used with PC CRT monitors, and are there any similar tool for DOS or Windows?



Thank you.

By the way, do you rememberer "Scitech Display Doctor"?

Yep, it can get pretty exact on the refresh rate used by most games in Mame, the more capable the monitor the closer it can get in both horizontal/vertical size and refresh rate. 

There is a Windows version and Linux version, both the same code mostly, but in Windows we have to use registry custom modes like Soft15khz does, limited by amount of custom resolutions a card can accept for height/width but can customize any of those to any refresh rate we need.  It also is right now really only working for 15khz mode with ATI cards, both Linux and Windows, although in Linux might be more capable of other cards. 

It works really well in Linux, decent in Windows, in Linux for X Windows using xrandr and a custom kernel patch and such, you can get very precise resolutions and with a d9800 + ATI card pretty much spot on everything.

In Linux xrandr does all the resolution changing of the X Windows desktop, and can do it quite well.  Performance for me has been better in Linux, others have reported it quite nice there too.  Calamity can comment more on how it works in Windows, but I am guessing in Linux you'll always have a lighter load on the system, although I don't really have any proof of that myself so one would want to test the two side by side themselves to see.

There's no tearing when setup right, everything is smooth scrolling without choppiness, following the vsync of the monitor and and page flipping through interrupts with the ATI cards.  In Linux it is great, in Windows it is quite good too.

The framebuffer in Linux unfortunately isn't really able to do the resolutions like through X windows and xrandr right now, there are quite a few limitations currently in the design of the framebuffer.  Hopefully in the future that will change, something I someday would like to look at.  They basically are hard to get exact dotclocks/pixelclock values, and are mostly limited to either hardwired modes or VESA ones (my patch puts in a few modes for 15khz so bootup/console is good).

It can work with PC CRT and LCD monitors, you might resort to doublescan and other virtualization or other less than optimal stuff, because there's just limitations to those monitors and modelines they can take and display.  I run it in Linux on my LCD for testing sometimes, and can get some pretty nice/interesting results on a 16:9 monitor.  Some games though don't work without a slight change in the width because there's some limitations on those monitors at times with things less than 320 pixels wide.

This all works upon the basic algorithms from Calamity for the modeline calculations, the methods of getting refresh rate changes in the Windows registry for ATI cards without a reboot.  He basically is the one who knew how all this was possible, I've coded it into the mame version 0141u3 + patch currently, a modeline generator switchres and wrapper to other emulators, and a whole Linux distribution based around it with LiveCD capability to allow a person to avoid having to really collect all the  parts in Linux themselves.

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on March 31, 2011, 08:19:28 am
By the way, do you rememberer "Scitech Display Doctor"?

There's a name I haven't heard in ages. I remember playing with it back in the day.. Can't remember what I was trying to do with it though.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: torino on March 31, 2011, 11:59:31 am
So this software beside authentic resolutions can also set all those refresh rates which are not exactly 60Hz, like Galaga: 224x288 @ 60.606061Hz, right? Is that X-windows based application, and so does it use desktop video drivers, or can it perhaps work without X-windows from the console via VESA or frame-buffer drivers maybe? If it only works with X-windows, does it then only work in some 'full-screen" mode or maybe the whole X-windows desktop changes to set resolution?

What version and kind of MAME you testing this with?
Is performance better, same or worse than on Windows?

If you can set the exact refresh rates as MAME, then you should have no problems to perfectly sync all those games with monitor V-sync, right? But can you get smooth scrolling and fluid animation even with the latest MAME and what are the important settings to make it all work nicely without any scroll tearing or choppiness, if possible? Finally, can this be used with PC CRT monitors, and are there any similar tool for DOS or Windows?



Thank you.

By the way, do you rememberer "Scitech Display Doctor"?

Yep, it can get pretty exact on the refresh rate used by most games in Mame, the more capable the monitor the closer it can get in both horizontal/vertical size and refresh rate. 

There is a Windows version and Linux version, both the same code mostly, but in Windows we have to use registry custom modes like Soft15khz does, limited by amount of custom resolutions a card can accept for height/width but can customize any of those to any refresh rate we need.  It also is right now really only working for 15khz mode with ATI cards, both Linux and Windows, although in Linux might be more capable of other cards. 

It works really well in Linux, decent in Windows, in Linux for X Windows using xrandr and a custom kernel patch and such, you can get very precise resolutions and with a d9800 + ATI card pretty much spot on everything.

In Linux xrandr does all the resolution changing of the X Windows desktop, and can do it quite well.  Performance for me has been better in Linux, others have reported it quite nice there too.  Calamity can comment more on how it works in Windows, but I am guessing in Linux you'll always have a lighter load on the system, although I don't really have any proof of that myself so one would want to test the two side by side themselves to see.

There's no tearing when setup right, everything is smooth scrolling without choppiness, following the vsync of the monitor and and page flipping through interrupts with the ATI cards.  In Linux it is great, in Windows it is quite good too.

The framebuffer in Linux unfortunately isn't really able to do the resolutions like through X windows and xrandr right now, there are quite a few limitations currently in the design of the framebuffer.  Hopefully in the future that will change, something I someday would like to look at.  They basically are hard to get exact dotclocks/pixelclock values, and are mostly limited to either hardwired modes or VESA ones (my patch puts in a few modes for 15khz so bootup/console is good).

It can work with PC CRT and LCD monitors, you might resort to doublescan and other virtualization or other less than optimal stuff, because there's just limitations to those monitors and modelines they can take and display.  I run it in Linux on my LCD for testing sometimes, and can get some pretty nice/interesting results on a 16:9 monitor.  Some games though don't work without a slight change in the width because there's some limitations on those monitors at times with things less than 320 pixels wide.

This all works upon the basic algorithms from Calamity for the modeline calculations, the methods of getting refresh rate changes in the Windows registry for ATI cards without a reboot.  He basically is the one who knew how all this was possible, I've coded it into the mame version 0141u3 + patch currently, a modeline generator switchres and wrapper to other emulators, and a whole Linux distribution based around it with LiveCD capability to allow a person to avoid having to really collect all the  parts in Linux themselves.


Thank you. That's great.

Just one thing, I am pretty sure LCDs have truly fixed refresh rates, at exactly 60Hz, so they should not be able to properly sync with games like Galaga running @60.606Hz, or anything else that is not exactly 60Hz. Is that right?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: torino on March 31, 2011, 12:36:28 pm
By the way, do you rememberer "Scitech Display Doctor"?

There's a name I haven't heard in ages. I remember playing with it back in the day.. Can't remember what I was trying to do with it though.

They invented VESA standard. If you ever used DOS you must know "UNIVBE.EXE" - the VESA driver. At the time many video cards in use were without any VESA support, and 'Scitech Doctor' could "cure" those crappy cards and turn them into healthy ones. Sometimes the gain in performances would be really amazing, truly spectacular. In windows, they could get you from 640x480 to 800x600 and above, and it was the only product at the time that could do anything like that, to everyone's surprise. It was miraculous, everyone was using it, and so I find it curious no one remembers it any more. Their SNAP/MGL library is very portable and still in use across many platforms, in mostly embedded devices. You could say Scitech SNAP of yesterday is Trolltech Qtopia of today.

Anyway, beside fast and portable graphic/sound library (kind of like Allegro, only better), there were also many tools to set and test wide range of resolutions, possibly completely arbitrary like this software does, all of which was released later as Open Source. The point is, I believe the pathway (video registers) via which you can set all those resolutions on today's modern video cards is the same one that came along with VESA standard many years ago, so this old library might still prove useful today and in the future, as PC of yesterday is mobile phone of today.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 31, 2011, 01:00:22 pm

Thank you. That's great.

Just one thing, I am pretty sure LCDs have truly fixed refresh rates, at exactly 60Hz, so they should not be able to properly sync with games like Galaga running @60.606Hz, or anything else that is not exactly 60Hz. Is that right?


That figures, I wonder if the LCD monitors that are made for arcade monitor replacements that are 15khz capable might be able to do this, or it's again something that is never going to be as exact.  I definitely have seen more jumpy percentages on the LCD monitor compared to my arcade monitor when using F11 and checking the percentage speed games are running when using the vsync.

I read about that company in Wikipedia that made Scitech display doctor, definitely interesting sounding.  I guess one big issue with video card hardware is that newer ones like the ATI 6xxx series and above are using proprietary register setups compared to the older ones.  I was reading how powerstrip took forever to work with the 5xxx series because of this, and I'm not sure if it even works with newer ones.  So what has happened, like with advanced mame even, is that older video cards definitely can be understood through these types of older programs and methods.  Yet unfortunately video card makers seem to have been closing the doors and altering the standards more and more in recent years from what I can tell.  It still can be figured out, but seems like it takes about the time a chip becomes 1-2 generations out of date/old and it's never the same because the interface is not completely ever worked out to fully exploit the video chips possibilities.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on March 31, 2011, 05:46:15 pm
bitbytebit,

today i bought all the required parts to build a new pc to install inside my cab.  presently, it is being co-used with my main pc, so i'm now ready to hard-install it inside the cab.

i like the fact that the linux version runs pretty much ootb and is currently running better than in windows, so i''m going to attempt to install it in my cab innards.

is there a guide to getting it all setup and running, with the pre-installed front end?

sorry to be a pain, mate...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 31, 2011, 07:23:43 pm
bitbytebit,

today i bought all the required parts to build a new pc to install inside my cab.  presently, it is being co-used with my main pc, so i'm now ready to hard-install it inside the cab.

i like the fact that the linux version runs pretty much ootb and is currently running better than in windows, so i''m going to attempt to install it in my cab innards.

is there a guide to getting it all setup and running, with the pre-installed front end?


It mostly should be automatic if you have an empty non partitioned drive and choose the Install option on the menu.  Looking to make it as easy as possible, but of course it'll take time so any feedback will help get closer to that goal.
sorry to be a pain, mate...

[/quote]
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on March 31, 2011, 07:31:29 pm
my roms currently reside on a windows formatted (ntfs) drive.  if i point the linux install to this folder (when asked for the snap/roms folder), will linux be able to see it?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on March 31, 2011, 07:56:34 pm
my roms currently reside on a windows formatted (ntfs) drive.  if i point the linux install to this folder (when asked for the snap/roms folder), will linux be able to see it?
If you choose it as the Roms/Snaps drive whenthe install asks, it should be able to see it.  If not then we can figure out any remaining issues there.  I made changes that should allow it, not sure if it's been tested, but really it should be somewhat seamless since linux can easily mount ntfs read only, you just won't be able to write to it in linux.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on April 01, 2011, 07:58:45 am
Just another question, I've seen you moved all the monitor values setup for switchres/groovymame into the code itself, so no longer have a switchres.conf file, etc. I'd like to use your values for different monitors in VMMaker, so I can add support for multisync monitors. The idea is that needed resolutions are monitor depending, as in some circunstances GroovyMame will use different resolutions for different monitors, being vertical games the most obvious case, so for instance twincobr will use 576x320 or something like that if set up for D9800, while with my H9110 it will use 720x560 (virtualized). So the prefixed mode table will be different for each monitor case, and for best experience the mode table VMMaker creates and GroovyMame expects should be perfectly synced. So, back to the config thing, I need to add those monitor ranges to my ini file, but maybe it's more convenient to have them built in my code like you do now and leave the ini params for a single custom mode, with four lines for each range, as the format you used to have in switchres.conf, so people can experiment to find the best values for their monitors and eventually add them to the project as built in ones. Having all values in a line is somewhat confusing but as I intend to have a graphical interface in future versions then it will be good to have it like that and maybe use the same format in GroovyMame so it can read the monitor info produced with VMMaker. I'd need to clone your modeline weighting system too so I'm able to guess which range will be used by GroovyMame in order to have the right modeline ready.

EDIT: I remember you had to set sync polarities to 1 for some of your ranges, now it seems they're all 0, but for the multi and vga cases. I'm wondering if this is actually tested for these cases or maybe guessed. In Windows, we'd need to use an extra registry key to account for polarities different to the default negative case, I'd like to think it's not really needed but just wondering.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on April 01, 2011, 08:21:03 am
Just another question, I've seen you moved all the monitor values setup for switchres/groovymame into the code itself, so no longer have a switchres.conf file, etc. I'd like to use your values for different monitors in VMMaker, so I can add support for multisync monitors. The idea is that needed resolutions are monitor depending, as in some circunstances GroovyMame will use different resolutions for different monitors, being vertical games the most obvious case, so for instance twincobr will use 576x320 or something like that if set up for D9800, while with my H9110 it will use 720x560 (virtualized). So the prefixed mode table will be different for each monitor case, and for best experience the mode table VMMaker creates and GroovyMame expects should be perfectly synced. So, back to the config thing, I need to add those monitor ranges to my ini file, but maybe it's more convenient to have them built in my code like you do now and leave the ini params for a single custom mode, with four lines for each range, as the format you used to have in switchres.conf, so people can experiment to find the best values for their monitors and eventually add them to the project as built in ones. Having all values in a line is somewhat confusing but as I intend to have a graphical interface in future versions then it will be good to have it like that and maybe use the same format in GroovyMame so it can read the monitor info produced with VMMaker. I'd need to clone your modeline weighting system too so I'm able to guess which range will be used by GroovyMame in order to have the right modeline ready.

EDIT: I remember you had to set sync polarities to 1 for some of your ranges, now it seems they're all 0, but for the multi and vga cases. I'm wondering if this is actually tested for these cases or maybe guessed. In Windows, we'd need to use an extra registry key to account for polarities different to the default negative case, I'd like to think it's not really needed but just wondering.
 

Yeah, basically groovymame just doesn't have the config option to read new ranges into it, yet, I still need to do that, it actually won't be too hard but I've been lazy :).  Also figured it's less needed, but if lots of people are wanting it now then I can get it done pretty soon.

Basically all the default modelines are all in src/emu/switchres/monitor.c and the weight system in the src/emu/switchres/modeline.c files, sounds good to have the same convention for VMMaker too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on April 01, 2011, 08:34:48 am
Yeah, basically groovymame just doesn't have the config option to read new ranges into it, yet, I still need to do that, it actually won't be too hard but I've been lazy :).  Also figured it's less needed, but if lots of people are wanting it now then I can get it done pretty soon.

TV screen users are reporting problems with prefixed settings, mainly overscan or picture shifted to the right and stuff. In the cases where the problem is common to all modes, then one can easily edit the back porch value for instance and fix all modes with that. Arcade monitors are much more flexible in this area it seems.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on April 01, 2011, 08:53:30 am
Yeah, basically groovymame just doesn't have the config option to read new ranges into it, yet, I still need to do that, it actually won't be too hard but I've been lazy :).  Also figured it's less needed, but if lots of people are wanting it now then I can get it done pretty soon.

TV screen users are reporting problems with prefixed settings, mainly overscan or picture shifted to the right and stuff. In the cases where the problem is common to all modes, then one can easily edit the back porch value for instance and fix all modes with that. Arcade monitors are much more flexible in this area it seems.

Yeah I'm guessing the settings for NTSC/PAL are wrong, if we can get those right probably will fix that, or does that really differ among each TV?  I need to put that configuration option in so people can find the good values, then report them back to us and we can use those from now on.  Probably will do that this weekend and have a new ISO possibly Sunday night I hope, and new groovymame build for Windows with the change. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on April 01, 2011, 05:22:58 pm
my roms currently reside on a windows formatted (ntfs) drive.  if i point the linux install to this folder (when asked for the snap/roms folder), will linux be able to see it?
If you choose it as the Roms/Snaps drive whenthe install asks, it should be able to see it.  If not then we can figure out any remaining issues there.  I made changes that should allow it, not sure if it's been tested, but really it should be somewhat seamless since linux can easily mount ntfs read only, you just won't be able to write to it in linux.

ok, i've tried this via several different methods.  it keeps saying 'no drives are available to use' when i try and point it at my roms folder (on an ntfs drive).

when it comes to installing on the hard drive, it can see the other drive, but it can't see it when it comes to pointing to it regarding the roms folder.

i have tried two separate partitions on the same drive, and two separate hard drives, both give the same results...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on April 01, 2011, 05:43:37 pm
my roms currently reside on a windows formatted (ntfs) drive.  if i point the linux install to this folder (when asked for the snap/roms folder), will linux be able to see it?
If you choose it as the Roms/Snaps drive whenthe install asks, it should be able to see it.  If not then we can figure out any remaining issues there.  I made changes that should allow it, not sure if it's been tested, but really it should be somewhat seamless since linux can easily mount ntfs read only, you just won't be able to write to it in linux.

ok, i've tried this via several different methods.  it keeps saying 'no drives are available to use' when i try and point it at my roms folder (on an ntfs drive).

when it comes to installing on the hard drive, it can see the other drive, but it can't see it when it comes to pointing to it regarding the roms folder.

i have tried two separate partitions on the same drive, and two separate hard drives, both give the same results...

Ah ok, I just hopefully fixed that bug, see now I had been checking for only Linux type partitions in the Data/Roms disk listing.  I'll have new ISO's out sometime this weekend with the fix.

Thanks for helping figure that out, one of the things I forgot to change when trying to make any type of partition type work for the Data/Roms drive.

The other way to do this for now, till it's in the ISO, is browse to the http://system.ip/ (http://system.ip/) interface, login as 'admin' with pwd of 'arcade' and map the drive that way to the /home/roms/ folder on the system.  Make sure you tell it to set the permissions on the drive to allow the arcade user to read it too.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on April 01, 2011, 10:59:28 pm
Yeah, basically groovymame just doesn't have the config option to read new ranges into it, yet, I still need to do that, it actually won't be too hard but I've been lazy :).  Also figured it's less needed, but if lots of people are wanting it now then I can get it done pretty soon.

TV screen users are reporting problems with prefixed settings, mainly overscan or picture shifted to the right and stuff. In the cases where the problem is common to all modes, then one can easily edit the back porch value for instance and fix all modes with that. Arcade monitors are much more flexible in this area it seems.


I just added the custom monitor config option into groovymame, it's -monitor_specs <> with the same syntax as in switchres.  The main difference is that it can only be setup for one range, since in mame I can't give a parameter multiple times and have it store it as an array.  That should be ok though, since right now mostly to fiddle around with the TV settings and more likely a monitor has one range than many, else they are covered already or should be a special case and added in.  I have new builds as 011d for this, possibly you could test it and then have the people with the TV issues try some changes in the front porches and other values to see if things can use better values.  Just use switchres to figure out what the current default settings are for NTSC and PAL, it'll print them out in verbose mode, and work off of those outputs.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on April 02, 2011, 06:39:44 am
bitbytebit,  one other issue i noticed last night - when it comes to installing onto the hard drive, it doesn't recognise a separate partition on the drive, but instead only sees the whole drive, and if there is something already on it, ie. my mame roms on a separate partition, it won't install onto (see) the unpartitioned space...

eg.  i have a 320gb drive, first partition is 50gb, unpartitioned, and the second partition is 250gb, which contains my roms folder (formatted ntfs).

when i choose to install to hard disk, it sees only the 320gb partition, but is unable to install to the first unparitioned space, because the 'partition is not empty', or words to that effect...

maybe you can look into this too...

regards
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on April 02, 2011, 07:03:55 am
bitbytebit,  one other issue i noticed last night - when it comes to installing onto the hard drive, it doesn't recognise a separate partition on the drive, but instead only sees the whole drive, and if there is something already on it, ie. my mame roms on a separate partition, it won't install onto (see) the unpartitioned space...

eg.  i have a 320gb drive, first partition is 50gb, unpartitioned, and the second partition is 250gb, which contains my roms folder (formatted ntfs).

when i choose to install to hard disk, it sees only the 320gb partition, but is unable to install to the first unparitioned space, because the 'partition is not empty', or words to that effect...

maybe you can look into this too...

regards

Yeah that's currently a limitation of how I've done the automatic partitioning, since it becomes a bit more complicated when the drive isn't clean since we then have to move around the partition numbers and may not be able to get the first one for the /boot partition and then grub installation becomes a bit trickier too.  I've been thinking of ways to automate that, but right now it's more of a manual partition task which of course then runs into requiring the knowledge of how to partition the drives.  So I'll get that ability hopefully soon, but it's kind of the next step since It'll change around how I do things somewhat and there are a few issues to figure out there.

Good news is I have ISO's uploading with the NTFS fix, hopefully I got it working now, I at least removed the part that ignores them on the partition search and it shouldn't say no drives available anymore.  Should be done uploading hopefully in a few hours, will post when they are done.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on April 02, 2011, 09:09:58 am
This should hopefully allow NTFS drives to be used now for Roms/Snaps, report any issues if there's remaining bugs.  Monitor specs are now able to be customized, but you'll need to know the right format from switchres to pass to the new -monitor_specs option in groovymame...

02042011 - 1.546 Release
         - Added new option to groovymame named -monitor_specs that takes switchres monitor specs format
         - Now NTFS drives really should allow being used as the Roms/Snap folder
         - fixes for xorg.conf generation when lspci shows other interfaces with VGA in them
         - cwiid controller fixes
         - Really prevent extra setup on install if already done
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on April 02, 2011, 09:58:01 am
just a quick question.  it now sees the ntfs when enquiring about the roms location, but it then said it coulnd't find any matched roms once it rebooted and at the front end...

do the roms have to be on the root of the partition?  presently, they are inside mame\roms...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on April 02, 2011, 10:00:13 am
just a quick question.  it now sees the ntfs when enquiring about the roms location, but it then said it coulnd't find any matched roms once it rebooted and at the front end...

do the roms have to be on the root of the partition?  presently, they are inside mame\roms...
You'll have to edit the Advance Menu config (in the System Setup menu) and point to the roms locations.  The drive is mounted as /home/roms/ so from there where the exist on the NTFS drive they will be something like /home/roms/Mame/roms or something similar. 
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: MonkeyJug on April 02, 2011, 12:55:02 pm
making slow progress...

got the folder structure sorted thanks to your last post, but now i have a new, unrelated problem...

i have a tri-sync monitor, but when i select d9200 or d9800, the front end is displayed in a split screen.  the roms seem to launch ok and most of them sync up and run fine...

when i select h9110 from the video setup, the front end displays normally, full screen, but when i flick between different games, it sometimes has problems re-syncing back at the front end, and then some games have problems syncing when launched.  randomly, if i escape back to the front end, sometimes it syncs, sometimes it doesn't, and likewise, when i launch a game, sometimes it syncs up and sometimes it doesn't...  but if i remove the vga from the j-pac and re-connect it, it re-syncs itself...

also, completely unrelated - the controls for player 1 don't seem right.  i haven't adjusted anything here, but 'up' doesn't respond, and when i launch a game, left doesn't work.  i had a look in the general controls within mame, and it seems to be setup correctly...

i haven't touched my controls at all, which is why i'm baffled...

edit:  ignore the control problems... i went into universal controls and even though they were set to up, down, left, right, there was also a joy1, 2, 3, 4 in there.  i reset them to only up, down, left, right and now all is working control-wise...
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on April 02, 2011, 04:03:14 pm
I just added the custom monitor config option into groovymame, it's -monitor_specs <> with the same syntax as in switchres.  The main difference is that it can only be setup for one range, since in mame I can't give a parameter multiple times and have it store it as an array.  That should be ok though, since right now mostly to fiddle around with the TV settings and more likely a monitor has one range than many, else they are covered already or should be a special case and added in.  I have new builds as 011d for this, possibly you could test it and then have the people with the TV issues try some changes in the front porches and other values to see if things can use better values.  Just use switchres to figure out what the current default settings are for NTSC and PAL, it'll print them out in verbose mode, and work off of those outputs.

GREAT, testing that in a minute. So the format you're using is the same as in Switchres:

# HfreqMin-HfreqMax,VrefMin-VrefMax,HFP,HSP,HBP,VFP,VSP,VBP,HPol,VPol,ActiveLinesLimit,VirtualLinesLimit
#
# CGA Monitor
#MonitorLimits 15750-15750,55-60,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288,448

...so -monitor_specs <15750-15750,55-60,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288,448>

Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on April 02, 2011, 09:04:10 pm
the monitor value section sounds awesome. will it select 2x scaled modes correctly?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: Calamity on April 03, 2011, 05:44:25 am
when i select h9110 from the video setup, the front end displays normally, full screen, but when i flick between different games, it sometimes has problems re-syncing back at the front end, and then some games have problems syncing when launched.  randomly, if i escape back to the front end, sometimes it syncs, sometimes it doesn't, and likewise, when i launch a game, sometimes it syncs up and sometimes it doesn't...  but if i remove the vga from the j-pac and re-connect it, it re-syncs itself...

That's actually a problem with your j-pac board itself, I have similar issue with one of my j-pacs here, although lately it seems it has cured itself from that, sometimes it starts doing that for a while and it's annoying. I guess the problem has to do with the voltage on the usb it uses as power supply, if I remove the usb and switch it again then it resyncs perfectly.

the monitor value section sounds awesome. will it select 2x scaled modes correctly?

Well not yet actually, that only accounts for monitor timings, to do what you need GroovyMame must be specifically instructed to do so, either by manually making an ini for each game or modifying the pick_best_mode function in the code and adding an option for that case.
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: kevinp on April 07, 2011, 12:30:28 am
Guys,

This is simply fantastic stuff!!  Calamity's driver and Groovymame have alleviated so many of the issues I have been fighting for years on mameing arcade monitors.  No more stuttering and a huge reduction in adjusting VSize and Vhold between roms.  Thank you so much for your efforts!
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: newmanfamilyvlogs on April 07, 2011, 05:38:54 am
the monitor value section sounds awesome. will it select 2x scaled modes correctly?

Well not yet actually, that only accounts for monitor timings, to do what you need GroovyMame must be specifically instructed to do so, either by manually making an ini for each game or modifying the pick_best_mode function in the code and adding an option for that case.

By 'it', I did mean GroovyMame in general, not the new monitor values section, though looking back I realize that's not what it looks like.

Bitbytebit: Are you planning on implementing this?
Title: Re: Switchres arcade monitor modeline generator and mame wrapper
Post by: bitbytebit on April 07, 2011, 06:06:21 am
the monitor value section sounds awesome. will it select 2x scaled modes correctly?

Well not yet actually, that only accounts for monitor timings, to do what you need GroovyMame must be specifically instructed to do so, either by manually making an ini for each game or modifying the pick_best_mode function in the code and adding an option for that case.

By 'it', I did mean GroovyMame in general, not the new monitor values section, though looking back I realize that's not what it looks like.

Bitbytebit: Are you planning on implementing this?

Yeah I am, I have just about gotten 0142 ready, which took a bit of work completely redoing the patches. 

Now that's looking ready, I plan on doing this next.  So basically when doublescan is necessary, instead we just double the height and width, and no settings in mame are needed changing?  Then it'll just do the work at making the output fit?  Want to get more clear on the necessary changes, if it's just simply replacing doublescan with double height width, that's probably pretty easy.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 07, 2011, 10:14:23 am
So basically when doublescan is necessary, instead we just double the height and width, and no settings in mame are needed changing?  Then it'll just do the work at making the output fit?  Want to get more clear on the necessary changes, if it's just simply replacing doublescan with double height width, that's probably pretty easy.

In my tests I just doubled one of the dimensions, for instance, for 320x224, I know that if you select 320x448 or 640x224 Mame will scale it automatically without any pain, so I understand that doubling both dimensions will also work.

In theory for 31Khz monitors we'd only need double yres in order to achieve the fake doublescan we need, that would be my preferred approach if you ask me, but I know people will prefer to double both dimensions to have 4:3 resolutions, just for having better looking fonts and stuff like that.

EDIT: Maybe could be good to check for either double xres and yres too, it would help users of some ATI families in Windows, like HD3000, that are known to not accept low dotclocks. For those cases, I've enabled a "DotclockMin" option in VMMaker that just doubles xres in case it's needed, leaving yres unmodified (this is necessary for lowres arcade monitors).

Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 07, 2011, 01:37:21 pm
So basically when doublescan is necessary, instead we just double the height and width, and no settings in mame are needed changing?  Then it'll just do the work at making the output fit?  Want to get more clear on the necessary changes, if it's just simply replacing doublescan with double height width, that's probably pretty easy.

In my tests I just doubled one of the dimensions, for instance, for 320x224, I know that if you select 320x448 or 640x224 Mame will scale it automatically without any pain, so I understand that doubling both dimensions will also work.

In theory for 31Khz monitors we'd only need double yres in order to achieve the fake doublescan we need, that would be my preferred approach if you ask me, but I know people will prefer to double both dimensions to have 4:3 resolutions, just for having better looking fonts and stuff like that.

EDIT: Maybe could be good to check for either double xres and yres too, it would help users of some ATI families in Windows, like HD3000, that are known to not accept low dotclocks. For those cases, I've enabled a "DotclockMin" option in VMMaker that just doubles xres in case it's needed, leaving yres unmodified (this is necessary for lowres arcade monitors).



Something I just realized, in Windows should I turn off doublescan calculation then, does it ever even work and if so isn't the modeline registry entry require something different (from what I can tell, there isn't a flag for that anyways). 
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 07, 2011, 01:56:12 pm
Something I just realized, in Windows should I turn off doublescan calculation then, does it ever even work and if so isn't the modeline registry entry require something different (from what I can tell, there isn't a flag for that anyways). 

Yes, we don't have doublescan support for ATI cards in Windows unfortunately, so better have it disabled :(

I believe doublescan actually worked at some point in the past. There's actually a documented flag for that but it doesn't work any more. Instead, Catalyst drivers were badly hardcoded to enable doublescan just for 320x and 400x modes, and I'm pretty sure that was what broke generic doublescan support. Something I always do when I patch Catalyst drivers is to disable that behaviour by modifying the points where those checks are done. This is needed in order to allow normal 320x224 and such resolutions without doublescan (notice that ArcadeVGA drivers don't have this patch, that's why those cards use resolutions defined as 321x and 401x to avoid doublescan and these have become so popular).

Actually, there's one way I could restore doublescan support in ATI drivers, but to be honest I don't know if I want to go through the pain involved. If I modified the original hardcoded checks for 320x and 400x resolutions, and made them check for the least significant bit of xres instead, then we could have double scan for resolutions with odd xres, so in case we wanted 320x224 doublescanned we would define it as 321x224. The problem is that it would break the logic I have for "labels" when using static modelists, so maybe that would cause more problems than benefits, and after all doublescan can be easily faked by doubling yres.



Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 07, 2011, 03:20:39 pm
Something I just realized, in Windows should I turn off doublescan calculation then, does it ever even work and if so isn't the modeline registry entry require something different (from what I can tell, there isn't a flag for that anyways). 

Yes, we don't have doublescan support for ATI cards in Windows unfortunately, so better have it disabled :(

I believe doublescan actually worked at some point in the past. There's actually a documented flag for that but it doesn't work any more. Instead, Catalyst drivers were badly hardcoded to enable doublescan just for 320x and 400x modes, and I'm pretty sure that was what broke generic doublescan support. Something I always do when I patch Catalyst drivers is to disable that behaviour by modifying the points where those checks are done. This is needed in order to allow normal 320x224 and such resolutions without doublescan (notice that ArcadeVGA drivers don't have this patch, that's why those cards use resolutions defined as 321x and 401x to avoid doublescan and these have become so popular).

Actually, there's one way I could restore doublescan support in ATI drivers, but to be honest I don't know if I want to go through the pain involved. If I modified the original hardcoded checks for 320x and 400x resolutions, and made them check for the least significant bit of xres instead, then we could have double scan for resolutions with odd xres, so in case we wanted 320x224 doublescanned we would define it as 321x224. The problem is that it would break the logic I have for "labels" when using static modelists, so maybe that would cause more problems than benefits, and after all doublescan can be easily faked by doubling yres.





From what I can tell it seems that we need to do double width too, else we need to use keepaspect with it using only height and I've found things don't look as good with keep aspect as getting the width right (at least for vertical games this seems true).  Is this not the case with doubling the xres, that the yres would be able to avoid being doubled, without using keepaspect.  Or for both of these cases would using keepaspect allow the other value not to need doubling?

I think I may have all these about done, lowdotclock double res and disabled doublescan in Windows, just need to make sure the aspect is still correct though.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 07, 2011, 04:01:50 pm
Interesting, probably I've had keepaspect on all the time (as it's necessary for virtualized modes) and just thought it was the default behaviour, it makes sense that the keepaspect is needed there. So you mean it's looking worse with keepaspect? I didn't notice that but probably you're right, or maybe the vertical games are specially affected by their rotation and Mame performs a fractional scaling there. I'll need to do more testing on this.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 07, 2011, 04:19:38 pm
Interesting, probably I've had keepaspect on all the time (as it's necessary for virtualized modes) and just thought it was the default behaviour, it makes sense that the keepaspect is needed there. So you mean it's looking worse with keepaspect? I didn't notice that but probably you're right, or maybe the vertical games are specially affected by their rotation and Mame performs a fractional scaling there. I'll need to do more testing on this.

Yeah this was one of the first things I noticed about it and especially when I was originally using my arcadeVGA card and how the instructions recommended using keepaspect.  One pacman, it squishes the numbers oddly, and are too skinny on the sides, but yet if the resolution is wider and doing the aspect ratio correctly, then it is nice.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 07, 2011, 04:50:41 pm
I updated the patch, to 012a, builds coming soon.

These are the new options:

-monitor_doublescan  Use doublescan if necessary, not available in Windows
-monitor_dotclock    Lowest dotclock videocard accepts, 0 is the default
-monitor_ymin        Minimum height to calculate, default is no minimum

basically under Windows, it automatically disables doublescan, but can be done in Linux manually if using a card that doesn't.
The dotclock option takes the lowest dotclock, like 10000000 for 10Mhz
The ymin option is there to control the minimum height, in case you want 240 minimum instead of 224, although it's really not something necessary most of the time.

I *think* the way I did this will work well, at least in testing seems to be really nice on my LCD now when disabling doublescan with the double height/width method.  Also the low dotclock does a similar thing too.  There might be some odd little bugs too that I have possibly fixed, rare I think but basically when calculating resolutions more than once I discovered by doing the dotclock change that some values like doublescan would still be set, I now completely clear the modeline structure on each re-calculation :).
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 08, 2011, 12:03:23 pm
Great, I'll test this today. So when you set the monitor_dotclock, in case the resulting initial dotclock is below that value you do xres*2?
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 08, 2011, 12:08:23 pm
Great, I'll test this today. So when you set the monitor_dotclock, in case the resulting initial dotclock is below that value you do xres*2?

Yeah, and also yres because otherwise it's a squished screen, I can't see how it would work actually any other way.  I'm guessing that by doing this, on a 15khz monitor, it'll virtualize.  That probably is the most workable method I'm guessing because keepaspect doesn't seem to help in this case, and having the resolution wide like that looks pretty odd otherwise.  Check the latest git for the changes and play around with it though, if you can figure out how that can work better would be great, but it should all be there in the right places hopefully to allow us to perfect it.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 08, 2011, 12:47:04 pm
Yeah, and also yres because otherwise it's a squished screen, I can't see how it would work actually any other way.  I'm guessing that by doing this, on a 15khz monitor, it'll virtualize.  That probably is the most workable method I'm guessing because keepaspect doesn't seem to help in this case, and having the resolution wide like that looks pretty odd otherwise.  Check the latest git for the changes and play around with it though, if you can figure out how that can work better would be great, but it should all be there in the right places hopefully to allow us to perfect it.

I see, but if you double yres then as you say we can't use that for 15Khz monitors, and I'm nearly sure it works just with xres*2 at least for horizontal games. I'll do some testing anyway.

Check this bublbobl.log, it's interesting. I'm testing it with an lcd. The game originally uses 256x224 resolution. The first odd thing is that even if we have 512x448 available, that should be the one selected, it chooses 256x512 instead. Second, 256x512 is a registry defined modeline, but it's not available as an usable mode, probably because my lcd's edid is blocking that mode. Although this is not intended to be used with an lcd, it's good to know this and after reading registry modelines check if they've been accepted by the system and actually available.

EDIT: Just out of curiosity, here and there I see this word 'squished' used for a bad picture, but I don't get the accurate meaning of it and my dictionary is not helping with this one :)
EDIT2: When I say xres*2 works for me, I mean it is indistinguishable of the real thing, to the point that I'm tempted to get rid of the lower ones to do a better use of the limited space for video modes (anyway I might be wrong)
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 08, 2011, 04:23:12 pm
Yeah, and also yres because otherwise it's a squished screen, I can't see how it would work actually any other way.  I'm guessing that by doing this, on a 15khz monitor, it'll virtualize.  That probably is the most workable method I'm guessing because keepaspect doesn't seem to help in this case, and having the resolution wide like that looks pretty odd otherwise.  Check the latest git for the changes and play around with it though, if you can figure out how that can work better would be great, but it should all be there in the right places hopefully to allow us to perfect it.

I see, but if you double yres then as you say we can't use that for 15Khz monitors, and I'm nearly sure it works just with xres*2 at least for horizontal games. I'll do some testing anyway.

Check this bublbobl.log, it's interesting. I'm testing it with an lcd. The game originally uses 256x224 resolution. The first odd thing is that even if we have 512x448 available, that should be the one selected, it chooses 256x512 instead. Second, 256x512 is a registry defined modeline, but it's not available as an usable mode, probably because my lcd's edid is blocking that mode. Although this is not intended to be used with an lcd, it's good to know this and after reading registry modelines check if they've been accepted by the system and actually available.

EDIT: Just out of curiosity, here and there I see this word 'squished' used for a bad picture, but I don't get the accurate meaning of it and my dictionary is not helping with this one :)
EDIT2: When I say xres*2 works for me, I mean it is indistinguishable of the real thing, to the point that I'm tempted to get rid of the lower ones to do a better use of the limited space for video modes (anyway I might be wrong)


Ah, I mean it basically is really wide and really short, like 32:9 aspect ratio or something, with 1/3 of the screen black above and below the picture.  It just horizontally fills the picture but vertically it's barely filling 1/3 of it right in the middle. 
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 08, 2011, 04:51:19 pm
Ah, I mean it basically is really wide and really short, like 32:9 aspect ratio or something, with 1/3 of the screen black above and below the picture.  It just horizontally fills the picture but vertically it's barely filling 1/3 of it right in the middle. 

Ah ok, I now see what you mean, yes I've also seen that before but I think I got it working, will test it in a while.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 08, 2011, 06:03:06 pm
I've confirmed the xres*2 method works here, but I'm thinking it could be a DirectDraw behaviour and maybe not the same with SDL. I'm testing this with keepaspect 0. I've created a list of modelines starting from dotclock 7.5 and up, so the lowest is 360x.

goldnaxe uses 320x224, so it's supposed to use 640x224 with this setup. The interesting thing here is how DirectDraw uses the original 320x224 blit size when the resolution is below 640 (320*2) but as soon as it reaches 640x224 it automatically scales xres*2 and leaves yres unmodified:

> This one has very big borders on the sides
DirectDraw: Mode selected =  624x 288@ 54Hz
DirectDraw: primary surface created: 624x288x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 320x224

> This looks perfect, exactly as real 320x224
DirectDraw: Mode selected =  640x 224@ 60Hz
DirectDraw: primary surface created: 640x224x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 640x224

> This has little borders on the sides
DirectDraw: Mode selected =  672x 239@ 60Hz
DirectDraw: primary surface created: 672x239x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 640x224

I think it's just the same for vertical values.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 08, 2011, 06:15:12 pm
I've confirmed the xres*2 method works here, but I'm thinking it could be a DirectDraw behaviour and maybe not the same with SDL. I'm testing this with keepaspect 0. I've created a list of modelines starting from dotclock 7.5 and up, so the lowest is 360x.

goldnaxe uses 320x224, so it's supposed to use 640x224 with this setup. The interesting thing here is how DirectDraw uses the original 320x224 blit size when the resolution is below 640 (320*2) but as soon as it reaches 640x224 it automatically scales xres*2 and leaves yres unmodified:

> This one has very big borders on the sides
DirectDraw: Mode selected =  624x 288@ 54Hz
DirectDraw: primary surface created: 624x288x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 320x224

> This looks perfect, exactly as real 320x224
DirectDraw: Mode selected =  640x 224@ 60Hz
DirectDraw: primary surface created: 640x224x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 640x224

> This has little borders on the sides
DirectDraw: Mode selected =  672x 239@ 60Hz
DirectDraw: primary surface created: 672x239x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 640x224

I think it's just the same for vertical values.


So in the height case for doublescan, is it also able to do the same thing?  Interesting, I am guessing it's a direct draw feature or something.  I'm looking at a couple possible changes, first check if SDL or driect draw and only mess with the height on this or width on no-doublescan if it's SDL.  Also looks like in the best mode function, I'm now seeing how after checking exact matches, like you've been saying, I can try double width ones too.  Should I also then after that check for double height ones with the same original width, then mabye double width + double height after that?



Update: Patch to try, which only does the aspect keeping part in SDL, not in Windows...
Code: [Select]
--- a/src/emu/switchres/modeline.c
+++ b/src/emu/switchres/modeline.c
@@ -96,7 +96,8 @@ int ModelineCreate(ConfigSettings *cs, GameInfo *game, MonitorMode *monitor, Mod
                        if (cs->verbose > 2)
                                mame_printf_verbose("SwitchRes: Double height width instead of doublescan\n");
                        mode->vactive *= 2; // Double height
-                       mode->hactive *= 2; // Double width
+                       if (cs->keepaspect)
+                               mode->hactive *= 2; // Double width
                        mode->result |= RESULT_DOUBLERES;
                } else {
                         double num, den;
diff --git a/src/emu/switchres/switchres.c b/src/emu/switchres/switchres.c
index 05dc1ba..589286f 100644
--- a/src/emu/switchres/switchres.c
+++ b/src/emu/switchres/switchres.c
@@ -203,7 +203,8 @@ void calc_modeline(running_machine &machine)
                if (modeLine->pclock < cs->dotclockmin) {
                        mame_printf_verbose("SwitchRes: Dotclock too low, doubling horizontal size\n");
                        gameInfo->width *= 2;
-                       gameInfo->height *= 2;
+                       if (cs->keepaspect)
+                               gameInfo->height *= 2;
 
                        ModelineCreate(cs, gameInfo, switchRes->monitorMode, &switchRes->monitorMode->modeLine);
                        switchRes->monitorMode->modeLine.result |= RESULT_LOWDOTCLOCK;
diff --git a/src/emu/switchres/switchres.h b/src/emu/switchres/switchres.h
index cb1145a..550b2a9 100644
--- a/src/emu/switchres/switchres.h
+++ b/src/emu/switchres/switchres.h
@@ -50,6 +50,7 @@ typedef struct ConfigSettings {
        int    cleanstretch;
        int    soundsync;
        int    changeres;
+       int    keepaspect;
 } ConfigSettings;
 
 typedef struct ModeLine {
diff --git a/src/osd/sdl/switchres.c b/src/osd/sdl/switchres.c
index 9367aad..77882ef 100644
--- a/src/osd/sdl/switchres.c
+++ b/src/osd/sdl/switchres.c
@@ -105,6 +105,7 @@ bool switchres_modeline_setup(running_machine &machine)
        // Get .ini resolution if any
        if (!machine.switchRes.resolution.count) {
                strcpy(machine.switchRes.gameInfo.resolution, options.resolution());
+               machine.switchRes.cs.keepaspect = 1;
        }
 
        // Get connector name

Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 08, 2011, 06:35:26 pm
So in the height case for doublescan, is it also able to do the same thing?  Interesting, I am guessing it's a direct draw feature or something.  I'm looking at a couple possible changes, first check if SDL or driect draw and only mess with the height on this or width on no-doublescan if it's SDL. 

Yes, for what I've been seeing with the lcd on the other system if you select 320x448 it will scale yres instead and the result will be perfect, so that would be the case of fake doublescan on vga monitors.

I'm not sure if it's a directdraw feature or just something explicitly coded in the ddraw osd part, that could be ported to the sdl side.

Also looks like in the best mode function, I'm now seeing how after checking exact matches, like you've been saying, I can try double width ones too.  Should I also then after that check for double height ones with the same original width, then mabye double width + double height after that?

Yes, the only caution needed is to penalize interlaced modes, as I wouldn't choose an interlaced mode if I have a better progressive one available although not exact. So I'm guessing it can get a little tricky to account for everything, although that will make a very flexible system.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 08, 2011, 08:34:55 pm
So in the height case for doublescan, is it also able to do the same thing?  Interesting, I am guessing it's a direct draw feature or something.  I'm looking at a couple possible changes, first check if SDL or driect draw and only mess with the height on this or width on no-doublescan if it's SDL.

Yes, for what I've been seeing with the lcd on the other system if you select 320x448 it will scale yres instead and the result will be perfect, so that would be the case of fake doublescan on vga monitors.

I'm not sure if it's a directdraw feature or just something explicitly coded in the ddraw osd part, that could be ported to the sdl side.

Also looks like in the best mode function, I'm now seeing how after checking exact matches, like you've been saying, I can try double width ones too.  Should I also then after that check for double height ones with the same original width, then mabye double width + double height after that?

Yes, the only caution needed is to penalize interlaced modes, as I wouldn't choose an interlaced mode if I have a better progressive one available although not exact. So I'm guessing it can get a little tricky to account for everything, although that will make a very flexible system.


Try the current patch or git, I haven't made builds of the changes yet, but I hopefully have done the scoring a lot better now and might have gotten close to doing like you mention above.  

See the changes, let me know how it works, I do have a few questions about when the match is 'fuzzy', which you may want to test.  Like what do we need to set when width is a bit less than we wanted (especially vertical games), possibly keep aspect and hwstretch?  And when width is wider than what we wanted, but not double, gessing we need keepaspect but no hwstretch in that case.  You'll see in the changes I've made since the patch above I posted, (git diff ac7266e137b5ac37efd45f339f9bc3a6f369a3c0) that I'm now doing some extra checking to set keepaspect and/or hwstretch in the non-perfect match cases.  Also now only set filter if interlaced is used, just to make sure it's always on in any interlaced mode, thinking that is best just in case.  I also score down the interlaced modes, but that might need some perfecting, my score system is kinda a quick hack but hopefully improves if not already good enough.

Update:
  Ok I'm uploading builds as 012b for this now, since from what I can tell it probably is only going to be better than what has been being done in the past.  At least seems like there's a lot more chance of things working, even when you have a limited custom modeline table.  Also wondering about how to check if a custom modeline is really usable, with my testing since it's on a system without 15khz monitors I never reboot and activate them, so I can test without going into them.  So is it only by that active modelines check we do to reload things, does that actually return the custom modelines too once they are active?
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 09, 2011, 05:11:47 am
I'm going to try the new patch here with a lcd, although won't be able to test it in my cab probably until Sunday as I'm away this weekend.

Yes, this could be the moment to work on the pick best mode algorithm, I've always wanted to figure out a good one but never started with it. It's not a trivial matter probably, and I think no one has come with a really good algorithm yet, even the original one from Mame is far from perfect. However the one in GroovyMame is already doing pretty good when fed with a decent mode list.

By using EnumDisplaySettings api you get the modes actually available in the system, so by matching that list with your registry modeline list you can check which of them are available and most important, which of the are custom modes instead of native modes: unless explicitly stated we should not use native modes as we can't tweak or have any control on them.

There's something else I noticed in the last logs, if I launch Groovymame with the -resolution0 param I think we should force it to update the registry modeline we're asking for (in case it exists) instead of making its own decision, mainly because after that it's actually using the resolution we asked for so the modified registry modeline is never used.

Update: I've done basic testing here. It works perfect when one of the dimensions is doubled (goldnaxe case: 320x448), but doesn't choose the right one when both dimensions are doubled (bublbobl: should select 512x448). However if I force bublbobl to select 512x448 then it displays perfectly (but groovymame does not target the right modeline as I explained above, so it runs 101%). For these tests I'm using monitor option "vga" and have a modeline list calculated with fake doublescan. Notice that even if I have created modelines with yres=512, for games that are 256 lines tall (*2), those modes are not available in my system, probably blocked by my lazy Dell lcd monitor edid (its native resolution is 1680x1050).
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 09, 2011, 07:09:22 am
I'm going to try the new patch here with a lcd, although won't be able to test it in my cab probably until Sunday as I'm away this weekend.

Yes, this could be the moment to work on the pick best mode algorithm, I've always wanted to figure out a good one but never started with it. It's not a trivial matter probably, and I think no one has come with a really good algorithm yet, even the original one from Mame is far from perfect. However the one in GroovyMame is already doing pretty good when fed with a decent mode list.

By using EnumDisplaySettings api you get the modes actually available in the system, so by matching that list with your registry modeline list you can check which of them are available and most important, which of the are custom modes instead of native modes: unless explicitly stated we should not use native modes as we can't tweak or have any control on them.

There's something else I noticed in the last logs, if I launch Groovymame with the -resolution0 param I think we should force it to update the registry modeline we're asking for (in case it exists) instead of making its own decision, mainly because after that it's actually using the resolution we asked for so the modified registry modeline is never used.

Update: I've done basic testing here. It works perfect when one of the dimensions is doubled (goldnaxe case: 320x448), but doesn't choose the right one when both dimensions are doubled (bublbobl: should select 512x448). However if I force bublbobl to select 512x448 then it displays perfectly (but groovymame does not target the right modeline as I explained above, so it runs 101%). For these tests I'm using monitor option "vga" and have a modeline list calculated with fake doublescan. Notice that even if I have created modelines with yres=512, for games that are 256 lines tall (*2), those modes are not available in my system, probably blocked by my lazy Dell lcd monitor edid (its native resolution is 1680x1050).


Do that bublboble with a -md 4 or more, something is odd there, it should have scores for some of those resolutions and they are all 0.00.  So something odd, and more debug might show me how that's happening.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 09, 2011, 07:18:37 am
Ah sorry, I always forget the md 4 param, here it is.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 09, 2011, 07:46:26 am
Ah sorry, I always forget the md 4 param, here it is.


I've got a fix hopefully, I was checking the wrong one for doubling for the height/width, that probably is the issue.  Also might have fixed the logic in the other checks there, was doing it backwards from the registry value to the target value :).

Also trying to check in the available modes to make sure the resolution is available, see if it really can figure that out, it says none of mine are available because they aren't, not sure if it will be able to know for sure.  Right now it just checks and warns, since by the time that is called the resolution is already picked.  Have to look at a way to do it yet avoid the large static arrays like before which cause issues and too much extra looping over and over, at least try to do the minimal amount.

I have a patch uploaded, git updated, and updated the 012b builds with the fix so you can see if it's working right now.

Update:
 Ah I actually now see how it just needed a 2x width and height case, I didn't actually have that case built in, and the other change I made was not good and probably broke the other ones that did work :). 

I am uploading new builds with fixes to that, but also I think I hopefully got the other logic right too, a bit confusing getting the logic all right in comparing the correct one with the right multiplier. The newer uploads should be in place now, these should be a bit better I hope.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 09, 2011, 09:41:59 am
Ah sorry, I always forget the md 4 param, here it is.


I've got a fix hopefully, I was checking the wrong one for doubling for the height/width, that probably is the issue.  Also might have fixed the logic in the other checks there, was doing it backwards from the registry value to the target value :).

Also trying to check in the available modes to make sure the resolution is available, see if it really can figure that out, it says none of mine are available because they aren't, not sure if it will be able to know for sure.  Right now it just checks and warns, since by the time that is called the resolution is already picked.  Have to look at a way to do it yet avoid the large static arrays like before which cause issues and too much extra looping over and over, at least try to do the minimal amount.

I have a patch uploaded, git updated, and updated the 012b builds with the fix so you can see if it's working right now.

Update:
 Ah I actually now see how it just needed a 2x width and height case, I didn't actually have that case built in, and the other change I made was not good and probably broke the other ones that did work :).  

I am uploading new builds with fixes to that, but also I think I hopefully got the other logic right too, a bit confusing getting the logic all right in comparing the correct one with the right multiplier. The newer uploads should be in place now, these should be a bit better I hope.
 

I'm uploading some more changes, should be up now, because now I'm properly making interlaced a lower priority, and should be doing the fuzzy matching in a much more precise way with more complex scoring for that.  If working right, it should now really be intelligent about which fuzzy match it picks if any are close to decent.  It's interesting because right now it seems to be able to pick the couple most popular resolutions in order for vertical games, like with pacman it'll pick first the 400x288, then second 382x288 and third 352x288, which are all ones I've seen used in different places (so it knows that 400x288 is the proper aspect ratio one, but the others are decent compromises).  

The scoring is definitely looks like quite a tricky thing to do, at least the 'fuzzy matching' which mame really doesn't seem to do from what I've been able to ever tell (it just picks a large resolution, it can't find one that's just 8-16 lines/pixels bigger, at least from what I've seen).  That might be an SDL specific characteristic though, those double resolutions and possibly the general way it picks seem a bit different.  I was looking at the direct draw vs. d3d picking method, and that's interesting how that all works, I need to compare the SDL part to those and see if the differences really are in the actual OS libraries/drivers themselves.

Update: Also the last commit in the git repository tries to really skip and not use the non-available modelines, it's only in the updated patch and git, not the builds.  So I can't test that one here, since my modelines are all non-active, but see how that works there and if it does things right.  Only fear I have is mainly the calling of that Enum call too much, not sure if that is safe or not, I'm hoping it's harmless.  It avoids the issue of needing the big array allocated that causes the Windows stack to crash.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 10, 2011, 10:56:36 am
hi bitbytebit - i have the linux cd installed and running now, and i'm very pleased with how it all looks.  just a couple of questions...

1. i have downloaded a whole bunch of snaps, and they are placed inside the snaps folder, however, i can see no way to get them to appear on the advancemenu frontend.  can you advise on this, please?

2. ordered a new j-pac, and it is now re-syncing everytime i switch games, and switch back to the frontend.  seems like it was indeed faulty - not sure what happened to it, but my question is this:  for a tri-sync monitor (15/24/31), what video settings should i be selecting in the monitor setup section?  my understanding, although likely wrong, is that i should be selecting either d9200 or d9800, but when i do this, i get the split-screen on the frontend.  games however mostly launch fine, with the odd one not syncing properly.  when i set it to either cga, or h9110, the front end displays fine, but is 'flickery' as if interlaced...  my monitor can display 640x480p, and i'm not sure what resolution the front end is being displayed at.

3.  for the video output, i'm assuming i should be selecting 15khz, even though my monitor is tri-sync?  and why is there an option for 'disable output'?  what is the relevance of that?

edit: 4: can you have a look at 'alcon' (slap fight here in the uk).  i can only get it to run at around 88% speed-wise...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 10, 2011, 11:15:27 am
hi bitbytebit - i have the linux cd installed and running now, and i'm very pleased with how it all looks.  just a couple of questions...

1. i have downloaded a whole bunch of snaps, and they are placed inside the snaps folder, however, i can see no way to get them to appear on the advancemenu frontend.  can you advise on this, please?

2. ordered a new j-pac, and it is now re-syncing everytime i switch games, and switch back to the frontend.  seems like it was indeed faulty - not sure what happened to it, but my question is this:  for a tri-sync monitor (15/24/31), what video settings should i be selecting in the monitor setup section?  my understanding, although likely wrong, is that i should be selecting either d9200 or d9800, but when i do this, i get the split-screen on the frontend.  games however mostly launch fine, with the odd one not syncing properly.  when i set it to either cga, or h9110, the front end displays fine, but is 'flickery' as if interlaced...  my monitor can display 640x480p, and i'm not sure what resolution the front end is being displayed at.

3.  for the video output, i'm assuming i should be selecting 15khz, even though my monitor is tri-sync?  and why is there an option for 'disable output'?  what is the relevance of that?

edit: 4: can you have a look at 'alcon' (slap fight here in the uk).  i can only get it to run at around 88% speed-wise...

Ah, yeah that snaps folder is something that is wrong actually, I need to clear that up better.  It's actually this folder...

emulator_altss "mame" "/home/roms/ttl"

So /home/roms/ttl/ for the title screens or basically it looks in there, by the advance menu config currently setup.

Yeah it uses interlaced when setup to arcade monitors, but yet your monitor can do the 640x480 like mine.  I am guessing the J-Pac is doing the thing where it refuses to pass the 31khz signal to your monitor and doubling the screen.  Maybe Calamity knows what to do in this case, is it a jumper or setting? That would allow the 32khz signals through too.

Oh, ignore that, it's only for changing the video card output when you want to for example change from VGA-0 to DVI-0, or basically the VGA to the DVI connector, or back.  So if you boot with the right option and don't change the output ever, then you can ignore that setup menu.

I'll give alcon a check on my arcade monitor, on my LCD here with resolution switching it is running at 100% but this computer may be different.
Update: Yeah alcon works fine here, sounds odd, possibly a full -verbose -md 4 log from groovymame would show something, also what exact brand is that monitor?  I could try to find specs on it and add it, possibly another issue, although less likely. 
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 10, 2011, 12:23:51 pm
I'll give alcon a check on my arcade monitor, on my LCD here with resolution switching it is running at 100% but this computer may be different.
Update: Yeah alcon works fine here, sounds odd, possibly a full -verbose -md 4 log from groovymame would show something, also what exact brand is that monitor?  I could try to find specs on it and add it, possibly another issue, although less likely.  

wow, that would be great!

it's a 'Wei-Ya M31 Series CGA/EGA/VGA 29" Monitor', with a 3129DB chassis.

i had a quick look on google and found this link, but i'm unable to confirm what's there due to it being filtered out at my workplace.  hopefully it contains the info you're looking for:

wiki.arcadeotaku.com/w/File:Wei-ya_M3192D_manual.pdf (http://wiki.arcadeotaku.com/w/File:Wei-ya_M3192D_manual.pdf)

basically the monitors are installed into the Big Century (and i think, OK Baby) cabinets.  a link for the cabinets is here:

http://www.gremlinsolutions.co.uk/ebaybigcentury.htm (http://www.gremlinsolutions.co.uk/ebaybigcentury.htm)

maybe you could contact them and see if they can help you with that information...

if you can do that, a hefty donation will be coming your way!

regarding Alcon, i've tried it on 2 fairly beefy pcs, and i can get it to run slightly faster, (about 92% if i try with d9800 as the selected monitor) - weird how it runs 100% your end - i loved that game as a boy!
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 10, 2011, 10:18:49 pm
I'll give alcon a check on my arcade monitor, on my LCD here with resolution switching it is running at 100% but this computer may be different.
Update: Yeah alcon works fine here, sounds odd, possibly a full -verbose -md 4 log from groovymame would show something, also what exact brand is that monitor?  I could try to find specs on it and add it, possibly another issue, although less likely.  

wow, that would be great!

it's a 'Wei-Ya M31 Series CGA/EGA/VGA 29" Monitor', with a 3129DB chassis.

i had a quick look on google and found this link, but i'm unable to confirm what's there due to it being filtered out at my workplace.  hopefully it contains the info you're looking for:

wiki.arcadeotaku.com/w/File:Wei-ya_M3192D_manual.pdf (http://wiki.arcadeotaku.com/w/File:Wei-ya_M3192D_manual.pdf)

basically the monitors are installed into the Big Century (and i think, OK Baby) cabinets.  a link for the cabinets is here:

http://www.gremlinsolutions.co.uk/ebaybigcentury.htm (http://www.gremlinsolutions.co.uk/ebaybigcentury.htm)

maybe you could contact them and see if they can help you with that information...

if you can do that, a hefty donation will be coming your way!

regarding Alcon, i've tried it on 2 fairly beefy pcs, and i can get it to run slightly faster, (about 92% if i try with d9800 as the selected monitor) - weird how it runs 100% your end - i loved that game as a boy!

I think to start off, trying a d9200 profile for this monitor but minus the SVGA section would be good.  I'm not sure if the front/back porch values are exact, but might not be so bad.  So I added an m3292 monitor type to groovymame to try, I'll put it into the next Linux ISO and will upload new Windows builds with it.  So trying it with an m3192 monitor with the Windows build might be interesting, I'll need to look at adding this to the menu on the Linux ISO too.

Mostly the d9200 profile should work, except if it creeps up into the SVGA range, but that shouldn't happen too often, most everything normally would stay in the VGA and below.  I think the alcon issue might just be the processor, but amazing that it takes that much processor to run that game, but sounds like the issue. The J-Pac issue I'm guessing is trying to use the J-Pac with something more than 15khz, so that's possibly some setting on it, at least from what I can tell.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 11, 2011, 07:14:40 am
my understanding, although likely wrong, is that i should be selecting either d9200 or d9800, but when i do this, i get the split-screen on the frontend.  games however mostly launch fine, with the odd one not syncing properly.  when i set it to either cga, or h9110, the front end displays fine, but is 'flickery' as if interlaced...  my monitor can display 640x480p, and i'm not sure what resolution the front end is being displayed at.

You'll need to remove the proper jumpers on your jpac to allow 31Khz signal to pass the filter.

edit: 4: can you have a look at 'alcon' (slap fight here in the uk).  i can only get it to run at around 88% speed-wise...

That game, when rotated, uses 280 lines. You can't get 60Hz having to draw so many lines with a normal arcade monitor, that's why you only get 88% of its speed. pacman, contra, dspirit and such games should show the same issue. But they *should* run 100% with the D9800 setup, if otherwise please post your logs so we can check what's wrong there.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 11, 2011, 10:55:03 am
I think to start off, trying a d9200 profile for this monitor but minus the SVGA section would be good.  I'm not sure if the front/back porch values are exact, but might not be so bad.  So I added an m3292 monitor type to groovymame to try, I'll put it into the next Linux ISO and will upload new Windows builds with it.  So trying it with an m3192 monitor with the Windows build might be interesting, I'll need to look at adding this to the menu on the Linux ISO too.

Mostly the d9200 profile should work, except if it creeps up into the SVGA range, but that shouldn't happen too often, most everything normally would stay in the VGA and below.  I think the alcon issue might just be the processor, but amazing that it takes that much processor to run that game, but sounds like the issue. The J-Pac issue I'm guessing is trying to use the J-Pac with something more than 15khz, so that's possibly some setting on it, at least from what I can tell.

the d9200 profile works very well for the most part.  one game that i'd like to play that is problematic though is strikers 1945 ii (s1945ii) which just won't sync with that profile, but will sync no problems when the video mode is set to CGA.

one minor issue, that link that i gave you above, i only just noticed it says M3192, whereas my monitor/chassis is M3129.  i checked last night and that .pdf is exactly the same as the manual that came with my cabinet.  not sure if it's a typo or not, but as i'm not at home right now to test it, can you just confirm that i should set the monitor type in the groovymame .ini file to M3292 and not M3192 or even M3129!  i'm just a bit confused with the 29s or 92s!

thank you so much for doing this, by the way!
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 11, 2011, 10:58:39 am
A quick fix, in your GetAvailableVideoModes function you need to change this:

Code: [Select]
while (EnumDisplaySettings( NULL, iModeNum, &lpDevMode ) != 0) {
if (lpDevMode.dmBitsPerPel == 32) {
if (lpDevMode.dmPelsWidth == width
&& lpDevMode.dmPelsHeight == height
//&& lpDevMode.dmPelsWidth == height)
&& lpDevMode.dmDisplayFrequency == freq)

Now it works here, I've attached bublbobl log...
Update: Also have a look at loht's log, it doesn't choose any mode so ddraw selects its own one.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 11, 2011, 11:01:25 am
I think to start off, trying a d9200 profile for this monitor but minus the SVGA section would be good.  I'm not sure if the front/back porch values are exact, but might not be so bad.  So I added an m3292 monitor type to groovymame to try, I'll put it into the next Linux ISO and will upload new Windows builds with it.  So trying it with an m3192 monitor with the Windows build might be interesting, I'll need to look at adding this to the menu on the Linux ISO too.

Mostly the d9200 profile should work, except if it creeps up into the SVGA range, but that shouldn't happen too often, most everything normally would stay in the VGA and below.  I think the alcon issue might just be the processor, but amazing that it takes that much processor to run that game, but sounds like the issue. The J-Pac issue I'm guessing is trying to use the J-Pac with something more than 15khz, so that's possibly some setting on it, at least from what I can tell.

the d9200 profile works very well for the most part.  one game that i'd like to play that is problematic though is strikers 1945 ii (s1945ii) which just won't sync with that profile, but will sync no problems when the video mode is set to CGA.

one minor issue, that link that i gave you above, i only just noticed it says M3192, whereas my monitor/chassis is M3129.  i checked last night and that .pdf is exactly the same as the manual that came with my cabinet.  not sure if it's a typo or not, but as i'm not at home right now to test it, can you just confirm that i should set the monitor type in the groovymame .ini file to M3292 and not M3192 or even M3129!  i'm just a bit confused with the 29s or 92s!

thank you so much for doing this, by the way!

The manual probably is the same for either, just basically showing that it has the 3 different khz ranges and basically like the d9200.  The difference is that the d9200 can also use the SVGA range and so possibly that one game is trying to use that range, and so can't sync.  The change I made skips that range if given the new m3292 monitor type, although I need to rethink some things on how the Linux setup works for monitor selection.  Mainly because it is getting kind of full of monitor types, 10 already, I need to either submenu them or some other method.  Also I need to now look at the way the general desktop modeline is generated, am using switchres but I'm now thinking that redoing it so that switchres shares the same code as mame, or groovymame itself has a -showmode arg or something so it has the switchres modeline generation output built into it.  So I can have the monitor types and ranges it supports not have to be added into switchres and groovymame, plus the calculations in groovymame are now advancing a bit ahead of what switchres does and best to find a way to unify them now instead of later.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 11, 2011, 11:11:14 am
A quick fix, in your GetAvailableVideoModes function you need to change this:

Code: [Select]
while (EnumDisplaySettings( NULL, iModeNum, &lpDevMode ) != 0) {
if (lpDevMode.dmBitsPerPel == 32) {
if (lpDevMode.dmPelsWidth == width
&& lpDevMode.dmPelsHeight == height
//&& lpDevMode.dmPelsWidth == height)
&& lpDevMode.dmDisplayFrequency == freq)

Now it works here, I've attached bublbobl log...
Update: Also have a look at loht's log, it doesn't choose any mode so ddraw selects its own one.


Ah, wow, I definitely didn't look closely at that :), I am uploading the 012d builds with that fix.  So all the scoring seems sane?, one thing I'm wondering is if in all cases interlacing is properly scored lower than the progressive possibilities, at least in the fuzzy match cases where things can't be multiples.  It's definitely a big change/leap in how that all works, hopefully for the good since before compared to this things were really going to be random with a small set of resolutions like the default Soft15khz ones.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 11, 2011, 11:26:46 am
Ah, wow, I definitely didn't look closely at that :), I am uploading the 012d builds with that fix.  So all the scoring seems sane?, one thing I'm wondering is if in all cases interlacing is properly scored lower than the progressive possibilities, at least in the fuzzy match cases where things can't be multiples.  It's definitely a big change/leap in how that all works, hopefully for the good since before compared to this things were really going to be random with a small set of resolutions like the default Soft15khz ones.

Yes I'm starting to have a look at the scoring system now as before all the modelines were marked as non available but for the "square" ones (same width/height) so it was easy to find the bug :). Now I'm testing on my lcd here, so have no interlaced modes. I'm seeing that when no suitable resolution is found all are scored to 0.00 so directdraw is free to select whatever it decides, we should fix that I'm thinking. Although this lcd case is not our target, it would be elegant to make it work the best possible even if lcds are evil.

There are very subtle details that need to be accounted for, I'll try to think of them and probably help with implementation. It's not a trivial matter at all. Not all refresh rates can be obtained for all resolutions, and it will highly depend on the monitor selected, fortunately we have the info to do that based on our calculations. No one has done that before afaik.

I've noticed a big slowdown at startup, probably due to the way EnumDisplaySettings is called so many times now. Not important by now but I believe it could be solved by using a static array for our modes, maybe allocating memory at the beginning and using it after that.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 11, 2011, 12:14:18 pm
my understanding, although likely wrong, is that i should be selecting either d9200 or d9800, but when i do this, i get the split-screen on the frontend.  games however mostly launch fine, with the odd one not syncing properly.  when i set it to either cga, or h9110, the front end displays fine, but is 'flickery' as if interlaced...  my monitor can display 640x480p, and i'm not sure what resolution the front end is being displayed at.

You'll need to remove the proper jumpers on your jpac to allow 31Khz signal to pass the filter.

edit: 4: can you have a look at 'alcon' (slap fight here in the uk).  i can only get it to run at around 88% speed-wise...

That game, when rotated, uses 280 lines. You can't get 60Hz having to draw so many lines with a normal arcade monitor, that's why you only get 88% of its speed. pacman, contra, dspirit and such games should show the same issue. But they *should* run 100% with the D9800 setup, if otherwise please post your logs so we can check what's wrong there.


as a test this morning, i ran the video settings in the linux cd as VGA (31khz) and removed the 15khz jumper from the jpac, leaving just the 31khz attached.  the frontend displayed, full-screen, with no flicker, (640x480p) and 'alcon' did indeed run at 100%, although the screen resolution was obviously completely messed up.

it's a brand new jpac, but i'm unsure if it is displaying symptoms that are considered normal.  ie. selecting d9200 from the linux cd, with jumpers on both 15khz and 31khz, it boots to the front end, in split screen (interlaced?), whereas i believe it 'should' be displaying a 640x480p full-screen.  launch any low-res game and it displays perfectly, full-screen, then if i exit back to the front end, i still get the split screen...

however, if i then remove the power to the jpac temporarily, and remove the 15khz jumper, leaving just the 31khz jumper attached, and then reconnect the power, it displays 640x480p in the front end perfectly, full-screen.  then if i launch, for example, tekken tag tournament (which off the top of my head is 640x480p), it also displays full-screen and looks perfect...  nothing happens when i launch a low-res game (black screen) which i'm guessing is perfectly normal because i have removed the 15khz jumper.

with both jumpers attached, (allowing to launch low-res and hi-res games), my problem seems to be 640x480p isn't given priority over the jpac insisting on splitting the signal and displaying a split screen... i very confused!

Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 11, 2011, 12:35:58 pm
with both jumpers attached, (allowing to launch low-res and hi-res games), my problem seems to be 640x480p isn't given priority over the jpac insisting on splitting the signal and displaying a split screen... i very confused!

Attaching both 15 and 31Khz jumpers is only intended for 15Khz monitors, to filter 31Khz signal and show it as split screen. Otherwise you should only use one jumper, depending on your monitor frequency range. What happens if you have a multisync monitor? I don't know :) I'd check if it works by removing all jumpers: that way your jpac sends composite sync, there's a chance your monitor will accept that.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 11, 2011, 05:53:59 pm
I'm testing this version with tricky mode tables to see how it behaves and looks pretty good. I'm using modes starting from 432 or so, and it works surprisingly well. I've noticed with this mode table that I need to set keepaspect in order to have vertical games like pacman to show properly: instead of 400x288, that's missing, it goes for 800x288, but then it looks double wide unless I use keepaspect (which doesn't seem to create any artifacts so I think it's clean to do so). On the other hand most horizontal games look perfect, although I have not defined resolutions below 432, it goes for the exact multiple and it's impossible to tell the difference. I've found two odd cases:

- ghouls for some reason picks the right resolution and all the logs look perfect, but for some reason it doesn't perform the xres*2 scaling and the picture is very narrow
- mk works fine but 110% of it's speed, even if the logs look correct, it's confusing...

Apart from the big slowdown when checking resolutions, I've seen it get in a loop when trying to switch resolutions back and forth sometimes, until you kill the app. This is for sure due to the abuse of EnumDisplaySettings I'm thinking. That could be causing the mk issue probably as a side effect if the dynamic modeline magic is affected by that, not sure.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 11, 2011, 06:04:16 pm
I'm testing this version with tricky mode tables to see how it behaves and looks pretty good. I'm using modes starting from 432 or so, and it works surprisingly well. I've noticed with this mode table that I need to set keepaspect in order to have vertical games like pacman to show properly: instead of 400x288, that's missing, it goes for 800x288, but then it looks double wide unless I use keepaspect (which doesn't seem to create any artifacts so I think it's clean to do so). On the other hand most horizontal games look perfect, although I have not defined resolutions below 432, it goes for the exact multiple and it's impossible to tell the difference. I've found two odd cases:

- ghouls for some reason picks the right resolution and all the logs look perfect, but for some reason it doesn't perform the xres*2 scaling and the picture is very narrow
- mk works fine but 110% of it's speed, even if the logs look correct, it's confusing...

Apart from the big slowdown when checking resolutions, I've seen it get in a loop when trying to switch resolutions back and forth sometimes, until you kill the app. This is for sure due to the abuse of EnumDisplaySettings I'm thinking. That could be causing the mk issue probably as a side effect if the dynamic modeline magic is affected by that, not sure.


Yeah I'm reworking how the resolutions are read/stored to fix the need to call Enum so much.  Basically closer to what you originally had, but just one single list of active resolutions, filled in custom modelines.  So it will both only allow real active resolutions into the list, have the non-custom ones there for the ability to choose them if we must, and probably more possibilities from having them all read into an array at startup and labeled properly (plus sorted too, so making sure they are in order, although the scoring has probably made that less likely to matter).  Will see how this works out, should be interesting doing it this way, and how easily I can figure out ways to exploit the system resolutions when we don't have custom ones that fit, or being able to see the ArcadeVGA 3000 possible resolutions to use. 
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 11, 2011, 08:38:03 pm
I'm testing this version with tricky mode tables to see how it behaves and looks pretty good. I'm using modes starting from 432 or so, and it works surprisingly well. I've noticed with this mode table that I need to set keepaspect in order to have vertical games like pacman to show properly: instead of 400x288, that's missing, it goes for 800x288, but then it looks double wide unless I use keepaspect (which doesn't seem to create any artifacts so I think it's clean to do so). On the other hand most horizontal games look perfect, although I have not defined resolutions below 432, it goes for the exact multiple and it's impossible to tell the difference. I've found two odd cases:

- ghouls for some reason picks the right resolution and all the logs look perfect, but for some reason it doesn't perform the xres*2 scaling and the picture is very narrow
- mk works fine but 110% of it's speed, even if the logs look correct, it's confusing...

Apart from the big slowdown when checking resolutions, I've seen it get in a loop when trying to switch resolutions back and forth sometimes, until you kill the app. This is for sure due to the abuse of EnumDisplaySettings I'm thinking. That could be causing the mk issue probably as a side effect if the dynamic modeline magic is affected by that, not sure.


I have made changes, 012e builds will show up in a few minutes.  I have completely changed the way it gathers the custom modelines and now it basically gets all active modelines and marks them as either custom or not, very much like your original methods, put back all the active modeline reading code I had removed.  Also I now actually treat active modelines as possible usable modelines (although without ability to change the refresh rates) yet they never will be chosen over a custom modeline (unless I have bugs there).  So there's a lot to test, but this might be really neat when it works right, which hopefully is now but I'm suspecting everything might not be perfect yet since it required quite a bit of changes.  Also this in theory will work really good with an ArcadeVGA 3000 card and avoid .ini files, although it's funny because now I realize you never can really get vsync with an arcade VGA 3000 card since how could you with it not even reporting the proper refresh rates for the modelines.  I guess with the Arcade Perfect utility you could tweak each games modeline chosen to match, and then know it through that, but wow that sounds like a pain in the butt to do for every single game by hand.  Well I basically default to using throttle and possible the other lesser things like triple buffer etc. if either it's a System modeline or ArcadeVGA3000 modeline. 

Anyone wanting to test this, great, otherwise stick to the previous 012d version for stability till Calamity confirms it's safe :).       
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 12, 2011, 07:43:42 am
with both jumpers attached, (allowing to launch low-res and hi-res games), my problem seems to be 640x480p isn't given priority over the jpac insisting on splitting the signal and displaying a split screen... i very confused!

Attaching both 15 and 31Khz jumpers is only intended for 15Khz monitors, to filter 31Khz signal and show it as split screen. Otherwise you should only use one jumper, depending on your monitor frequency range. What happens if you have a multisync monitor? I don't know :) I'd check if it works by removing all jumpers: that way your jpac sends composite sync, there's a chance your monitor will accept that.


therein lies my problem!

via the jpac, if i remove both jumpers, i get split screen, with vertical roll that can't be held.
but if i then install a jumper in 31khz, it snaps straight into place, with full screen and games like tekken launch perfectly.  obviously, 15khz games won't display.

when i bypass the jpac altogether (my preferred method) and go straight to the vga of the monitor, the picture rolls vertically and split screen, and ONLY when i tick the box in ATI CCC for 'composite sync' does it snap to fullscreen and holds perfectly.

unfortunately, on the live-cd, i don't have such an option.  i've even gone so far as to buy a vga breakout cable, and run it to the vga of the monitor, and have tried connecting every single possible combination of h/v sync, but can't get the picture to stop rolling vertically...

sorry to go off-topic, but i've spent four days now trying to get the bloody thing to stop rolling vertically via the linux install, but i'm stumped!  i feel like chucking the whole thing off my balcony!



what i need is an option for 'composite sync' in the linux install, as it is in the ati ccc, but i'm not sure if bitbytebit could achieve such a thing...

i'm gonna give it a rest for a week or two very soon, cos it's putting years on me!
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 12, 2011, 07:55:31 am
with both jumpers attached, (allowing to launch low-res and hi-res games), my problem seems to be 640x480p isn't given priority over the jpac insisting on splitting the signal and displaying a split screen... i very confused!

Attaching both 15 and 31Khz jumpers is only intended for 15Khz monitors, to filter 31Khz signal and show it as split screen. Otherwise you should only use one jumper, depending on your monitor frequency range. What happens if you have a multisync monitor? I don't know :) I'd check if it works by removing all jumpers: that way your jpac sends composite sync, there's a chance your monitor will accept that.


therein lies my problem!

via the jpac, if i remove both jumpers, i get split screen, with vertical roll that can't be held.
but if i then install a jumper in 31khz, it snaps straight into place, with full screen and games like tekken launch perfectly.  obviously, 15khz games won't display.

when i bypass the jpac altogether (my preferred method) and go straight to the vga of the monitor, the picture rolls vertically and split screen, and ONLY when i tick the box in ATI CCC for 'composite sync' does it snap to fullscreen and holds perfectly.

unfortunately, on the live-cd, i don't have such an option.  i've even gone so far as to buy a vga breakout cable, and run it to the vga of the monitor, and have tried connecting every single possible combination of h/v sync, but can't get the picture to stop rolling vertically...

sorry to go off-topic, but i've spent four days now trying to get the bloody thing to stop rolling vertically via the linux install, but i'm stumped!  i feel like chucking the whole thing off my balcony!



what i need is an option for 'composite sync' in the linux install, as it is in the ati ccc, but i'm not sure if bitbytebit could achieve such a thing...

i'm gonna give it a rest for a week or two very soon, cos it's putting years on me!

I don't know if it's really still supported, I'm hoping it is, but in Linux seems that adding Composite and possibly either +CSync or -CSync to the modeline enables composite sync.  I'll look into if that really is a valid option still.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 12, 2011, 08:44:12 am
I have made changes, 012e builds will show up in a few minutes.  I have completely changed the way it gathers the custom modelines and now it basically gets all active modelines and marks them as either custom or not, very much like your original methods, put back all the active modeline reading code I had removed.  Also I now actually treat active modelines as possible usable modelines (although without ability to change the refresh rates) yet they never will be chosen over a custom modeline (unless I have bugs there).  So there's a lot to test, but this might be really neat when it works right, which hopefully is now but I'm suspecting everything might not be perfect yet since it required quite a bit of changes.  Also this in theory will work really good with an ArcadeVGA 3000 card and avoid .ini files, although it's funny because now I realize you never can really get vsync with an arcade VGA 3000 card since how could you with it not even reporting the proper refresh rates for the modelines.  I guess with the Arcade Perfect utility you could tweak each games modeline chosen to match, and then know it through that, but wow that sounds like a pain in the butt to do for every single game by hand.  Well I basically default to using throttle and possible the other lesser things like triple buffer etc. if either it's a System modeline or ArcadeVGA3000 modeline. 

Anyone wanting to test this, great, otherwise stick to the previous 012d version for stability till Calamity confirms it's safe :).       

I can confirm it's not slow anymore at startup so the new method for storing video modes seems pretty good now. Anyway I'm testing on my lcd so I can't give a good report yet. I notice that in many situations no good match is found ("SwitchRes: Index -1/101 modeline  score 0.00 has no match") and then a bunch of undesired options are enabled (like hwstretch) and it gives ddraw the oportunity to make its own decisions. I think we should always come with a decision even if not a very good one, and completely override what ddraw decides. Also, the scoring system could be inverse, as in Switchres, so the bigger the score the worse the mode, that way you always make sure to have a rate for each mode. Being able to use native video modes is definitely a good thing, however we should be able to decide if we want to use them or not. For instance, when using my hacked drivers, native modes are still present but they run at 31Khz or whatever, so those are there in case we want to plug a lcd but should be avoided all the time for emulation with arcade monitors, some of them are even broken (320x and 400x ones). On the other hand, if using a lcd that is fixed to 60Hz, maybe it makes no sense to use modelines at all and better use the native video modes, so it's good to be able choose the best one. Even in that case, one could decide to turn vsync + soundsync on all the time to make all games run at 60Hz with smooth scrolling. The same is valid for ArcadeVGA 3000, we should not make decisions based on the fake vfreq label, as some advanced users might have tweaked their modes using ArcadePerfect so better give the opportunity to enable vsync + syncrefresh in all cases and let the user be responsible of mantaining his adjustments.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 12, 2011, 09:26:05 am
I have made changes, 012e builds will show up in a few minutes.  I have completely changed the way it gathers the custom modelines and now it basically gets all active modelines and marks them as either custom or not, very much like your original methods, put back all the active modeline reading code I had removed.  Also I now actually treat active modelines as possible usable modelines (although without ability to change the refresh rates) yet they never will be chosen over a custom modeline (unless I have bugs there).  So there's a lot to test, but this might be really neat when it works right, which hopefully is now but I'm suspecting everything might not be perfect yet since it required quite a bit of changes.  Also this in theory will work really good with an ArcadeVGA 3000 card and avoid .ini files, although it's funny because now I realize you never can really get vsync with an arcade VGA 3000 card since how could you with it not even reporting the proper refresh rates for the modelines.  I guess with the Arcade Perfect utility you could tweak each games modeline chosen to match, and then know it through that, but wow that sounds like a pain in the butt to do for every single game by hand.  Well I basically default to using throttle and possible the other lesser things like triple buffer etc. if either it's a System modeline or ArcadeVGA3000 modeline. 

Anyone wanting to test this, great, otherwise stick to the previous 012d version for stability till Calamity confirms it's safe :).       

I can confirm it's not slow anymore at startup so the new method for storing video modes seems pretty good now. Anyway I'm testing on my lcd so I can't give a good report yet. I notice that in many situations no good match is found ("SwitchRes: Index -1/101 modeline  score 0.00 has no match") and then a bunch of undesired options are enabled (like hwstretch) and it gives ddraw the oportunity to make its own decisions. I think we should always come with a decision even if not a very good one, and completely override what ddraw decides. Also, the scoring system could be inverse, as in Switchres, so the bigger the score the worse the mode, that way you always make sure to have a rate for each mode. Being able to use native video modes is definitely a good thing, however we should be able to decide if we want to use them or not. For instance, when using my hacked drivers, native modes are still present but they run at 31Khz or whatever, so those are there in case we want to plug a lcd but should be avoided all the time for emulation with arcade monitors, some of them are even broken (320x and 400x ones). On the other hand, if using a lcd that is fixed to 60Hz, maybe it makes no sense to use modelines at all and better use the native video modes, so it's good to be able choose the best one. Even in that case, one could decide to turn vsync + soundsync on all the time to make all games run at 60Hz with smooth scrolling. The same is valid for ArcadeVGA 3000, we should not make decisions based on the fake vfreq label, as some advanced users might have tweaked their modes using ArcadePerfect so better give the opportunity to enable vsync + syncrefresh in all cases and let the user be responsible of mantaining his adjustments.


Cool, I have made changes that mostly fit those issues.  I didn't reverse the scoring system, yet, but think I have worked around the need to.  Also now the logic will always skip interlaced modes if we've found a progressive, instead of just scoring them lower.  Also if there's a custom modeline, even one,  it'll always pick them over system ones.  Figure if a user has any custom modelines, then it says they aren't using an ArcadeVGA for sure, and probably aren't going to want system modelines in the way.  Also I removed that default options stuff when no modelines were found (which now should only happen when there are absolutely no system or custom modelines larger or equal to the height of the target resolution.

It'll be 012f and uploaded builds here in  a few minutes.   At least should address the major issues your seeing, can see how there could be some more improvement on setting choices/methods for users overriding them at times, and possibly the scoring system reversing although I think they way I'm doing it now might work as well.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 12, 2011, 01:11:46 pm
I'm stress testing the new one and works pretty well. No more stretching issues. Some games are far from perfect with the modes I have defined for this lcd, specially the ones that are 256 lines tall and many vertical rotated ones for the same reason: my monitor is hiding 512 lines modes, so it will go for 384 lines resulting in big borders. Of course this system is not optimal for emulation but somehow it's helping me detecting some issues that otherwise are masked when testing in my cab. I'm seeing how it would be good to also check for xres*3, yres*3 and maybe more, so here I would pick 768 lines to render 256*3 lines as a workaround. I'll have a look later at how you're doing your scoring system in case I can think something useful.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 12, 2011, 01:25:12 pm
I'm stress testing the new one and works pretty well. No more stretching issues. Some games are far from perfect with the modes I have defined for this lcd, specially the ones that are 256 lines tall and many vertical rotated ones for the same reason: my monitor is hiding 512 lines modes, so it will go for 384 lines resulting in big borders. Of course this system is not optimal for emulation but somehow it's helping me detecting some issues that otherwise are masked when testing in my cab. I'm seeing how it would be good to also check for xres*3, yres*3 and maybe more, so here I would pick 768 lines to render 256*3 lines as a workaround. I'll have a look later at how you're doing your scoring system in case I can think something useful.

Cool, yeah I've done another change that just basically allows a second pass at recalculating the modeline in the case that
the registry one was virtualized when it was calculated again if it didn't fit.  This really seems to only happen in cases like on
ntsc monitor types.  I ran into it while testing and basically it is where you get the modeline you want, find a registry modeline
that might be double or something, then recalculate that modeline with the refresh, and it virtualizes it to another resolution,
so then I go back and find that resolution from the registry or best match for it.  Seems to at least avoid the bad condition where
it's using a registry modeline with different height/width than it should be, and if it can't get the right height/width after the second
pass through the registry it gives up and just does throttling after that point.  It'll be up in a bit as 012g.

Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 12, 2011, 02:08:29 pm
This one is interesting. I think I found the issue with mk. It seems to happen only if changeres is enabled. When it's enabled, speed is 110% (although the log does not reflect that for some reason). If changeres is disabled, the modeline is properly updated and the game runs 100%. I think it has to do with the fact that after the resolution is switched, the same registry modeline is used again, and probably something goes wrong after resetting it:

SwitchRes: Setting Option -waitvsync
SwitchRes: Setting Option -resolution 400x384@60
SwitchRes: [2] Resetting Custom modeline DALDTMCRTBCD400X384X0X60 to original values...
SwitchRes: Set Registry mode DALDTMCRTBCD400X384X0X60 with:
SwitchRes: (61206/61206/61206) Modeline 15.880000 400 408 472 504 384 442 444 525

...so it wouldn't be necessary to reset to the original values if the same one is going to be used again, until you actually exit, although I don't know if that would be easy to do or would break something else.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 12, 2011, 02:21:04 pm
This one is interesting. I think I found the issue with mk. It seems to happen only if changeres is enabled. When it's enabled, speed is 110% (although the log does not reflect that for some reason). If changeres is disabled, the modeline is properly updated and the game runs 100%. I think it has to do with the fact that after the resolution is switched, the same registry modeline is used again, and probably something goes wrong after resetting it:

SwitchRes: Setting Option -waitvsync
SwitchRes: Setting Option -resolution 400x384@60
SwitchRes: [2] Resetting Custom modeline DALDTMCRTBCD400X384X0X60 to original values...
SwitchRes: Set Registry mode DALDTMCRTBCD400X384X0X60 with:
SwitchRes: (61206/61206/61206) Modeline 15.880000 400 408 472 504 384 442 444 525

...so it wouldn't be necessary to reset to the original values if the same one is going to be used again, until you actually exit, although I don't know if that would be easy to do or would break something else.

Ah interesting, I had actually thought about if that were a possibility and to avoid switching if the outcome resolution is the same anyways.  I'll have to actually figure out how to change that to work right in that case, and just not do the switch since it is already the best it can do.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 12, 2011, 03:05:02 pm
This one is interesting. I think I found the issue with mk. It seems to happen only if changeres is enabled. When it's enabled, speed is 110% (although the log does not reflect that for some reason). If changeres is disabled, the modeline is properly updated and the game runs 100%. I think it has to do with the fact that after the resolution is switched, the same registry modeline is used again, and probably something goes wrong after resetting it:

SwitchRes: Setting Option -waitvsync
SwitchRes: Setting Option -resolution 400x384@60
SwitchRes: [2] Resetting Custom modeline DALDTMCRTBCD400X384X0X60 to original values...
SwitchRes: Set Registry mode DALDTMCRTBCD400X384X0X60 with:
SwitchRes: (61206/61206/61206) Modeline 15.880000 400 408 472 504 384 442 444 525

...so it wouldn't be necessary to reset to the original values if the same one is going to be used again, until you actually exit, although I don't know if that would be easy to do or would break something else.

Ah interesting, I had actually thought about if that were a possibility and to avoid switching if the outcome resolution is the same anyways.  I'll have to actually figure out how to change that to work right in that case, and just not do the switch since it is already the best it can do.

I uploaded a new build, same version number.  I hopefully fixed it, so that now it will not re-modify a modeline and just skip the rewrite of it, and then be able to reset it properly at the end too again.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 12, 2011, 05:29:25 pm
I uploaded a new build, same version number.  I hopefully fixed it, so that now it will not re-modify a modeline and just skip the rewrite of it, and then be able to reset it properly at the end too again.

This new version fixes mk issue and everything else works fine  ;)

Please have a look at gtmr log, there's a bug because it's using a system video mode thinking its a custom one and so editing the registry when it shouldn't.

There's also a problem with Capcom games when using doubled resolutions, but it's not Switchres related, rather it seems internal to the ddraw routines. The right mode 768x224 is selected for 384x224 but the frame is not scaled for some reason. It's interesting because this doesn't happen on my other system (lcd). The logs look ok (ghouls.txt). Of course this doesn't happen either if a 384x224 modeline exists, but it's interesting because it seems a exception. Maybe some other systems/resolutions are affected but this is the only one I've found.

I've checked that -keepaspect is necessary for non-virtualized rotated vertical games, like pacman, when we're using a doubled resolution. I don't know if that would have any side effect on the Linux side, here it looks innocuous.

Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 12, 2011, 06:51:19 pm
I uploaded a new build, same version number.  I hopefully fixed it, so that now it will not re-modify a modeline and just skip the rewrite of it, and then be able to reset it properly at the end too again.

This new version fixes mk issue and everything else works fine  ;)

Please have a look at gtmr log, there's a bug because it's using a system video mode thinking its a custom one and so editing the registry when it shouldn't.

There's also a problem with Capcom games when using doubled resolutions, but it's not Switchres related, rather it seems internal to the ddraw routines. The right mode 768x224 is selected for 384x224 but the frame is not scaled for some reason. It's interesting because this doesn't happen on my other system (lcd). The logs look ok (ghouls.txt). Of course this doesn't happen either if a 384x224 modeline exists, but it's interesting because it seems a exception. Maybe some other systems/resolutions are affected but this is the only one I've found.

I've checked that -keepaspect is necessary for non-virtualized rotated vertical games, like pacman, when we're using a doubled resolution. I don't know if that would have any side effect on the Linux side, here it looks innocuous.



I changed the scoring system, the part finding the best score after they were all scored, split it up into categories so hopefully now the system resolutions and interlaced ones are put into lower priority unless no custom ones exist that were scored at all.  I think this will fix that issue, I still need to look at keepaspect some since I should probably set it sometimes when it isn't getting set.  Version 012h will have this fix, should have builds up soon. Definitely a bit tricky getting the scoring right for having the custom/system modes and then looking at them differently if interlaced, but what I've done now might make it work right in most cases.

Update: Just made a change, trying to set keepaspect when the width isn't the desired resolution like a doubled one with vertical games.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 13, 2011, 04:01:53 am
I uploaded a new build, same version number.  I hopefully fixed it, so that now it will not re-modify a modeline and just skip the rewrite of it, and then be able to reset it properly at the end too again.

This new version fixes mk issue and everything else works fine  ;)

Please have a look at gtmr log, there's a bug because it's using a system video mode thinking its a custom one and so editing the registry when it shouldn't.

There's also a problem with Capcom games when using doubled resolutions, but it's not Switchres related, rather it seems internal to the ddraw routines. The right mode 768x224 is selected for 384x224 but the frame is not scaled for some reason. It's interesting because this doesn't happen on my other system (lcd). The logs look ok (ghouls.txt). Of course this doesn't happen either if a 384x224 modeline exists, but it's interesting because it seems a exception. Maybe some other systems/resolutions are affected but this is the only one I've found.

I've checked that -keepaspect is necessary for non-virtualized rotated vertical games, like pacman, when we're using a doubled resolution. I don't know if that would have any side effect on the Linux side, here it looks innocuous.



I changed the scoring system, the part finding the best score after they were all scored, split it up into categories so hopefully now the system resolutions and interlaced ones are put into lower priority unless no custom ones exist that were scored at all.  I think this will fix that issue, I still need to look at keepaspect some since I should probably set it sometimes when it isn't getting set.  Version 012h will have this fix, should have builds up soon. Definitely a bit tricky getting the scoring right for having the custom/system modes and then looking at them differently if interlaced, but what I've done now might make it work right in most cases.

Update: Just made a change, trying to set keepaspect when the width isn't the desired resolution like a doubled one with vertical games.

Will test that later. However, just to make sure, the issue with gtmr is, rather than using a system video mode (that is a bad thing), is that it *creates* a new DAL... registry entry that does not exist at first hand, so after that I need to manually edit the registry to remove it.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 13, 2011, 09:09:13 am
I uploaded a new build, same version number.  I hopefully fixed it, so that now it will not re-modify a modeline and just skip the rewrite of it, and then be able to reset it properly at the end too again.

This new version fixes mk issue and everything else works fine  ;)

Please have a look at gtmr log, there's a bug because it's using a system video mode thinking its a custom one and so editing the registry when it shouldn't.

There's also a problem with Capcom games when using doubled resolutions, but it's not Switchres related, rather it seems internal to the ddraw routines. The right mode 768x224 is selected for 384x224 but the frame is not scaled for some reason. It's interesting because this doesn't happen on my other system (lcd). The logs look ok (ghouls.txt). Of course this doesn't happen either if a 384x224 modeline exists, but it's interesting because it seems a exception. Maybe some other systems/resolutions are affected but this is the only one I've found.

I've checked that -keepaspect is necessary for non-virtualized rotated vertical games, like pacman, when we're using a doubled resolution. I don't know if that would have any side effect on the Linux side, here it looks innocuous.



I changed the scoring system, the part finding the best score after they were all scored, split it up into categories so hopefully now the system resolutions and interlaced ones are put into lower priority unless no custom ones exist that were scored at all.  I think this will fix that issue, I still need to look at keepaspect some since I should probably set it sometimes when it isn't getting set.  Version 012h will have this fix, should have builds up soon. Definitely a bit tricky getting the scoring right for having the custom/system modes and then looking at them differently if interlaced, but what I've done now might make it work right in most cases.

Update: Just made a change, trying to set keepaspect when the width isn't the desired resolution like a doubled one with vertical games.

Will test that later. However, just to make sure, the issue with gtmr is, rather than using a system video mode (that is a bad thing), is that it *creates* a new DAL... registry entry that does not exist at first hand, so after that I need to manually edit the registry to remove it.


Yeah hopefully I fixed that since that version, at least now should not be possible to write what wasn't a custom modeline, will see.  In 012i 012j I've possibly really fixed the keepaspect issue, was checking after instead of before I should have for that.  Also have the output a bit better so should be more easy to see if it's writing, and which modelines are system by the labels now.  I'm re-uploading 012i 012j right now actually, so make sure it's timestamped after this post :).  Should be a couple minutes before it's done.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 13, 2011, 04:58:11 pm
This new version is working great. The pick best mode function does it's job pretty well, I still need to test more to find problems if there are any. Vertical games with -keepaspect now look good with doubled resolutions.

The only feature I somehow miss is that when a given resolution is selected from command line it would actually be used for modeline calculation bypassing the pick best mode function. In fact, the resolution specified from command line is actually used later by direct draw, so the modified modeline is not used anyway. This would be very handy for testing purposes.

I still have the issue with games using 384x224 -> 768x224 (does not scale xres*2). It's interesting because 384x240 -> 768x240 works fine. I'm thinking it could be related to a possible aspect ratio check done somewhere in the ddraw side. It's a shame because it's the only problem I'm seeing with this doubled resolutions system. I'm interested in fixing this as it could be a possible way of reducing the needed modetable a lot. There's an additional benefit when doubling resolutions: we have a finer granularity both for dotclocks and porches, so at least in theory we could get more accurate refresh rates and differences in centering between modes would be smaller.

For anyone is following this thread, I would like to make clear that these issues don't happen if we install a normal mode table, so all this has been working fine for some time already. It's just that we are trying to make it more versatile for using special experimental mode tables, like the ones with doubled resolutions. So don't get discouraged to use it just because I keep reporting problems everyday :)

Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 13, 2011, 05:10:46 pm
This new version is working great. The pick best mode function does it's job pretty well, I still need to test more to find problems if there are any. Vertical games with -keepaspect now look good with doubled resolutions.

The only feature I somehow miss is that when a given resolution is selected from command line it would actually be used for modeline calculation bypassing the pick best mode function. In fact, the resolution specified from command line is actually used later by direct draw, so the modified modeline is not used anyway. This would be very handy for testing purposes.

I still have the issue with games using 384x224 -> 768x224 (does not scale xres*2). It's interesting because 384x240 -> 768x240 works fine. I'm thinking it could be related to a possible aspect ratio check done somewhere in the ddraw side. It's a shame because it's the only problem I'm seeing with this doubled resolutions system. I'm interested in fixing this as it could be a possible way of reducing the needed modetable a lot. There's an additional option when doubling resolutions: we have a finer granularity both for dotclocks and porches, so at least in theory we could get more accurate refresh rates and differences in centering between modes would be smaller.

For anyone is following this thread, I would like to make clear that these issues don't happen if we install a normal mode table, so all this has been working fine for some time already. It's just that we are trying to make it more versatile for using special experimental mode tables, like the ones with doubled resolutions. So don't get discouraged to use it just because I keep reporting problems everyday :)



Cool, yeah I was hoping I finally got the scoring system working right or at least close, was worried after seeing the last issue and rewriting the way to compare system/interlaced/custom ones properly. 

Isn't the input though possibly forced by doing -resolution args or a .ini file one, either should force it to what you want to be used for the game.  I'm not sure if that's exactly going to fit, but guessing it should essentially do the same thing (unless there's bugs in that vs. the scoring/modeline enumeration code).

Hopefully we get some results from ArcadeVGA3000 testing, I'm really curious how that works, since this should really be able to interact with that card as much as possible and choose it's internal resolutions dynamically instead of using .ini files.  Also I'm curious what the actual output of the resolutions from the enumeration looks like, would help know if there's any improvements that could still be made. 

Also there's the question still of how to properly allow overriding the throttling when using system modes, how to really know if the refresh rate is correct (like with the ArcadeVGA3000).  If there's no way built into the system at all, and we just blindly hope it's a good refresh to use vsync, a manual command/.ini file option seems awful painful to require since a user has to go through each game and decide or setup the ArcadePerfect utility (still wish that utility could be automated, seems like it could automatically be made to tweak the refresh rate, it should know what the game uses from mame, or we could tell it).  Also like the ArcadePerfect utility, I'm guessing the PowerStrip refresh rate change API call might be interesting with system resolutions, and then we'd mostly work with any card that PowerStrip supported and users could add custom resolutions through powerstrip if they needed, and we would just change the refresh rate with it.  Otherwise I don't see a way to use system resolutions without throttling, or actually triplebuffer I guess.  By the way, what settings are needed to have nothrottle and triple buffer, is it really that triplebuffer takes care of it without vsync?  I'm wondering because I was testing and I swear it had issues with triplebuffer without throttle or vsync, still ran full speed instead of proper speed, but it might just be my system I was testing on.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 13, 2011, 06:30:10 pm
Isn't the input though possibly forced by doing -resolution args or a .ini file one, either should force it to what you want to be used for the game.  I'm not sure if that's exactly going to fit, but guessing it should essentially do the same thing (unless there's bugs in that vs. the scoring/modeline enumeration code).

Yes, it listens the -resolution args and directdraw uses that resolution, but the modeline calculator still recalculates the one chosen by the pick best mode function, so the recalculated modeline is never used. It's not important anyway, just could be nice if the modeline calculator tried to use the resolution I pass, very useful at least in this testing phase, to compare with its own decisions and other situations when it'd become handy. I'm guessing it would require additional checks to make sure we pass a reasonable resolution, so I would leave it as it is by now.

Also there's the question still of how to properly allow overriding the throttling when using system modes, how to really know if the refresh rate is correct (like with the ArcadeVGA3000).  If there's no way built into the system at all, and we just blindly hope it's a good refresh to use vsync, a manual command/.ini file option seems awful painful to require since a user has to go through each game and decide or setup the ArcadePerfect utility (still wish that utility could be automated, seems like it could automatically be made to tweak the refresh rate, it should know what the game uses from mame, or we could tell it).  Also like the ArcadePerfect utility, I'm guessing the PowerStrip refresh rate change API call might be interesting with system resolutions, and then we'd mostly work with any card that PowerStrip supported and users could add custom resolutions through powerstrip if they needed, and we would just change the refresh rate with it.  Otherwise I don't see a way to use system resolutions without throttling, or actually triplebuffer I guess.  By the way, what settings are needed to have nothrottle and triple buffer, is it really that triplebuffer takes care of it without vsync?  I'm wondering because I was testing and I swear it had issues with triplebuffer without throttle or vsync, still ran full speed instead of proper speed, but it might just be my system I was testing on.

Yes it's the classical problem with the programs that have tried to do this before like Mame Res Tool and AVres. I think that if I had an ArcadeVGA3000 I'd like GroovyMame to have an option to "always force vsync", even if some games where slowed/accelerated, but at least avoid tearing and run smooth. Then launching GroovyMame from ArcadePerfect and press f-11 and if it's not 100%, tweak the mode from there so the next time it'll run fine. At least that's how that's intended to be used. Then if you disable that "always force vsync" option, it would use the normal throttling scheme in case we where too far from the theoric vfreq, and so bear with tearing.

Enabling triplebuffer in this suboptimal situation will remove tearing but produce scroll hiccups. Tripebuffer does wait for vsync on its own, so it get's in the middle of throttle. IMHO I see no benefit in using triplebuffer. Anyway, I think it was running full speed in your case because we didn't add it to the multithreading patch, here (winwindow_video_window_update):

+            if ((video_config.waitvsync || video_config.syncrefresh) && video_config.mode != VIDEO_MODE_GDI)

Yes, being able to drive PowerStrip from GroovyMame could be the ultimate solution for any card. The possibilities are great. This is an old post but shows some amazing use of PowerStrip's api.

http://forum.doom9.org/archive/index.php/t-73874.html (http://forum.doom9.org/archive/index.php/t-73874.html)
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 14, 2011, 07:35:23 am
I don't know if it's really still supported, I'm hoping it is, but in Linux seems that adding Composite and possibly either +CSync or -CSync to the modeline enables composite sync.  I'll look into if that really is a valid option still.

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

At the minute, i'm forced to run the vga via the jpac (jumpered both 15&31), but this is defeating the whole purpose of having a tri-sync monitor...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 14, 2011, 08:12:19 am
I'd be most grateful if you could at least find the time to look into this, as i am at my wits end trying to get the vertical roll to hold properly.

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

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

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

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

(by doing this you will actually use a single hfreq range, so multisync capabilities will not be used but in case that works then it will be possible to fix your monitor definition).
 
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 14, 2011, 09:24:34 am
I don't know if it's really still supported, I'm hoping it is, but in Linux seems that adding Composite and possibly either +CSync or -CSync to the modeline enables composite sync.  I'll look into if that really is a valid option still.

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

At the minute, i'm forced to run the vga via the jpac (jumpered both 15&31), but this is defeating the whole purpose of having a tri-sync monitor...
I'm thinking this is the best option, I've been looking into the composite sync in Linux and so far I really don't see that it can work there with the +CSync option.  From my tests that option doesn't seem to do anything, and from researching people seem to have found the same conclusion.  So hopefully changing the positive values like Calamity is saying will work, and then can setup a monitor definition with those. 
Title: Re: Switchres modeline generator and emulator wrapper
Post by: newmanfamilyvlogs on April 14, 2011, 10:51:56 am
When an ATI Driver crashes and it does the "VPU Recovery" thing after a driver crash it essentially re-loads the drivers, right? Does it re-enumerate available video modes from the registry when it does?

If that's the case I wonder if it would be possible to invoke that action on purpose and add/remove modelines at run time instead of only altering existing modes....
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 14, 2011, 11:03:45 am
When an ATI Driver crashes and it does the "VPU Recovery" thing after a driver crash it essentially re-loads the drivers, right? Does it re-enumerate available video modes from the registry when it does?

If that's the case I wonder if it would be possible to invoke that action on purpose and add/remove modelines at run time instead of only altering existing modes....

There is a way to dynamically reload video drivers, explained here:

http://msdn.microsoft.com/en-us/library/ff568527%28v=vs.85%29.aspx (http://msdn.microsoft.com/en-us/library/ff568527%28v=vs.85%29.aspx)

I did some testing with that method and unfortunately it doesn't re-enumerate video modes. So I understand that is Windows itself the one which polls the video driver for available video modes during system startup, and it doesn't repeat that operation even if the driver is reloaded later. If that's the case (I can just analize evidence, there's no documentation about this that I have found), then we should actually hack Windows itself to do what we want.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: newmanfamilyvlogs on April 14, 2011, 01:02:03 pm
That list still has to reside somewhere, and I'd bet it's in the registry and not just in ram..
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 14, 2011, 02:10:40 pm
That list still has to reside somewhere, and I'd bet it's in the registry and not just in ram..

Yes, possibly, I don't really know. Anyway, even PowerStrip needs to restart Windows in order to add new video modes, afaik, so probably it's just a Windows limitation.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 14, 2011, 02:37:26 pm
I'd be most grateful if you could at least find the time to look into this, as i am at my wits end trying to get the vertical roll to hold properly.

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

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

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

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

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

BINGO!!

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

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

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

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

getting there... :)
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 14, 2011, 02:46:08 pm
I'd be most grateful if you could at least find the time to look into this, as i am at my wits end trying to get the vertical roll to hold properly.

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

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

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

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

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

BINGO!!

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

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

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

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

getting there... :)

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

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

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

Update 2: I'm uploading new ISO images with this change right now, so will have an option for your monitor to try, labeled m3192 (under the MultiSync monitor type submenu of the video setup monitor type menu.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 15, 2011, 01:38:20 am
Update 2: I'm uploading new ISO images with this change right now, so will have an option for your monitor to try, labeled m3192 (under the MultiSync monitor type submenu of the video setup monitor type menu.

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

I will post back with a verdict.

Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 15, 2011, 08:31:36 am
0,0 = rolling screen (as before)
0,1 = rolling screen (as before)
1,0 =  perfect sync, although the screen was about 3 inches left of center
1,1 - perfect sync, although the screen was about 1 cm right of center

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

Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 15, 2011, 08:47:24 am
Hi bitbytebit,

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

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


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

So does tripplebuffer without throttle or vsync really not work with the current groovymame code, or go full speed.  From what I can tell the ArcadeVGA report is that it worked that way actually, my system setup I tested it on would not be one to judge it by.  So I'm curious that it might actually work that way so it'd be another possible option?    Would it be best to have it just always use vsync and if the user picks tripplebuffer manually would that solve the too slow/fast speed issues? (if they want that). 
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 15, 2011, 09:17:15 am
It's currently using tripple buffer without throttle or vsync.  I plan on changing that, to what your saying, it's the next thing actually I've been planning on doing this week.  Hopefully tonight or tomorrow I'll be able to get that to be more flexible so that it can default to the vsync and soundsync, but if desired (like if tripplebuffer is set) then it'll go that route. 

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

Well, at least in theory, with the current patch, triplebuffer would need throttle to avoid going full speed, *unless* you disabled multithreading (so it would be as your test). I hadn't thought about that until you mentioned the other day. That's because if vsync is not set, the draw procedure still occurs in the window thread, as triplebuffer is not one of the conditions we check for doing it the other way. So the wait for vsync occurs before flipping but the main thread doesn't wait. BTW, I think this is the way triplebuffer should have always worked. (more on this later)
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 15, 2011, 09:24:02 am
It's currently using tripple buffer without throttle or vsync.  I plan on changing that, to what your saying, it's the next thing actually I've been planning on doing this week.  Hopefully tonight or tomorrow I'll be able to get that to be more flexible so that it can default to the vsync and soundsync, but if desired (like if tripplebuffer is set) then it'll go that route.  

So does tripplebuffer without throttle or vsync really not work with the current groovymame code, or go full speed.  From what I can tell the ArcadeVGA report is that it worked that way actually, my system setup I tested it on would not be one to judge it by.  So I'm curious that it might actually work that way so it'd be another possible option?    Would it be best to have it just always use vsync and if the user picks tripplebuffer manually would that solve the too slow/fast speed issues? (if they want that).  
Well, at least in theory, with the current patch, triplebuffer would need throttle to avoid going full speed, *unless* you disabled multithreading (so it would be as your test). I hadn't thought about that until you mentioned the other day. That's because if vsync is not set, the draw procedure still occurs in the window thread, as triplebuffer is not one of the conditions we check for doing it the other way. So the wait for vsync occurs before flipping but the main thread doesn't wait. BTW, I think this is the way triplebuffer should have always worked. (more on this later)

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

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


Update:

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

Code: [Select]

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



Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 15, 2011, 11:57:11 am
So should possibly vsync be toggled on too with triplebuffer just to make it behave, or would that be bad? Or possibly use throttle with it? At least to try and use multithreading, since right now groovymame expects to always use multithreading.

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

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

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

[continues...]



Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 15, 2011, 12:36:39 pm
So should possibly vsync be toggled on too with triplebuffer just to make it behave, or would that be bad? Or possibly use throttle with it? At least to try and use multithreading, since right now groovymame expects to always use multithreading.

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

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

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

[continues...]





Cool, I put a check in and if triplebuffer and multithreading are set it uses throttle, else if only triplebuffer it doesn't.  New builds are up with this change now.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 15, 2011, 12:46:52 pm
We can benefit from the fact that in Windows, there are to different options for vsync that at the moment do just the same: syncrefresh and waitvsync. We could actually use 'syncrefresh' as the active option instead of triplebuffer, to force sync to video card refresh, in any situation. And 'waitvsync' apart, as an option. Here is just a suggested logic that might cover all situations probably, anyway just let me know what you think.

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

ELSE
  ; Let groovymame decide

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

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

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

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

EDIT: I modified the options a bit, now I think are better. Also, this assumes multithreading is ON.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 15, 2011, 04:52:25 pm
Update 2: I'm uploading new ISO images with this change right now, so will have an option for your monitor to try, labeled m3192 (under the MultiSync monitor type submenu of the video setup monitor type menu.

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

I will post back with a verdict.


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

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

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

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

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

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

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

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

regards, and thanks again!
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 15, 2011, 05:26:58 pm
Update 2: I'm uploading new ISO images with this change right now, so will have an option for your monitor to try, labeled m3192 (under the MultiSync monitor type submenu of the video setup monitor type menu.

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

I will post back with a verdict.


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

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

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

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

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

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

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

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

regards, and thanks again!

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

Update:

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

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

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

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

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

Calamity might have more ideas from what your seeing what to change with the porch values etc, at least try them each with the sync altered though to see if that makes a big difference.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 15, 2011, 05:56:50 pm
Try editing the range for low resolutions, values into [] are front and back horizontal porches.

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

(they can't be zero)

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

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

Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 16, 2011, 01:03:03 pm
CRT_EmuDriver based on Catalyst 6.5 for Windows XP64 is finally ready!

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

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

More info here (Spanish):

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

Here are the files:

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

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

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

crt_emudriver_9.3_1.2_xp32_multisync.rar
http://www.megaupload.com/?d=LAYG0YYF (http://www.megaupload.com/?d=LAYG0YYF)
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 16, 2011, 02:37:19 pm
Tried running the switchres command with trackfld, and its uses the 15khz range.

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

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

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

Not sure if you are able to easily loacate the porch/pulse values for either of those and i could try them my side...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 16, 2011, 05:02:01 pm
Oh I meant in the mame.ini use monitor_specs and then from there the values, switchres isn't used, the config option I gave was the switchres one so might have been confusing.  You can also use the cmdline with groovymame and give it -monitor_specs too, so can make changes quicker that way.

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

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

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

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

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

Not sure if you are able to easily loacate the porch/pulse values for either of those and i could try them my side...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 17, 2011, 12:09:59 pm
MonkeyJug,

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

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

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

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

Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 17, 2011, 01:01:01 pm

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

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

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


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

sudo emerge -av groovymame

And it should download and recompile with this change, and also the old -monitor_specs argument won't work anymore and must have 0 at the end if it to do the same thing.  I'll update the patch and windows builds here in a bit, but it's in the git repository right now.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 17, 2011, 01:47:23 pm
8 ranges? I thought the maximum was 6 for D9800, my definitions are probably outdated then...

It's great you added that too, now it will be very flexible and versatile for testing new monitors.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 17, 2011, 01:54:04 pm
8 ranges? I thought the maximum was 6 for D9800, my definitions are probably outdated then...

It's great you added that too, now it will be very flexible and versatile for testing new monitors.
I didn't check, it at least that will give it even more just in case someone wants to really explore the in between ranges like around 20khz and 29khz where I have basically blocked out the range since those areas don't act right.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 18, 2011, 04:36:18 am
MonkeyJug,

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

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

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

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



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

any ideas what i'm doing wrong?
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 18, 2011, 05:17:26 am
i'm trying to do this, but the options for 'edit modeline' and 'horizontal geometry' are greyed out and can't be selected...

any ideas what i'm doing wrong?

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

Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 18, 2011, 06:59:38 am
i'm trying to do this, but the options for 'edit modeline' and 'horizontal geometry' are greyed out and can't be selected...

any ideas what i'm doing wrong?

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



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

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

when arcade_osd starts, it says 'crt-emudriver found' in green, but all 120 resolutions are showing as native...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 18, 2011, 07:16:58 am

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

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

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

Oh, really strange  :P

I've attached a test version that does not gray the options for native modes. You'll be able to get into the options with this one. I'm interested to know if you see the options full of zero values (for the modes that are suposed to be custom, like 320x224, 384x256 and such), that would mean there's a problem reading the registry modelines.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 18, 2011, 08:05:44 am

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

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

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

Oh, really strange  :P

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


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

and yes, in edit mode, every single modeline is full of zeros.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 18, 2011, 08:40:09 am

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

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

Ugly stuff... I've attached a new one that changes a flag when accessing registry, it might help but I doubt it'll make any difference. I'll need to do a version that actually logs error messages...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 18, 2011, 09:43:17 am
well, it's game over for me...

monitor finally said enough is enough!

i updated groovymame via the sudo command, then rebooted.

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

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

wouldn't mind, but getting a tri-sync monitor in the uk is impossible nowadays...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 18, 2011, 10:00:35 am
Oh ---steaming pile of meadow muffin---!! That's the worse thing we can hear... I'm so sorry about that man. Hopefully it'll be possible to repair it.

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

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

Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 18, 2011, 10:21:00 am
i'm not sure what happened really.  maybe i had a typo in the monitor_specs line.  ah well, not sure if it can be repaired, and to be honest, i'm not even sure i would want to - that monitor has been nothing but a curse for me!!

i had a quick look on ebay and saw this:

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

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

any of you guys got any experience with this monitor?
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 18, 2011, 02:43:29 pm
MonkeyJug, I've no experience with that monitor, anyway it looks good and new. It's nearly impossible to get a multisync monitor down here in Spain too and it's so expensive to send or import them... I should have done it when they were available.

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

There's something strange too with the aspect ratio thing. If you see the old logs (h and j) they look exactly the same, but h has correct aspect ratio, while j is wide-screen. This is confusing. Hopefully in some days I'll make a deeper testing of many games. Also assuming a 0.02 Hz difference as "Vfreq Change" and go for the throttle route seems too conservative to me, we won't get se accurate in Windows most of the time.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 18, 2011, 03:00:11 pm
MonkeyJug, I've no experience with that monitor, anyway it looks good and new. It's nearly impossible to get a multisync monitor down here in Spain too and it's so expensive to send or import them... I should have done it when they were available.

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

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


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

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

Update:  Ok, 012m is uploaded, see if it still has issues with setting the .ini file.  Also now the .ini resolution setting should for the most part override the games resolution even for vertical games.   Seems my logic was checking that before the vertical calculations were done, now it is done afterwards and completely lets you choose the resolution that is calculated even if the game is a vertical or double screen one.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 18, 2011, 05:37:48 pm
Testing 012m. Please have a look at this log. It's filling a 512x512 modeline with the wrong height/width values.
The resolution option seems fixed however.

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

BTW I'm testing on a laptop with nVidia card, the custom modelines are fake ones I put in the registry just for testing, but that should not be a problem.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 18, 2011, 06:52:18 pm
Testing 012m. Please have a look at this log. It's filling a 512x512 modeline with the wrong height/width values.
The resolution option seems fixed however.

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

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


Seems like it's constrained by having those few custom modelines available, so does't look very hopeful for it to be able to do the right thing at  all actually and it's trying to use 512x512 but that is too small so it looks to fail at calculating to that resolution.  From what I can tell it's a rare case where it tried twice to adjust to the resolution and fails both times, I'm still trying to figure out exactly what should be done though in that case.  I'm a bit confused exactly what is totally happening there, but is this probably a rare case or even with a full setup of modelines do you think it's having some issues similar too?
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 23, 2011, 08:58:10 am
Well, I've done lots of tests with all imaginable combinations, in order to check how to triplebuffer properly. I've seen that using DDBLT_ASYNC and DDFLIP_DONOTWAIT params does not help at all and the Flip function still waits and does not return inmediately, so there's no way to make truly asynchronous vsync flipping by just using the DirectDraw api. It would be possible to implement it by doing our own flipping thread but that would involve major changes to the Mame source, so I'd forget that.

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

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

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

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

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

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

Also, this option is great for 3d games as tekken where the syncrefresh option is making them run slower than possible. Unfortunately with the logic I suggested those games are usually forced to vsync as their refresh matches the modeline's vfreq but it would be nice to be able to disable syncrefresh in these cases and do throttle + triplebuffer, so I can see my logic doesn't work for these cases or at least needs some improvement.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 23, 2011, 03:43:17 pm
Ok, I just ran DXDiag and Ddraw is enable and passes all three tests.
I also verified I have a whole load of modelines active. Not sue if its 120  but it looks like it.

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

Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 23, 2011, 04:15:37 pm
Yeah, fortunately your modelines are available so the driver looks ok. There's something odd with mode selection, please try with latest groovymame just to see if it makes any difference and that bug is already solved, your logs say your using v0.012m. Well what happens is groovymame is acting as if you had a cga monitor, even if it says D9800 in your logs, so it's calculating only with it's lower range and not using the higher resolutions available. Probably bitbytebit will know what the issue may be. Try deleting any monitor_specs line you have in groovymame.ini just in case, this could have been caused since the last change when those ranges where added.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 23, 2011, 04:28:18 pm
I am usinging the latest groovymame. Version n. not m
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 23, 2011, 04:31:52 pm
mayne its a bug in the n version that doesnt show correct version but it is n
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 23, 2011, 04:41:11 pm
mayne its a bug in the n version that doesnt show correct version but it is n

Yes, probably. Anyway, in your donpachi log:

SwitchRes: Entering switchres_modeline_setup (0)
SwitchRes: Monitor: D9800 Orientation: horizontal Aspect 4:3
SwitchRes: MonitorLimits 15250.00-15700.00,49.50-65.00,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288.0,448
SwitchRes: Setup monitor limits min=184x108 max=0x608

... it says D9800 but you only have a range available ("monitorlimits"), you should have several ranges there. Then when selecting the resolution it's doing this:

SwitchRes v0.012m: [donpachi] (1) vertical (320x240@57.55)->(432x320@57.55)->(664x496@57.55)
SwitchRes: # donpachi 664x496@57.55 15.4523Khz

So it's virtualizing the resolution as if it was a cga monitor, however you have your 432x320 resolution available and ready for use:

SwitchRes: 432 x 320 -> 0.00 Custom Modeline

So it must be a silly bug, I'm sure this has worked for me before some time ago, if you feel like testing with older versions here they are:
http://mario.groovy.org/GroovyMame/0142/Archives/ (http://mario.groovy.org/GroovyMame/0142/Archives/)

anyway I'd wait until this can be fixed.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 23, 2011, 05:08:16 pm
Ok

Tried it with version A of groovymam 142 and it works alot better but donpachi small center and small and still looked interlaced. dkong looks great but had some sound stutter.
 I guess ill wait for new version and i can test more.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 23, 2011, 05:15:50 pm
Sound stutter can be fixed with -soundsync enabled. However the fact that you have sound stutter means groovymame is not getting the right refresh for that particular game when it should be doing if you have a multisync monitor like yours.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 23, 2011, 05:36:01 pm
the D9800 is the problem, needs to be loewcase d9800.  it's defaulting to cga cause of that :)
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 23, 2011, 05:45:06 pm
 :D good to hear that, I knew it had worked for me before!
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 23, 2011, 06:30:14 pm
Wow!!!

Everything works great now. I did not have to set pixel clock to 7.5 it works fine set at 0 default.

Do I have to also change to lowercase d9800 in the VMMaker.ini also?

Is there a way to get rid of nag screen before launch rom?
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 23, 2011, 06:33:01 pm
Also, I cant run Hyperspin. I knew there was a bug with it but I thought that was anything over then 120 modelines?


IS there a way to use less modelines so I can still use Hyperspin?
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 24, 2011, 05:25:50 am
Those are good news, so your X1950XT can work with low dotclocks, good to know.

VMMaker will convert all params to uppercase anyway so you don't need to change it.

I think there's an option in Mame.ini to get rid of nag screens, just need to confirm.

Yes, the Hyperspin issue... what matters is the total amount of video modes in the system, not just modelines, so CRT_Emudriver 6.5 was restricting anything but its modelines, so with 160 modelines Hyperspin will still load, but this 9.3 version is not restricting anything because its patch is different so it has its 120 modelines plus the native ones in the system. So you could play with the TotalModes param in VMMaker reducing it and recalculating modelines. But doing that many of your games will not use their best possible resolution. Probably Hyperspin needs to reserve more memory to store the total list of video modes in the system, Hyperspin author said he would check that for version 2.0.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 24, 2011, 08:29:01 am
Is there a way to remove native resolutions above 1024x768 in the 9.3 driver? My monitor is not capable of doing that and there is about 20+ resolutions I will never use? I can't use the 6.5 driver on my card.

Right now using the 9.3 driver I have to set number of modlines to 70 for Hyperspins to work and it runs sluggish. Hyperspin 2.0 is not going to be out for atleast another 4 months so I want to come up with a workaround before then.

Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 24, 2011, 08:33:07 am
I aso forgot to tell you. I tried Missile Command and monitor could not sync. Txt dump attached
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 24, 2011, 12:05:24 pm
Another issue I found Frogger isnt resizes correctly in this version of groovymame. I attached file
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 24, 2011, 12:09:41 pm
Is there a way to remove native resolutions above 1024x768 in the 9.3 driver? My monitor is not capable of doing that and there is about 20+ resolutions I will never use? I can't use the 6.5 driver on my card.

Well there's no way as the restricted resolutions via registry is disabled in 9.3 due to the patch, and I thought it can be handy to have them there in case someone needs to plug a lcd or even use the driver in a multi-monitor system.

Right now using the 9.3 driver I have to set number of modlines to 70 for Hyperspins to work and it runs sluggish. Hyperspin 2.0 is not going to be out for atleast another 4 months so I want to come up with a workaround before then.

I see, unfortunately there's nothing I can do about that, I wish I could, I even tried to patch Hyperspin myself but saw it would require a debugger and lots of hours of my time and maybe won't achieve it. Maybe the author could drop a quick fix for it if there's real interest.

I aso forgot to tell you. I tried Missile Command and monitor could not sync. Txt dump attached

That game uses 256x240 resolution, please try that one with Arcade_OSD to make sure it works, that one has a low dotclock.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 24, 2011, 12:14:01 pm
Another issue I found Frogger isnt resizes correctly in this version of groovymame. I attached file
What does it look like, seems strange, the log indicates technically everything looks like it should but there must be something else going on.  It's choosing 400x256 and getting it setup, mame is picking it, and in theory all should be well but is it for some odd reason still the huge resolution vertically?  It works well in Linux, not sure if Calamity has double checked that for the Windows side of things.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 24, 2011, 12:16:27 pm
Yeah I think that misslecommand resolution dotclock and that radeon card probably don't mix, would need to set a higher dotclock minimum probably.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 24, 2011, 12:18:39 pm
Another issue I found Frogger isnt resizes correctly in this version of groovymame. I attached file
What does it look like, seems strange, the log indicates technically everything looks like it should but there must be something else going on.  It's choosing 400x256 and getting it setup, mame is picking it, and in theory all should be well but is it for some odd reason still the huge resolution vertically?  It works well in Linux, not sure if Calamity has double checked that for the Windows side of things.

Well this is odd:

DirectDraw: Mode selected =  400x 256@ 60Hz
DirectDraw: primary surface created: 400x256x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 472x957
DirectDraw: blit surface created: 472x957x32 (R=00FF0000 G=0000FF00 B=000000FF)

I remember frogger used to work fine, will test again with this version.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 24, 2011, 12:23:47 pm
Another issue I found Frogger isnt resizes correctly in this version of groovymame. I attached file
What does it look like, seems strange, the log indicates technically everything looks like it should but there must be something else going on.  It's choosing 400x256 and getting it setup, mame is picking it, and in theory all should be well but is it for some odd reason still the huge resolution vertically?  It works well in Linux, not sure if Calamity has double checked that for the Windows side of things.

Well this is odd:

DirectDraw: Mode selected =  400x 256@ 60Hz
DirectDraw: primary surface created: 400x256x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 472x957
DirectDraw: blit surface created: 472x957x32 (R=00FF0000 G=0000FF00 B=000000FF)

I remember frogger used to work fine, will test again with this version.

It always created that big surface I'm pretty sure, but just puts it inside the smaller window of it I guess.  Actually in Linux at least it now even does the mame settings stuff the smaller screen size too, originally it didn't do that and you had large settings screens that could barely be used at all.  Although I don't know if the Windows OSD somehow does things different there than SDL does, I was able to move all the frogger/galaxian hack stuff into the emu side so it is independent now of the OSD  chosen.  I stuffed it all in the resize size calculation functions in the emu/render.c file.  So every calculation uses it, but in Windows it might have some other place I guess.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: ves on April 24, 2011, 12:30:59 pm
Hello, bitbytebit, I've been watching what the wiimote, and I have compiled 140 with mame lightgun option works well, the only downside I've seen is that when setting the wiimote create / dev / input / eventX and if it does not recognize Xorg will have to restart X, or at least on ubuntu 10.10, not if it happened in Gentoo, these events are created when you configure the wiimote, and do not stay saved.

I've also tried to groovymame 142, I can compile but not work, I do not know C + +, you might look at you or Calamity?

I attached the files and modified.

Also attached the modified files mame normal 142, I think the problem is over here as I had to modify it to compile.

Code: [Select]
static void sdlinput_register_lightguns(running_machine &machine)
{
    int index;
    XExtensionVersion    *version;
 
//    lightgun_enabled = options_get_bool(machine->options(), OPTION_LIGHTGUN);
//    lightgun_enabled = options_get_bool(mame_options(), OPTION_LIGHTGUN);
    lightgun_enabled = machine.options().lightgun();
//      lightgun_enabled = machine.options().bool_value(SDLOPTION_KEYMAP);
//      lightgun_enabled = machine.options().bool_value();
 
    devmap_init(machine, &lightgun_map, SDLOPTION_LIGHTGUNINDEX, 8, "Lightgun mapping");
   



Thanks.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 24, 2011, 12:33:28 pm
It always created that big surface I'm pretty sure, but just puts it inside the smaller window of it I guess.  Actually in Linux at least it now even does the mame settings stuff the smaller screen size too, originally it didn't do that and you had large settings screens that could barely be used at all.  Although I don't know if the Windows OSD somehow does things different there than SDL does, I was able to move all the frogger/galaxian hack stuff into the emu side so it is independent now of the OSD  chosen.  I stuffed it all in the resize size calculation functions in the emu/render.c file.  So every calculation uses it, but in Windows it might have some other place I guess.

Yes, I've just tested frogger and is working great here, I've attached my logs...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 24, 2011, 12:39:34 pm
Hello, bitbytebit, I've been watching what the wiimote, and I have compiled 140 with mame lightgun option works well, the only downside I've seen is that when setting the wiimote create / dev / input / eventX and if it does not recognize Xorg will have to restart X, or at least on ubuntu 10.10, not if it happened in Gentoo, these events are created when you configure the wiimote, and do not stay saved.

I've also tried to groovymame 142, I can compile but not work, I do not know C + +, you might look at you or Calamity?

I attached the files and modified.

Thanks.
Interesting, so this makes it work better with mame?  Yeah since mame moves so fast in the core infrastructure and API would doubt this will still work from 140 -> 142, a lot has changed :).  I'll have to look at this, does the author of the changes plan on keeping it updated?  I'll have to see how intrusive they are, I keep my patches mostly outside in separate files from the main mame code, at least as little as possible, so updating the patches isn't as painful between mame versions.  At least reduces some of the trouble of updating, reapplying patches by hand, etc.  I'll look at this closer later and see how it works.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: ves on April 24, 2011, 12:43:10 pm
I am attaching the files for mame 142 normal, to do the patch away from the rest as you say, so it will be better if someone just wants to suck the wiimote.

Have you asked the mamedev, if would be interested to deploy your patches in mame?

Code: [Select]
static void sdlinput_register_lightguns(running_machine &machine)
{
    int index;
    XExtensionVersion    *version;
 
//    lightgun_enabled = options_get_bool(machine->options(), OPTION_LIGHTGUN);
//    lightgun_enabled = options_get_bool(mame_options(), OPTION_LIGHTGUN);
    lightgun_enabled = machine.options().lightgun();
//      lightgun_enabled = machine.options().bool_value(SDLOPTION_KEYMAP);
//      lightgun_enabled = machine.options().bool_value();
 
    devmap_init(machine, &lightgun_map, SDLOPTION_LIGHTGUNINDEX, 8, "Lightgun mapping");
  



Thanks.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 24, 2011, 02:10:53 pm
No my patches are not a patch that should go into or would be accepted into the main mame.  It's better for me since it's a work in progress, and the mame developers goals are not to focus on the output to arcade monitors.  Also by being in separate files, most other patches can fit right on top of mine easily since the line numbers should mostly match up still for patch utilities.

I am attaching the files for mame 142 normal, to do the patch away from the rest as you say, so it will be better if someone just wants to suck the wiimote.

Have you asked the mamedev, if would be interested to deploy your patches in mame?

Code: [Select]
static void sdlinput_register_lightguns(running_machine &machine)
{
    int index;
    XExtensionVersion    *version;
 
//    lightgun_enabled = options_get_bool(machine->options(), OPTION_LIGHTGUN);
//    lightgun_enabled = options_get_bool(mame_options(), OPTION_LIGHTGUN);
    lightgun_enabled = machine.options().lightgun();
//      lightgun_enabled = machine.options().bool_value(SDLOPTION_KEYMAP);
//      lightgun_enabled = machine.options().bool_value();
 
    devmap_init(machine, &lightgun_map, SDLOPTION_LIGHTGUNINDEX, 8, "Lightgun mapping");
  



Thanks.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 25, 2011, 09:51:35 am
It always created that big surface I'm pretty sure, but just puts it inside the smaller window of it I guess.  Actually in Linux at least it now even does the mame settings stuff the smaller screen size too, originally it didn't do that and you had large settings screens that could barely be used at all.  Although I don't know if the Windows OSD somehow does things different there than SDL does, I was able to move all the frogger/galaxian hack stuff into the emu side so it is independent now of the OSD  chosen.  I stuffed it all in the resize size calculation functions in the emu/render.c file.  So every calculation uses it, but in Windows it might have some other place I guess.

Yes, I've just tested frogger and is working great here, I've attached my logs...


I just tried frogger with dotclock set to 7.5 and same thing its off screen. I have attached logs again.

Also I found setting in mame.ini to disable nag screen.

Is there a way to block resolutions higher then 800x600 the same way you have minimum resolutions?
Or maybe come up with a way to remove resolutions from the registry like soft15khz does. I really dont need about 30-40 modes,  this in turn can allow me to run Hyperspin.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 25, 2011, 10:10:28 am
It always created that big surface I'm pretty sure, but just puts it inside the smaller window of it I guess.  Actually in Linux at least it now even does the mame settings stuff the smaller screen size too, originally it didn't do that and you had large settings screens that could barely be used at all.  Although I don't know if the Windows OSD somehow does things different there than SDL does, I was able to move all the frogger/galaxian hack stuff into the emu side so it is independent now of the OSD  chosen.  I stuffed it all in the resize size calculation functions in the emu/render.c file.  So every calculation uses it, but in Windows it might have some other place I guess.

Yes, I've just tested frogger and is working great here, I've attached my logs...


I just tried frogger with dotclock set to 7.5 and same thing its off screen. I have attached logs again.

Also I found setting in mame.ini to disable nag screen.

Is there a way to block resolutions higher then 800x600 the same way you have minimum resolutions?
Or maybe come up with a way to remove resolutions from the registry like soft15khz does. I really dont need about 30-40 modes,  this in turn can allow me to run Hyperspin.
Try frogger with the monitor type set to cga, instead of d9800.  I get a feeling it's possibly a horizontal frequency range issue.  Not all d9800 monitors are exactly the same tuning, basically Wells Gardner sets up the ranges in the factory and they can be off just slightly I guess.  So I am thinking that yours can't handle the 18khz area very well, mine can't handle the 20khz area, so it's at least near and mine does a similar thing in the 20khz area yours is doing around 18khz.  It's a guess at least, does pacman have issues there?  Try to find any other games that trigger the issue and see in the verbose output if what the khz is for them.  Definitely something I didn't fully expect, but the black hole area as I call it in the khz range may just be slightly different for  every d9800.  If your able, take the MonitorLimits lines for the d9800 (from the log outputs, there's 4-5 of them)  and use the groovymame -monitor_specs0 (there's 0-6 possible ones, similar to how the -resolution0 cmd line options work) options to put each of the ranges in manually.  Then you can change the ranges around, for the khz, and possibly move the 'blackhole' range. 


15250.00-18000.00,40.00-80.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,288.0,448
18001.00-19000.00,40.00-80.00,2.187,4.688,6.719,0.140,0.191,0.950,0,0,288.0,448
20501.00-29000.00,40.00-80.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,480.0,768
29001.00-32000.00,40.00-80.00,0.636,3.813,1.906,0.318,0.064,1.048,0,0,576.0,768
32001.00-34000.00,40.00-80.00,0.636,3.813,1.906,0.020,0.106,0.607,0,0,576.0,768
34001.00-38000.00,40.00-80.00,1.000,3.200,2.200,0.020,0.106,0.607,0,0,600.0,768

Basically those are them above, try changing or removign the 18001.00 one, even then after that lowering the 15250.00-18000.00 one to use 15250.00-17000.00 in the line. 

So in mame, you'd use...

 -monitor_specs0 15250.00-17000.00,40.00-80.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,288.0,448 -monitor_specs1 20501.00-29000.00,40.00-80.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,480.0,768 -monitor_specs2 29001.00-32000.00,40.00-80.00,0.636,3.813,1.906,0.318,0.064,1.048,0,0,576.0,768 -monitor_specs3 32001.00-34000.00,40.00-80.00,0.636,3.813,1.906,0.020,0.106,0.607,0,0,576.0,768 -monitor_specs4 34001.00-38000.00,40.00-80.00,1.000,3.200,2.200,0.020,0.106,0.607,0,0,600.0,768

That command line, converting it to mame.ini syntax, might be interesting.  Possibly you can squeeze down the range to only around 18khz and include 20khz there too, would be interesting to see exactly what your d9800 can do and compare it to mine.  Mine can't go above 38khz without getting weird, maybe yours can go all the way to 40khz, and the range is about 2khz off of mine (and mine can go below 15khz, to 14.9 actually, but I don't do that since it just seems wrong, but I think it can handle it, like it's shifted down and yours might not be).
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 25, 2011, 10:24:45 am
I just tried frogger with dotclock set to 7.5 and same thing its off screen. I have attached logs again.

The frogger issue is really strange as it works fine for me with the exact same resolution, so in my case the surface has the right size (see my logs) but not in yours, I have no clue of what can be happening.

Is there a way to block resolutions higher then 800x600 the same way you have minimum resolutions?
Or maybe come up with a way to remove resolutions from the registry like soft15khz does. I really dont need about 30-40 modes,  this in turn can allow me to run Hyperspin.

Yeah there is a way by using the DALRestrictedModes registry key but that one is disabled by the patch I did for the particular version 9.3 you're using, I remember there was a good reason for it, anyway I'll consider re-enabling it in a future version. As a general rule, there's nothing bad in having those modes that are the native ones of the driver, someone might need to use them, indeed I use those in my desktop computer where I have the same drivers installed. Anyway, the bug here is on Hyperspin side.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 25, 2011, 10:34:19 am
Yeah now looking at the logs closer, I see it doesn't even pick the 18khz range, but it's interesting that the picture is doing the same behavior as my d9800 when it gets in the 20khz range.  The picture is usually fatter and sometimes shifted to the side, depending on the modeline.  possibly try the generic or cga options for the monitor, both, even the h9110 type too, see if restricting the khz lower like those will might improve it.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 25, 2011, 10:36:18 am
I just tried frogger with dotclock set to 7.5 and same thing its off screen. I have attached logs again.

The frogger issue is really strange as it works fine for me with the exact same resolution, so in my case the surface has the right size (see my logs) but not in yours, I have no clue of what can be happening.

Is there a way to block resolutions higher then 800x600 the same way you have minimum resolutions?
Or maybe come up with a way to remove resolutions from the registry like soft15khz does. I really dont need about 30-40 modes,  this in turn can allow me to run Hyperspin.

Yeah there is a way by using the DALRestrictedModes registry key but that one is disabled by the patch I did for the particular version 9.3 you're using, I remember there was a good reason for it, anyway I'll consider re-enabling it in a future version. As a general rule, there's nothing bad in having those modes that are the native ones of the driver, someone might need to use them, indeed I use those in my desktop computer where I have the same drivers installed. Anyway, the bug here is on Hyperspin side.


IS there anything else I should try for the frogger bug? I wasnt an issue with cabmame.

As for the Hyperspin, I know the issue resides on the Hyperspin side but it wont be fixed soon and since I need to run HS as my frontend I was looking for an alternative method. Have the ability to remove resolutions that are not applicable makes sense anyway as it will allow users to have access to more resolutions and refreshes since there is a 120 limitation in the driver, regardless of the HS bug.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 25, 2011, 11:09:19 am
Yeah now looking at the logs closer, I see it doesn't even pick the 18khz range, but it's interesting that the picture is doing the same behavior as my d9800 when it gets in the 20khz range.  The picture is usually fatter and sometimes shifted to the side, depending on the modeline.  possibly try the generic or cga options for the monitor, both, even the h9110 type too, see if restricting the khz lower like those will might improve it.

The interesting part is here:

My logs:

DirectDraw: Mode selected =  400x 256@ 60Hz
DirectDraw: primary surface created: 400x256x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 224x256
DirectDraw: blit surface created: 224x256x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectSound: Primary buffer: 48000 Hz, 16 bits, 2 channels

bent98's logs:

DirectDraw: Mode selected =  400x 256@ 60Hz
DirectDraw: primary surface created: 400x256x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 472x957
DirectDraw: blit surface created: 472x957x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectSound: Primary buffer: 48000 Hz, 16 bits, 2 channels


Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 25, 2011, 11:32:51 am
As for the Hyperspin, I know the issue resides on the Hyperspin side but it wont be fixed soon and since I need to run HS as my frontend I was looking for an alternative method. Have the ability to remove resolutions that are not applicable makes sense anyway as it will allow users to have access to more resolutions and refreshes since there is a 120 limitation in the driver, regardless of the HS bug.

Actually it does not work like that exactly, what I do is to use the DALRestrictedModes space to store my extra custom modelines, that's what it's convenient to get rid of that.

Well, if you really want to try it, I'll upload a modified version for you, be aware you'll need to reinstall the driver, I may have it today.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 25, 2011, 01:35:39 pm
As for the Hyperspin, I know the issue resides on the Hyperspin side but it wont be fixed soon and since I need to run HS as my frontend I was looking for an alternative method. Have the ability to remove resolutions that are not applicable makes sense anyway as it will allow users to have access to more resolutions and refreshes since there is a 120 limitation in the driver, regardless of the HS bug.

Actually it does not work like that exactly, what I do is to use the DALRestrictedModes space to store my extra custom modelines, that's what it's convenient to get rid of that.

Well, if you really want to try it, I'll upload a modified version for you, be aware you'll need to reinstall the driver, I may have it today.

Yeah I remember now why it was necessary to remove the restricted modes functionality. I've tried to leave the restricted modes option enabled and each time I select a custom modeline I get a blue screen. To explain it simple: regular Catalyst let you define 60 Custom Modes + 60 Restricted Modes. What I do is to patch the driver so I have 120 Custom Modes + 0 Restricted Modes, modifying the relative pointers. It's a damned hack, but it works, as long as we don't need any Restricted Modes. But unfortunately 120 custom modes added to the native mode list turns out in an unusual amount of available modes in the system, that should not be a problem unless a given program does not reserve enough space to retrieve the system mode list and is overflowed by that (btw a bug that's really easy to fix in 15' if you have the source code).

So I'm afraid the only workaround for HS by now is to define less video modes and bear with the non-so-accurate results :(

I wish I could be of more help with this, I know HS is a great frontend and many people on this board are using it, and probably these people will refuse to use my drivers because of this.

Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 25, 2011, 05:05:30 pm
Yeah now looking at the logs closer, I see it doesn't even pick the 18khz range, but it's interesting that the picture is doing the same behavior as my d9800 when it gets in the 20khz range.  The picture is usually fatter and sometimes shifted to the side, depending on the modeline.  possibly try the generic or cga options for the monitor, both, even the h9110 type too, see if restricting the khz lower like those will might improve it.

Do you want to me generate new modelines for each monitor type or just change the monitor type in the mami.ini or do both?
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on April 25, 2011, 05:13:27 pm
Yeah now looking at the logs closer, I see it doesn't even pick the 18khz range, but it's interesting that the picture is doing the same behavior as my d9800 when it gets in the 20khz range.  The picture is usually fatter and sometimes shifted to the side, depending on the modeline.  possibly try the generic or cga options for the monitor, both, even the h9110 type too, see if restricting the khz lower like those will might improve it.

Do you want to me generate new modelines for each monitor type or just change the monitor type in the mami.ini or do both?

Just try the cga monitor type I guess, it doesn't seem to be anything to do with the other stuff I was thinking though.  It's confusing since Calamity saw that one difference in the log output so not sure what is going on.  It doesn't make sense that it's doing the odd resolution size at the end like that, but throughout the rest of the log it is right.  It seems to be something specific to the Windows OSD, at least I'm guessing that, Calamity might be able to see more of what exactly it's doing to have that odd resolution calculation for the blitting part.  Is the mame.ini freshly generated, just thinking that maybe there's some option setting that could cause it to change the blitting size, but still seems very unlikely that would be the cause either.   
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 25, 2011, 05:16:36 pm
Do you want to me generate new modelines for each monitor type or just change the monitor type in the mami.ini or do both?

He means in mame.ini, you actually don't need to generate new modelines. It would be interesting to try h9110 monitor type in mame.ini, as that's my setup, where frogger works fine.

I'd like to be able to reproduce your frogger issue here. What's your desktop resolution?

Edit: The issue might be related with function compute_blit_surface_size(win_window_info *window) in drawdd.c.
After all I wanted to have a look at this at some point, as I couldn't fix the issue with ghouls when run with doubled resolution and I think there's a problematic aspect ratio checking hidden somewhere in the windows side.

Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 25, 2011, 05:29:52 pm
800x600
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 25, 2011, 05:31:58 pm
800x600

Good. Please change it to 640x480 and test frogger again... just an experiment.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 25, 2011, 05:35:12 pm
DirectDraw: Mode selected =  640x 480@ 60Hz
DirectDraw: primary surface created: 640x480x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 472x957
DirectDraw: blit surface created: 472x957x32 (R=00FF0000 G=0000FF00 B=000000FF)

when setting mame.ini to cga
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 25, 2011, 05:43:11 pm
800x600

Good. Please change it to 640x480 and test frogger again... just an experiment.



DirectDraw: Mode selected =  480x 480@ 60Hz
DirectDraw: primary surface created: 480x480x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 472x957
DirectDraw: blit surface created: 472x957x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectSound: Primary buffer: 48000 Hz, 16 bits, 2 channels
RawInput: APIs detected
Input: Adding Mouse #1: Microsoft USB IntelliMouse Optical
Input: Adding Gun #1: Microsoft USB IntelliMouse Optical


this is 640x480 d9800 setting
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 25, 2011, 06:02:00 pm
this is 640x480 d9800 setting

Thanks a lot for testing. I wonder where those 472x957 come from. You won't happen to have a second monitor plugged? It's so strange.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 25, 2011, 07:38:02 pm
no
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on April 27, 2011, 04:38:23 am
new chassis on the way!

http://www.giz10p.co.uk/index.php?_a=viewProd&productId=326 (http://www.giz10p.co.uk/index.php?_a=viewProd&productId=326)

can't wait to start tinkering again!

hopefully this will resolve my polarity problems as well... :)
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 27, 2011, 05:22:24 am
new chassis on the way!

http://www.giz10p.co.uk/index.php?_a=viewProd&productId=326 (http://www.giz10p.co.uk/index.php?_a=viewProd&productId=326)

can't wait to start tinkering again!

hopefully this will resolve my polarity problems as well... :)

Great news!
Hopefully we have better luck with this one!
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bent98 on April 28, 2011, 12:11:04 pm
Calamity,

Is there a resolution I can just config in the ini folder to override what groovymame is selecting? I can just do it for frogger as an exception
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 28, 2011, 12:32:21 pm
Calamity,

Is there a resolution I can just config in the ini folder to override what groovymame is selecting? I can just do it for frogger as an exception

You could try forcing it with the param -resolution0 400x256@60
Also try -resolution0 384x256@60 to see if it makes any difference

Also would be interesting to try this while adding the param -nomodeline, to disable the modeline generator.

However, there's something really odd going on with frogger in your system. It's working right for me here testing in two systems at least with completely different setups... I don't know where the difference comes from, that's why I was suggesting those tests with different desktop resolutions.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Calamity on April 29, 2011, 01:34:04 pm
EDIT: I move this post here as I think it's clearer...

Well now actually -nomultithreading disables triplebuffering in the current patch when the refresh doesn't match.

-triplebuffer now needs to be manually enabled from mame.ini (which is good in my opinion as it's the less preferred option due to its input lag).

To use triplebuffer + throttle we'd need triplebuffer to be asynchronous, but that's only possible in a multithreading environment (that's why it's disabled by the patch if -nomultithreading). However, even with multithreading on we don't get a truly asynchronous triplebuffering if throttle is also on, unless we add this other patch I suggested here:

http://forum.arcadecontrols.com/index.php?topic=106405.msg1179456#msg1179456 (http://forum.arcadecontrols.com/index.php?topic=106405.msg1179456#msg1179456)

So with this last patch, you can use nosyncrefresh + multithreading + triplebuffer to be able to run 100% with no tearing even if the refresh doesn't match (at the cost of some frameskipping).

UPDATE: Anyway, the patch's internal logic still has its flaws, we still need to figure out a way to avoid the automatic activation of vsync if the user doesn't want to, even if the refresh matches (i.e., for 3D games, where the CPU reaches its limits), and activate triplebuffer instead, that leaves more time available to cpu that -syncrefresh.

The problem here is that we can make a fully automatic system to cover all situations according to our personal taste but then it gets difficult to customize unless we add specific options (bad).
Also, what we are trying to do here is to make -syncrefresh and -triplebuffer independent things, with a very specific behaviour for each of them, that makes more sense that the default implementations in Mame.

UPDATE2: I think this logic is way simplier and can cover all situations, not fully sure though:

Code: [Select]
IF ( RESULT_VFREQ_CHANGE && !syncrefresh ) || triplebuffer
    throttle 1
    waitvsync 0

ELSE
    throttle 0
    waitvsync 1

So with this one, triplebuffer has preference over syncrefresh, so if you enable triplebuffer then it automatically disables vsync. So triplebuffer should be disabled all the time, unless you want to enable it for a particular game (pacman, tekken, etc.), and then it would turn vsync off regardless multithreading state. This means that if multithreading is on, the game will run 100% (provided the patch I mentioned is eventually added), but if it's off, the game will run at the refresh speed.

Title: Re: Switchres modeline generator and emulator wrapper
Post by: ves on May 08, 2011, 01:44:10 pm
Hello, groovymame is that new?

I've already tried the latest version has not been very thoroughly, but I've seen that has solved the problems they had in mame when shown the options screen within the game, now seen in all games without problems, but I think you have not touched anything on linux, right? may be by amending the part of windows? or just be some bugs Version 14xU?
I need to prove if you have the same problems with the wiimote, tonight will try to prove it.

I upgraded Openppjoy to the kernel 2.6.38, and have asked permission to the operator so that it can include, so if you want to live next you can get.
I remember it as a kernel module that applies to code the keyboard or joystick to the parallel port with a very very basic circuit and costs 3 € or less  ;D

I created two openppjoy, the first one have update for the kernel.
http://www.megaupload.com/?d=G1WIBKNI (http://www.megaupload.com/?d=G1WIBKNI)

And the second is to have the default mame key.
http://www.megaupload.com/?d=0VABV6AK (http://www.megaupload.com/?d=0VABV6AK)




Have you seen the patch for the wiimote?



Thanks.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on May 09, 2011, 09:20:09 am
Hello, groovymame is that new?

I've already tried the latest version has not been very thoroughly, but I've seen that has solved the problems they had in mame when shown the options screen within the game, now seen in all games without problems, but I think you have not touched anything on linux, right? may be by amending the part of windows? or just be some bugs Version 14xU?
I need to prove if you have the same problems with the wiimote, tonight will try to prove it.

I upgraded Openppjoy to the kernel 2.6.38, and have asked permission to the operator so that it can include, so if you want to live next you can get.
I remember it as a kernel module that applies to code the keyboard or joystick to the parallel port with a very very basic circuit and costs 3 € or less  ;D

I created two openppjoy, the first one have update for the kernel.
http://www.megaupload.com/?d=G1WIBKNI (http://www.megaupload.com/?d=G1WIBKNI)

And the second is to have the default mame key.
http://www.megaupload.com/?d=0VABV6AK (http://www.megaupload.com/?d=0VABV6AK)




Have you seen the patch for the wiimote?



Thanks.

Ah yeah, the Linux ISO hasn't changed much lately since mostly just works and haven't had any big needs there while the Windows groovymame has needed more detailed work, although I think it's really becoming more stable too now.  I'll look at those other patches and parts for the remotes and joystick stuff soon when I can find more time.  Am in the process of moving to a new house, or getting ready to do that, so a lot of my free time has been taken up with focusing on that lately.  Might be a month before I am settled hopefully and can have a lot more time like before to do extra stuff besides the bug fixing quick things.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: ves on May 11, 2011, 09:30:54 am
Hi, I upload the new arcade mame key module and I had an error when assigning the second player keys.
I tried it and it works great, if you include the arcade module, I think it would be better to include this that has the default mame key and use it as a keyboard and not as a joystick.

http://www.megaupload.com/?d=7NYEFWSC (http://www.megaupload.com/?d=7NYEFWSC)



Greetings.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on May 14, 2011, 04:05:01 am
new chassis on the way!

http://www.giz10p.co.uk/index.php?_a=viewProd&productId=326 (http://www.giz10p.co.uk/index.php?_a=viewProd&productId=326)

can't wait to start tinkering again!

hopefully this will resolve my polarity problems as well... :)

Update:

The chassis arrived, but was faulty.  It worked ok, but the screen was shaking very slightly, as if there was interference.  I sent it back and it was diagnosed as faulty.

On a more positive note, I am now the proud owner of a Wells Gardner D9200 and I have to say the picture quality compared to the Wei-Ya or the Rodotron is like night and day.  I wasn't cheap, but definitely worth it!  At least now GroovyMame will be running at it's finest!
Title: Re: Switchres modeline generator and emulator wrapper
Post by: ves on May 14, 2011, 11:10:18 am
Hello bitbytebit,the logs will go above 1.58 was the version that I thought was the last or so places in the git, but in no other more modern web of 1.60, these are the errors I found in version 1.60

Quote
manual partitioning, OK INSTALLATION

sda1 root
roms sda2
sda3 swap


manual partition does not create create. bash_profile, not start Xorg or gasetup by default, do not mount the roms particones or home, nor include them in fstab.

sda1 root
sda2 home
roms sda3
sda4 swap



automatic partitioning, if you have previous partitions, partition error because they are mounted, iif I delete the partitions fail again, until you restart gasetup or pc, grub error.

Automatic partitions with disk clean, OK INSTALLATION

Do not change the option setxkbmap us, a different language from the xinitrc file.

I need to check the controls of the wii if they have improved their performance in this version and see if the options screen when you are playing you can see well.



Thanks.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on May 14, 2011, 12:34:10 pm
Hello bitbytebit,the logs will go above 1.58 was the version that I thought was the last or so places in the git, but in no other more modern web of 1.60, these are the errors I found in version 1.60

Quote
manual partitioning, OK INSTALLATION

sda1 root
roms sda2
sda3 swap


manual partition does not create create. bash_profile, not start Xorg or gasetup by default, do not mount the roms particones or home, nor include them in fstab.

sda1 root
sda2 home
roms sda3
sda4 swap



automatic partitioning, if you have previous partitions, partition error because they are mounted, iif I delete the partitions fail again, until you restart gasetup or pc, grub error.

Automatic partitions with disk clean, OK INSTALLATION

Do not change the option setxkbmap us, a different language from the xinitrc file.

I need to check the controls of the wii if they have improved their performance in this version and see if the options screen when you are playing you can see well.



Thanks.

Yeah the home directory setup needs some fixing to work right with installation, I haven't had time to dive in and redo how that works to fix the issues.  Definitely need to go in and make it so partitions can be used mixed with automatic partitioning, but it'll need a redesign somewhat of how it all works to  fix manual partitioning and merge with automatic partitioning ability.  So waiting till when I have more time, probably not for a month or so before I can get around to it.  Been busy getting ready to move to a new house, and work has been busy too, so I'm waiting till in the new house to have more free time for this big of overhaul of the partitioning system.  It's really complicated when you have manual setup mixed with a home directory for the install, or automatic partitioning chosen then after doing that, lots of different things to consider and deal with in the setup script for all the possibilities.  It's a lot easier just knowing automatic partitioning is used, the other use cases are going to be quite complicated since partly to partition I have to run fdisk in quite a tricky way by script with the letters input so it has to be exact to what needs to be done.  The more use cases you get, the less likely that'll be as easy to do.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on May 16, 2011, 03:04:18 am
bitbytebit, could you explain how i change permissions in my roms/snap hard disk?

I want to keep my hi-scores, nvram and cfg folders on that hard disk so it will be safer in case of any future updates.  At the minute, i have set the correct path in mame.ini, but if i try to change dip-switches in a game, its not saving the changes because if i go into file manager and try to delete the nvram file, it says the disk is read-only (30)...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on May 16, 2011, 07:06:18 am
bitbytebit, could you explain how i change permissions in my roms/snap hard disk?

I want to keep my hi-scores, nvram and cfg folders on that hard disk so it will be safer in case of any future updates.  At the minute, i have set the correct path in mame.ini, but if i try to change dip-switches in a game, its not saving the changes because if i go into file manager and try to delete the nvram file, it says the disk is read-only (30)...
The configuration settings which you have to write to, have to be on a read/write mounted drive.  So it can't be NTFS based or Windows partitions for XP/Win7/Vista/NT/200X etc.   Only Linux or DOS/Win32 based partitions unfortunately.  It's a Linux limitation that NTFS can't be written to, it's read only, because Microsoft doesn't give out the information on how it works to be able to write to it safely without corruption.  There are technically ways out there to write to it outside of Windows but they are dangerous and can lose your entire NTFS drive with simply writing to the wrong part of the drive I guess.  So they don't even try in Linux because of that.

I'd recommend having a separate usb flash drive for the writable stuff, or a separate drive in the computer possibly. 
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on May 17, 2011, 01:29:10 pm
cheers for the reply.  i figured it would be the case after i posted that...

on a separate note, i have now decided to use Wah!Cade as my front-end, but it will not launch roms.  i get a grey square briefly, and then nothing...

i have assigned the rom path in the wah!cade setup, but i have a feeling i have to set it somewhere else too, as was the case with advancemenu...

i followed this guide: http://www.anti-particle.com/wahcade_quick.shtml (http://www.anti-particle.com/wahcade_quick.shtml)

but obviously some things are different, such as the following paragraph:

(obviously change "pacman" for a rom you know you have). If you get errors then you probably need to edit your ~/.xmame/xmamerc or ~/.xmame/xmame-x11rc files

can you help me out?
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on May 17, 2011, 01:33:06 pm
cheers for the reply.  i figured it would be the case after i posted that...

on a separate note, i have now decided to use Wah!Cade as my front-end, but it will not launch roms.  i get a grey square briefly, and then nothing...

i have assigned the rom path in the wah!cade setup, but i have a feeling i have to set it somewhere else too, as was the case with advancemenu...

i followed this guide: http://www.anti-particle.com/wahcade_quick.shtml (http://www.anti-particle.com/wahcade_quick.shtml)

but obviously some things are different, such as the following paragraph:

(obviously change "pacman" for a rom you know you have). If you get errors then you probably need to edit your ~/.xmame/xmamerc or ~/.xmame/xmame-x11rc files

can you help me out?

With wahcade you may want to fully erase the /home/arcade/.wahcade directory and then run the wahcade-setup program.  Wahcade seems really bad about changing the settings after you've setup your roms the first time, so it might need to be done from scratch. 
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on May 17, 2011, 03:01:13 pm
just tried a fresh install...

the emulator.log file inside the .wahcade folder shows:

command from wah!cade is:
   /usr/local/bin/switchres 10yard
************

sh: mame: command not found
error getting xml info for mame from 10yard
unknown rom for mame and mess 10yard
...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on May 17, 2011, 03:44:37 pm
just tried a fresh install...

the emulator.log file inside the .wahcade folder shows:

command from wah!cade is:
   /usr/local/bin/switchres 10yard
************

sh: mame: command not found
error getting xml info for mame from 10yard
unknown rom for mame and mess 10yard
...

Oh odd, the switchres command shouldn't be used, you want it to point to /usr/games/bin/groovymame actually instead.  I'm not sure why it's setting that path up, it shouldn't reference switchres at all.  In the newest ISO it shouldn't reference it anymore besides for the other emulators other than mame.  The default setup should have the groovymame reference correct. 
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on May 17, 2011, 03:58:10 pm
perfect!

btw, i was using the 1.560 version, so you may want to have a look at it when you find the time...

good luck with the house-move!
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on May 17, 2011, 04:08:41 pm
perfect!

btw, i was using the 1.560 version, so you may want to have a look at it when you find the time...

good luck with the house-move!
Thanks!  Yeah that's weird that it pulled up the switchres setting that way, can't find a single way it would but I guess I'm going to have to look closer since it must be somewhere still in the wahcade setup stuff.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on May 18, 2011, 03:13:56 pm
just a quick one...

i now have a d9200 monitor.  out of curiousity, i tried running with the d9800 preset, and alot of the vertical shooters looked a lot crisper.

an example of this is esp.ra.de.  with the d9200 preset, it has a bit of flicker as if the refresh rate is wrong (enough to probably give you a headache if you were to have some prolonged play at it), and it doesn't look quite right.  according to the osd, it is displaying at 15.9khz and 57hz.

when i try the same game with the d9800 preset, it looks amazingly crisp and just how i think it should be.  absolutely no flicker.  according to the osd, it is displaying at 20.4khz and 57hz.

could you have a look when you get the chance and see what frequency and refresh it is displaying for you?  can you see any 'flicker' with that game.  perhaps, you could also try the d9200 preset and compare the two...

according to the d9200 manual, the tolerance levels are +/- 1.8khz, so 20.4khz would place it outside those tolerance levels, so i'm not sure if it is damaging my monitor (although it is very tempting to play it because of how good it looks!)

cheers...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on May 18, 2011, 03:17:54 pm
just a quick one...

i now have a d9200 monitor.  out of curiousity, i tried running with the d9800 preset, and alot of the vertical shooters looked a lot crisper.

an example of this is esp.ra.de.  with the d9200 preset, it has a bit of flicker as if the refresh rate is wrong (enough to probably give you a headache if you were to have some prolonged play at it), and it doesn't look quite right.  according to the osd, it is displaying at 15.9khz and 57hz.

when i try the same game with the d9800 preset, it looks amazingly crisp and just how i think it should be.  absolutely no flicker.  according to the osd, it is displaying at 20.4khz and 57hz.

could you have a look when you get the chance and see what frequency and refresh it is displaying for you?  can you see any 'flicker' with that game.  perhaps, you could also try the d9200 preset and compare the two...

according to the d9200 manual, the tolerance levels are +/- 1.8khz, so 20.4khz would place it outside those tolerance levels, so i'm not sure if it is damaging my monitor (although it is very tempting to play it because of how good it looks!)

cheers...

Interesting, well it sounds like the d9200 can physically handle the whole range of khz like the d9800 can.  Definitely not good though to do that if it is a problem technically, which you could ask the Wells gardner support guy through email.  I asked him about the d9800 and he said it could do this, but didn't ask him about the d9200.  Let us know what he says, I'm curious, would be cool if we really could just have one single preset for both monitors.  I do know the d9200 can have some issues internally, so hopefully it doesn't push it over the edge using the d9800 setting.  So I'd definitely check with him to make sure, he's always been very quick to respond to my emails.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on May 19, 2011, 02:24:07 am
i fired off an email today, so i'll let you know when i get a reply...

in the meantime, if you get a chance, could you run esp.da.re through both presets for the d9200 and d9800 and let me know what frequency/refresh it is syncing at?

i'm interested if you get the 'flicker' with the d9200 preset, because something just ain't right...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on May 19, 2011, 10:23:09 am
hi bitbytebit...

just to clarify, i am getting those frequencies/refreshes when trying to play esp.ra.de on a horizontal monitor.

i tried setting the monitor as vertical, and running the game using both d9200 and d9800 presets and it is syncing at 15.0khz (d9200) and 15.1khz (d9800), and the screen is drop-dead gorgeous on both.

just out of interest, do you rotate your monitor for vertical games, or do you play all games horizontally?

it seems like the problem i'm having is due to running esp.ra.de (and some other vertical shooters) on the screen horizontal, because i tried running a few horizontal games, when the monitor set to vertical and the same 'flicker' is happening.

i feel like i have no choice but to get another cab and permanently mount it vertically!

also, i heard back from John at Wells Gardner.  i had to give him the exact model number of my d9200 (WGM2792-U5FS04E), because it seems there are a few different types and all are different, spec-wise...

 he said:

Mark as you can see this model will operate at 800X600 and as for the 20.4khz you should have no problem with that frequency.

he forwarded a document relating to my monitor with various porch/pulse values.  could this be of interest to you, bitbytebit?  seems like it can sync through the whole range...
Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on May 19, 2011, 10:38:42 am
hi bitbytebit...

just to clarify, i am getting those frequencies/refreshes when trying to play esp.ra.de on a horizontal monitor.

i tried setting the monitor as vertical, and running the game using both d9200 and d9800 presets and it is syncing at 15.0khz (d9200) and 15.1khz (d9800), and the screen is drop-dead gorgeous on both.

just out of interest, do you rotate your monitor for vertical games, or do you play all games horizontally?

it seems like the problem i'm having is due to running esp.ra.de (and some other vertical shooters) on the screen horizontal, because i tried running a few horizontal games, when the monitor set to vertical and the same 'flicker' is happening.

i feel like i have no choice but to get another cab and permanently mount it vertically!

also, i heard back from John at Wells Gardner.  i had to give him the exact model number of my d9200 (WGM2792-U5FS04E), because it seems there are a few different types and all are different, spec-wise...

 he said:

Mark as you can see this model will operate at 800X600 and as for the 20.4khz you should have no problem with that frequency.

he forwarded a document relating to my monitor with various porch/pulse values.  could this be of interest to you, bitbytebit?  seems like it can sync through the whole range...
I just run horizontal on my d9800, it's too big to rotate :).  Yeah I guess he's saying then that it's the same as the d9800 and really should just use that as your monitor type.  Definitely interesting, had wondered that, I had thought the d9800 was different but looks like everyone has misjudged the d9200 all along and it was able to be as flexible with khz ranges.  I have seen those documents, they sent me ones for the d9800 and there's the d9200 ones on their website.  Yeah I wish I had a separate vertical cabinet too, although the room for it and the wife would kill me probably for getting one.  Hopefully I can get a tabletop setup with this 19" CGA I have sooner or later and use that vertically/horizontally just by moving to the side instead of physically rotating it.
Title: Re: Switchres modeline generator and emulator wrapper
Post by: MonkeyJug on May 19, 2011, 10:40:47 am
update:

the document initially only showed the porch/pulse settings for VGA, so i asked him for the porch/pulse settings for all the resolutions and he replied again saying "Mark, here are the resolution for the D9800 which are the same as your D9200 version."

it seems like my d9200, which is one of the later manufactured (May 2005), is pretty much a d9800 disguised as a d9200!  i'm delighted!

here's the document he sent, you probably already have it...

http://dl.dropbox.com/u/7485094/D9800%20res.%20modes.PDF (http://dl.dropbox.com/u/7485094/D9800%20res.%20modes.PDF)
Title: Re: Switchres modeline generator and emulator wrapper
Post by: ves on May 19, 2011, 11:54:15 am
Hi, I've managed to finish the patch mameWiimote the 142 version, I have to test it on real machine to verify that everything works fine, then I pass the files so that you perform on the new version.

I have only one doubt, is that this patch is based on the events that created the bluethoo when you sync the wiimote, and not remain fixed, there is some way to events that are created are permanent and referring to the wiimote?
Title: Re: Switchres modeline generator and emulator wrapper
Post by: ves on May 21, 2011, 09:02:53 am
Bitbytebit Hi, here's the diff, files and modified to use the Wiimote as a gun, I have tested on ubuntu and everything works perfectly, now I'm compiling for use in the real machine.
I just need to see if I can modify the mame source code to change the order of the mouse buttons on the gun because it must be configured for each game shooting gun.

How to make work.

Edit Xorg.conf

Quote
Section "ServerLayout"
   InputDevice    "WiiMote0"
   InputDevice    "WiiMote1"
EndSection

Section "InputDevice"
   Identifier "WiiMote0"
   Driver "evdev"
   Option "Device" "/dev/input/event4"
   Option "SendCoreEvents" "True"
EndSection

Section "InputDevice"
   Identifier "WiiMote0"
   Driver "evdev"
   Option "Device" "/dev/input/event5"
   Option "SendCoreEvents" "True"
EndSection

Remember that eventX have to put that match your wiimote.
Before putting the bluetooth watch /dev/input/, then put bluetooth and sync the wiimote,and see the new events, these are the ones who have to put.

Edit mame.ini

Quote
joystick                    0
lightgun                   1


lightgun_device           lightgun
mouse_device              lightgun


lightgun_index1           WiiMote0
lightgun_index2           WiiMote1
lightgun_index3           auto
lightgun_index4           auto
lightgun_index5           auto
lightgun_index6           auto
lightgun_index7           auto
lightgun_index8           auto
Title: Re: Switchres modeline generator and emulator wrapper
Post by: ves on June 04, 2011, 08:37:23 am
Hello bitbytebit, I saw that there are several more errors in the configuration of the network card, to configure the card does not change this configuration, as does the ifconfig ethX donw or service.

Not if gasetup failure or not, but when you configure the boot lxde says not installed, it has removed or is it a bug?

You should include in packages are groovymame joystick xf86-input-joystick and input-utils.
(Now do not remember but I think it is necessary to use the Wiimote as a gun, because I was doing several Proofs for it to work and one of these was to install the packages)

I've tried the wiimote and I must say it works really well, there are no blocking issues, earthquakes etc ...
To succeed, I had to change the configuration files in the ir_ptrX cwiid the option mamebuttons by the original buttons, there is any conflict with that configuration.

About what we talked a while. takes less time to load gentoo, I've been looking to use the upstart debian etc, but this package is not in gentoo, since it represents a big change (bad luck), I looked in arch linux and not have it, but your boot is faster, and I think it's because things like load more modules in the kernel itself, (correct me if I'm wrong) you could compile the kernel so that charged at less stuff by default by setting only the basics and everything else that put as modules?

I forgot to comment that arch linux mkinitcpio used to optimize the creation and loading of initrd, leaving only what you need our PC, and thus takes less time to load.

I've been looking at guides to optimize gentoo changing values ​​etc. .. but I have given little or no results, but still leave you the link if you think you can claim for anything.

With respect to the boot image, I think the best option would be to use plymouth, we could have animations etc and it seems easy to use.

You thought your in groovyarcade migrate to arch linux, because it is much more friendly when installing or upgrading to gentoo?


Well I hope not to get tired a lot, are just notes that I wanted to discuss with you.


Thank.

Title: Re: Switchres modeline generator and emulator wrapper
Post by: bitbytebit on June 05, 2011, 04:36:19 pm
Hello bitbytebit, I saw that there are several more errors in the configuration of the network card, to configure the card does not change this configuration, as does the ifconfig ethX donw or service.

Not if gasetup failure or not, but when you configure the boot lxde says not installed, it has removed or is it a bug?

You should include in packages are groovymame joystick xf86-input-joystick and input-utils.
(Now do not remember but I think it is necessary to use the Wiimote as a gun, because I was doing several Proofs for it to work and one of these was to install the packages)

I've tried the wiimote and I must say it works really well, there are no blocking issues, earthquakes etc ...
To succeed, I had to change the configuration files in the ir_ptrX cwiid the option mamebuttons by the original buttons, there is any conflict with that configuration.

About what we talked a while. takes less time to load gentoo, I've been looking to use the upstart debian etc, but this package is not in gentoo, since it represents a big change (bad luck), I looked in arch linux and not have it, but your boot is faster, and I think it's because things like load more modules in the kernel itself, (correct me if I'm wrong) you could compile the kernel so that charged at less stuff by default by setting only the basics and everything else that put as modules?

I forgot to comment that arch linux mkinitcpio used to optimize the creation and loading of initrd, leaving only what you need our PC, and thus takes less time to load.

I've been looking at guides to optimize gentoo changing values ​​etc. .. but I have given little or no results, but still leave you the link if you think you can claim for anything.

With respect to the boot image, I think the best option would be to use plymouth, we could have animations etc and it seems easy to use.

You thought your in groovyarcade migrate to arch linux, because it is much more friendly when installing or upgrading to gentoo?


Well I hope not to get tired a lot, are just notes that I wanted to discuss with you.


Thank.



The newest builds don't contain lxde, were smaller to allow quicker uploads.  Also avoiding adding extra packages for the X windows joystick and other input devices, but will look at that in the future.  Booting slower is the compromise so that everyones systems will work, otherwise without loading all the modules some systems wouldn't work.  To get a fast bootup, would require only the specific kernel modules for your system to be loaded, it's a custom setup, would have to know about trimming down the Linux kernel.  Right now it works, for most everyone, but slower than a streamlined trimmed system.  Would be nice to eventually address that, but it's a lot of work most likely.  Arch Linux is interesting, but I suspect it's not best to move to it because I know Gentoo so well and in general the system should be a drop in working system, so moving to a new system wouldn't really help the end user and just require more work for me :).  Yeah thanks for input, I've been so busy I can't really focus on working on stuff right now.  Actually I'm happy with the state of things for the most part, all the additional things for now are just extra stuff it seems, and currently so busy with my moving into and working on getting my new house setup there's no time for extra work (besides my normal job :)).
Title: Re: Switchres modeline generator and emulator wrapper
Post by: Gray_Area on June 08, 2011, 11:25:41 pm
reposted elsewhere
Title: Re: Switchres: modeline generator engine
Post by: emphatic on September 01, 2011, 03:40:14 pm
Can someone please tell me what arguments I need to run groovymame with to generate modelines for missing video modes? Also it would be very nice if these could be listed in the first post, as this is now a 30+ pages thread. I'm running GroovyMAME in Windows with Soft15kHz. I went to the groovy website, but there's not much info there about the Windows usage.

By "arguments" I mean command line if there's any confusion. :)
Title: Re: Switchres: modeline generator engine
Post by: Calamity on September 02, 2011, 05:11:30 am
Can someone please tell me what arguments I need to run groovymame with to generate modelines for missing video modes? Also it would be very nice if these could be listed in the first post, as this is now a 30+ pages thread. I'm running GroovyMAME in Windows with Soft15kHz. I went to the groovy website, but there's not much info there about the Windows usage.

By "arguments" I mean command line if there's any confusion. :)

You can use a line like this:

       groovymame toki -monitor cga -v -md 4 >toki.txt

Then open toki.txt and line 18 should contain this:

SwitchRes: ModeLine          "256x224x59.61" 5.127413 256 272 296 336 224 231 234 256 -HSync -VSync

...which is the modeline GroovyMAME has calculated for the monitor type we entered (cga). GroovyMAME won't be able to add that modeline if you're using a nVidia card but you can copy it and use Soft15KHz to add it to the system.

Title: Re: Switchres: modeline generator engine
Post by: emphatic on September 02, 2011, 01:16:14 pm
Can someone please tell me what arguments I need to run groovymame with to generate modelines for missing video modes? Also it would be very nice if these could be listed in the first post, as this is now a 30+ pages thread. I'm running GroovyMAME in Windows with Soft15kHz. I went to the groovy website, but there's not much info there about the Windows usage.

By "arguments" I mean command line if there's any confusion. :)

You can use a line like this:

       groovymame toki -monitor cga -v -md 4 >toki.txt

Then open toki.txt and line 18 should contain this:

SwitchRes: ModeLine          "256x224x59.61" 5.127413 256 272 296 336 224 231 234 256 -HSync -VSync

...which is the modeline GroovyMAME has calculated for the monitor type we entered (cga). GroovyMAME won't be able to add that modeline if you're using a nVidia card but you can copy it and use Soft15KHz to add it to the system.



Awesome, thanks!
Title: Re: Switchres: modeline generator engine
Post by: Monkee on January 05, 2013, 09:06:18 am
A stupid question: concerning the choice of the GPU, you said that an old ATI Radeon card, any model from Radeon 7000 to the HD 4xxx family works but does mods of those cards (by MSI and other manufacturers) works also ?

I'm thinking about buying this one: http://www.ldlc.com/fiche/PB00127113.html (http://www.ldlc.com/fiche/PB00127113.html) but I don't want to realize afterwards that it's not working !  :-\
Title: Re: Switchres: modeline generator engine
Post by: jvlk on January 08, 2013, 04:06:56 pm
A stupid question: concerning the choice of the GPU, you said that an old ATI Radeon card, any model from Radeon 7000 to the HD 4xxx family works but does mods of those cards (by MSI and other manufacturers) works also ?

I'm thinking about buying this one: http://www.ldlc.com/fiche/PB00127113.html (http://www.ldlc.com/fiche/PB00127113.html) but I don't want to realize afterwards that it's not working !  :-\

Yes it will work.
Title: Re: Switchres: modeline generator engine
Post by: Monkee on January 08, 2013, 04:14:53 pm
Thanks jvlk !  ;)
Title: Re: Switchres: modeline generator engine
Post by: NightSprinter on February 11, 2013, 08:20:49 pm
Not sure if this belongs here, but is there any reason why building the latest versions of Switchres in linux always causes a Segmentation Fault?  I want to be able to use the newer features to see if there's any improvement on my Linux install, but the segfault issue puts a stint in that.
Title: Re: Switchres: modeline generator engine
Post by: Calamity on February 12, 2013, 06:09:25 pm
Not sure if this belongs here, but is there any reason why building the latest versions of Switchres in linux always causes a Segmentation Fault?  I want to be able to use the newer features to see if there's any improvement on my Linux install, but the segfault issue puts a stint in that.

Do you mean this version?: http://forum.arcadecontrols.com/index.php/topic,128879.msg1327817.html#msg1327817 (http://forum.arcadecontrols.com/index.php/topic,128879.msg1327817.html#msg1327817)
Did you apply Ansa89's patch? Is it the same segmentation fault?
Title: Re: Switchres: modeline generator engine
Post by: NightSprinter on February 13, 2013, 12:43:37 am
Yeah, got it applied (and even downloaded and re-compiled the zip posted that stated it was patched).  All is fine in terms of usage.  Now back to debugging kernel issues.
Title: Re: Switchres: modeline generator engine
Post by: Monkee on October 11, 2013, 12:10:38 pm
Can anyone tell me if the Sapphire VAPOR-X HD 4890 2 Gb works well with Calamity's drivers and everything that goes with it for the 15khz and modeline coolness?  ;D

Oh and also if it's worth having this 2Gb HD 4890 model compared to another HD 4890 1Gb classic model?

Thanks!
Title: Re: Switchres: modeline generator engine
Post by: machyavel on October 11, 2013, 12:52:04 pm
I have a 4870 (asus) and it works perfectly well, I suppose a 4890 should not differ in that regard.
1GB is largely enough for mame usage.
Title: Re: Switchres: modeline generator engine
Post by: Calamity on May 07, 2014, 05:16:58 pm
==============================
Update 5-7-2014 - Version 1.51
==============================

- Fixed segmentation fault when using some presets (lcd, k7000).
- New monitor presets:
  * pc_31_120: a preset for 120Hz capable PC CRT monitors, at 31kHz (VGA).
  * pc_70_120: same as pc_31_120, but for monitors capable of up to 70kH (SXGA).
  * r666b: Rodotron 666B-29

Note: both 32 and 64 bit binaries are provided as 'switchres32' and 'switchres64'
Remind renaming the one you need as 'switchres' if you use it with Groovy Arcade.

Title: Re: Switchres: modeline generator engine
Post by: Calamity on May 10, 2014, 11:35:13 am
===============================
Update 5-10-2014 - Version 1.52
===============================

- Added new option --edid. This option creates an EDID binary file (edid.bin)
  based on the calculated modeline and the monitor ranges used in its
  calculation. This file can be passed to the Linux kernel on boot in order to
  enable the same user defined timings for both KMS and Xorg.
Title: Re: Switchres: modeline generator engine
Post by: Sledge on July 14, 2014, 06:24:39 am
So i'm just trying to understand some of this resolution/modeline/Hz/etc stuff
I have a question though..
Galaga natively runs at: 288 x 224 (V) 60.606061 Hz
But Switchres chooses: 2560 x 288p 51.774 Hz 16.050 KHz

But if i press F11 during gameplay it says it's running at 100%

How does this work if it's running at 51.774Hz instead of 60 Hz ? Is it running at it's correct speed or not?
Title: Re: Switchres: modeline generator engine
Post by: Calamity on July 14, 2014, 06:47:45 am
How does this work if it's running at 51.774Hz instead of 60 Hz ? Is it running at it's correct speed or not?

Obviously the refresh is not correct (it can't be on a standard arcade monitor). But the speed is, because we detach the emulation from the refresh. This is achieved by triple buffering (multithreading must be enabled for this). GM enables triple buffering automatically when it judges the target refresh is going to be too off, being the default threshold 2.0 Hz. You can modify this value through the -syncrefresh_tolerance option in mame.ini.
Title: Re: Switchres: modeline generator engine
Post by: Ansa89 on July 27, 2016, 09:31:34 am
I fixed some bad bugs (related to memory allocation).
You can find the updated version here (https://github.com/Ansa89/switchres).
Title: Re: Switchres: modeline generator engine
Post by: bopaul on October 13, 2016, 06:19:17 am
Hello,
I am new to this forum and I hope to write in the right section.

I have some problem with Groovymame and Switchres.

I state that I disabled in MAME.INI interlaced resolutions because they do not love them.

With the desktop resolution to 640x480, and Groovymame Swithchres working properly.

If instead you imposed the desktop resolution to 640x240 and Groovymame Swithchres only work for a few games.

Rampage games by type, Paperboy, 19xx, Twincobra, maintains it in exchange for a resolution.

For other types Metalslug, Rolling Thunder, Pacman (Midway) work perfectly.
Some idea?

Use CRTEmudriver 6.5, ATI x300, Groovymame 0148u5.014b and WindowsXP.

Thank you.
Title: Re: Switchres: modeline generator engine
Post by: ronbin on April 26, 2020, 01:14:03 pm
Hi

Coming from here (http://forum.arcadecontrols.com/index.php/topic,160023.msg1713402.html#msg1713402). Groovymame creates a good modeline for sega genesis but standalone switchres doesn't. I gues groovyarcade's switchres comes from this 4 year old git repository, so it may be the problem.
https://github.com/Ansa89/switchres

I've found a newer repository here.
https://github.com/antonioginer/switchres

So cloned it and tried to compile for testing, but I get dependency errors... (SDL_syswm.h). That's strange because I've compiled MAME with groovymame patch in this machine with no problem. Any help for compiling? I'm using debian, but can try from arch.
Title: Re: Switchres: modeline generator engine
Post by: Calamity on April 26, 2020, 01:23:54 pm
Are compiling the branch named "standalone" right? Make sure you checkout this one instead of master.
Title: Re: Switchres: modeline generator engine
Post by: ronbin on April 26, 2020, 03:19:46 pm
I was compiling master... ;D

Cloned standalone branch but now I have another error
Code: [Select]
g++ -c -O3 -Wall -Wextra -I/usr/include/libdrm -fPIC monitor.cpp -o monitor.o
g++ -c -O3 -Wall -Wextra -I/usr/include/libdrm -fPIC modeline.cpp -o modeline.o
g++ -c -O3 -Wall -Wextra -I/usr/include/libdrm -fPIC switchres.cpp -o switchres.o
g++ -c -O3 -Wall -Wextra -I/usr/include/libdrm -fPIC display.cpp -o display.o
g++ -c -O3 -Wall -Wextra -I/usr/include/libdrm -fPIC custom_video.cpp -o custom_video.o
In file included from custom_video.cpp:27:
custom_video_drmkms.h:76:14: error: ‘drmIsMaster’ was not declared in this scope
   __typeof__(drmIsMaster) *p_drmIsMaster;
              ^~~~~~~~~~~
custom_video_drmkms.h:76:14: note: suggested alternative: ‘drmSetMaster’
   __typeof__(drmIsMaster) *p_drmIsMaster;
              ^~~~~~~~~~~
              drmSetMaster
make: *** [makefile:41: custom_video.o] Error 1
:-\
Title: Re: Switchres: modeline generator engine
Post by: Calamity on April 26, 2020, 04:24:26 pm
If you're having troubles, you can try the automatic builds here: https://github.com/antonioginer/switchres/actions/runs/88479738
Title: Re: Switchres: modeline generator engine
Post by: ronbin on April 27, 2020, 02:51:08 am
Thanks Calamity. I could compile it from groovyarcade, there must be something wrong with my debian setup...
It seems new switchres has different options, I will do some tests tonight.

Thanks again!
Title: Re: Switchres: modeline generator engine
Post by: Substring on April 27, 2020, 04:40:10 am
This new switchres version doesn't support the --emulator and --rom switches. You should use -l '<full command>'
Title: Re: Switchres: modeline generator engine
Post by: ronbin on April 27, 2020, 11:09:45 am
This worked perfectly.
Code: [Select]
switchres_main -s 352 240 60 -i mame.ini -l "mednafen /home/roms/Saturn_roms/romname.cue"
switchres_main -s 320 240 60 -i mame.ini -l "mednafen /home/roms/Saturn_roms/romname.cue"
Now I can run saturn games at 704x480 or 640x480 resolution with scanlines. It's a shame I can't know game's resolution before loading it... but that's not switchres' fault.

Thank you for your GREAT work Calamity.
Title: Re: Switchres: modeline generator engine
Post by: Substring on April 27, 2020, 12:54:51 pm
It's a shame I can't know game's resolution before loading it...
That's why I've removed consoles. Whe you play on a CRT, you want some serious business, NTSC vs PAL refresh rates, not some "let's set 230x240 once for all, emulators will adapt".

But things may change ^^
Title: Re: Switchres: modeline generator engine
Post by: DaddyLongLegs on May 01, 2020, 04:14:10 pm
Should switchres be doing anything to 640x480 images on my standard def Wells Gardner?

I know with lower-res stuff I'm used to seeing a huge horizontal number and the same vertical number but my 640x480 games look like this:

(https://i.imgur.com/7aKXTSx.png)

Should the horizontal number be different? Or is that only for lower resolutions?

Also is switchres changing the Hz from 54.124000 Hz to 57.000 hz the reason this particular game runs way too fast? If so, is there any way to fix it?
Title: Re: Switchres: modeline generator engine
Post by: Vantier on February 11, 2021, 10:44:33 am
Hi. I'd like to test the latest standalone build for win32 x86_64 but the automatic builds are all expired and I had no luck compiling it. Anyone can post it, please?
Thank you. 
Title: Re: Switchres: modeline generator engine
Post by: Calamity on February 11, 2021, 01:25:47 pm
Hi. I'd like to test the latest standalone build for win32 x86_64 but the automatic builds are all expired and I had no luck compiling it. Anyone can post it, please?
Thank you. 

Here you go.
Title: Re: Switchres: modeline generator engine
Post by: Vantier on February 11, 2021, 04:37:38 pm
Very Thank you, Calamity!
Title: Re: Switchres: modeline generator engine
Post by: fred92 on October 22, 2021, 09:08:48 am
Hello all,

I'm wondering why when i use super resolutions and mame xml's resolutions the screen shows the right resolution of the game and switchres do the same

but when i only use super resolutions (like the guide of geedorah)
(http://www.abadiadelcrimen.com/crt/5450/20160201_200304.jpg)
 "The value 2560x0 denotes that the super resolutions method is being used. Here, a width of 2560 pixels is forced for all games, while the 0 acts as a wildcard for the vertical resolution (that is, the number of lines), so Groovy MAME will be free to pick the most convenient height from the ones available, applying integer scaling whenever possible. "

so, for me, like the picture shows,  384x224 is not the same as 2560x 240
it's more reassuring to see the same resolutions...

Calamity wrote on a youtube video :
"The whole point of super resolutions is to avoid using long mode lists."
but the game's real resolution is not the same as the one written on switchres...

thank you explaing me.
Fred.

Title: Re: Switchres: modeline generator engine
Post by: Calamity on October 23, 2021, 07:15:54 am
@fred92, this is a recurrent question. 224p is basically 240p with black borders. So 224p is redundant. Switchres is doing the right thing.