Software Support > GroovyMAME

Switchres: modeline generator engine

<< < (4/260) > >>

bitbytebit:

--- Quote from: Calamity on October 09, 2010, 03:48:46 pm ---
--- Quote from: bitbytebit on October 09, 2010, 12:59:51 pm ---I've been able to hack the Radeon driver and basically replace the modeline calculations it does with lrmc's.  So essentially I put lrmc into the Radeon driver and it no longer uses the default Xorg modeline calculator.
--- End quote ---

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 ;)


--- Quote from: bitbytebit on October 09, 2010, 12:59:51 pm ---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.
--- End quote ---

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?

--- End quote ---

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.


--- Quote from: Calamity on October 09, 2010, 03:48:46 pm ---
--- Quote from: bitbytebit on October 09, 2010, 12:59:51 pm ---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.

--- End quote ---

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

--- End quote ---

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.


--- Quote from: Calamity on October 09, 2010, 03:48:46 pm ---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!

--- End quote ---

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

--- Quote from: Calamity on October 09, 2010, 03:48:46 pm ---

--- End quote ---

Calamity:
Back in a minute...

Calamity:

--- Quote from: bitbytebit on October 09, 2010, 08:13:38 pm ---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.
--- End quote ---

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.


--- Quote from: bitbytebit on October 09, 2010, 08:13:38 pm ---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.
--- End quote ---

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!



bitbytebit:

--- Quote from: Calamity on October 10, 2010, 07:56:09 am ---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!

--- End quote ---
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.

ves:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version