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 fonticamente

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 Window