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

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


  

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

0 Members and 1 Guest are viewing this topic.

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
Switchres: modeline generator engine
« 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 - Switchres homepage with more information
« Last Edit: July 05, 2011, 12:54:47 pm by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Quinny

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
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.

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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.
« Last Edit: October 07, 2010, 01:43:27 pm by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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).
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

ves

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 204
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.

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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 :/.
« Last Edit: October 08, 2010, 01:00:58 pm by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Online Online
  • Posts: 5470
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

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

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
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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

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

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
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization

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.


SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Online Online
  • Posts: 5470
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.

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

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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/
« Last Edit: October 09, 2010, 12:21:11 am by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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. 
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Online Online
  • Posts: 5470
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.

« Last Edit: October 09, 2010, 06:24:41 am by Calamity »
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Online Online
  • Posts: 5470
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!
« Last Edit: October 09, 2010, 04:04:19 pm by Calamity »
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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

SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Online Online
  • Posts: 5470
Back in a minute...
« Last Edit: October 10, 2010, 07:30:58 am by Calamity »
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Online Online
  • Posts: 5470
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

Thanks for the good work!



« Last Edit: October 10, 2010, 07:58:51 am by Calamity »
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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

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.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

ves

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 204
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.

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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 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
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/  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.



SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

ves

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 204
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.
« Last Edit: October 11, 2010, 05:28:43 am by ves »

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
Hello, for anyone who is interested in compiling the driver etc. .. I leave from ubuntu packages needed to compile the driver Ati.
x11proto-DRI2-dev_2.3-1_all.deb
x11proto-fonts-dev_2.1.0-1_all.deb
x11proto-video-dev_2.3.0-1_all.deb
x11proto-xf86dri-dev_2.1.0-1_all.deb
xserver-xorg-Dev_2 :1.9.0-0ubuntu7_i386. deb

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

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

Any suggestions for using this with a monitor HANTAREX 9110?



Thanks.
Escuchar
Leer fonťticamente

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

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

Definitely interesting to see how it works with a pure arcade monitor, instead of my d9800.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Online Online
  • Posts: 5470
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

« Last Edit: October 11, 2010, 06:01:53 am by Calamity »
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Online Online
  • Posts: 5470
Sorry, I duplicated my last post...
« Last Edit: October 11, 2010, 06:03:01 am by Calamity »
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Online Online
  • Posts: 5470
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).

« Last Edit: October 11, 2010, 06:33:33 am by Calamity »
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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. 
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

ves

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 204
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.

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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).

SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Online Online
  • Posts: 5470
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.
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

ves

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 204
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.

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

ves

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 204
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.

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
    • The Groovy Organization
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.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

ahofle

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4524
    • Arcade Ambience Project
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


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. 

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Online Online
  • Posts: 5470
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


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.


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

  
 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31