Optimal mame hardware+software config?

[Dave_K.]

Hi Elvis, per your remarks on Mame in this other thread, can you please post what your mame configuration consists of?

Idealy, I'd like to understand what video card you are using, what speed processor, any special cabinet interfacing (Jpac, Ipac, ..), what linux distribution (and gcclib levels), what Mame (source?) version, what video driver, and what display modeline timings for 15khz arcade monitor you are using.

[elvis]

Pasting in from the other thread:

Now this sounds very specific to particular games that probably do 60hz refresh and video modes that are already supported by arcadevga and/or advmame. Can you confirm that your Mame setup will output exactly 57.550645Hz on a vertical arcade monitor at standard res with no sprite tearing in the scrolling background or tearing when bosses start flashing at 1/2 the refresh rate while being fired upon?

For starters, don't use an ArcadeVGA. It's a nice, easy method of getting pretty close to arcade-perfect, but it is not all the way there. The simple reason is that it has a finite list of video modelines. Due to the fact that there are so many different games in MAME, and that it can only fit so many modes into it's BIOS, the manufacturers have chosen the top 20 or so most commonly occuring modelines (called the mode in statistics).

Secondly, using an ArcadeVGA through Windows or Linux/X-Windows means you still have a lot of driver layers between you and raw hardware.

The only way to get a perfect modeline is to use a library that allows :
a) Direct writing to the hardware framebuffer
b) Dynamic creation of an infinite amount of analogue modelines

AdvanceMAME is the ONLY MAME build that can achieve this. You ca get very, very close by creating your own custom modelines in either X-Windows or Microsoft Windows using a tool like Powerstrip, but the hardware abstraction layers sitting between you and the framebuffer still add delays. I challenge most people to notice these, but for the sake of this post and the theme of this thread, they are not "perfect enough".

AdvanceMAME allows writing to a framebuffer via two methods: SVGALib (available for Linux and DOS), or the Linux Framebuffer device (fbdev).

Both of these devices require kernel modules to be used under Linux. The reason for needing that is pretty simple: you're writing directly to hardware. Linux doesn't let user processes touch hardware, and as such you need a kernel module to allow that. The DOS version of SVGALib allows direct writing to hardware. Note that SVGALib is available for Windows, but does not allow direct writing to hardware (it only allows high-level HAL modes), and as such is useless to us.

I personally use SVGALib. I find it easier to configure and use. FBDev by default requires patching (the code in the vanilla Linux kernel sets a floor of 31KHz for FBDev to protect PC monitors from damage, and as such requires patching to remove this artificial limitation).

The basic steps are:

1) Set up SVGALib (this requires you to compile the 1.9 tree from source against your current kernel headers, and install the kernel module). Set the conf file in the /etc/ dir with the upper and lower frequency limits of your monitor.

2) Compile AdvanceMAME against SVGALib. Create/edit the AdvanceMAME config files and tell them to use SVGALib as the screen drawing method.

3) The fiddly stuff: AdvanceMAME will create modelines on the fly. It does this by:

1) Extracting the perfect modeline from MAME's XML output
2) Comparing this modeline to the upper and lower limits set in the SVGALib config files
3) Either creating the modeline to match perfectly, or if it is outside the bounds you've set in your SVGALib config file, using a doublescan or interlaced modeline instead.

Before you can run AdvanceMAME, you need to use the advcfg and advv tools to generate some test modelines. Because these are perfect modelines, you'll notice that each and every resolution available will need to be hand adjusted. Unlike a PC monitor that uses 10 or fewer different modelines, and has a basic memory that remembers screen parameters (X/Y deflection, position, rotation, etc) - most arcade monitors have none of this. One of the drawbacks to AdvanceMAME is that switching games willy-nilly will mean you'll constantly need to adjust your monitor. This is a pretty good indication that you've set up AdvanceMAME CORRECTLY. Just like when you switch PCBs, you need to adjust your monitor depending on the game's output.

Both advv and advcfg give you tools to adjust the modelines ever so slightly to assist with lining them up on your arcade monitor without changing vital things like horizontal frequency and vertical refresh.

AdvanceMAME does indeed create perfect modelines. If the particular game you are firing up has a vertical refresh of 57.550645Hz, then AdvanceMAME will ask SVGALib to create that modeline perfectly, and send the exact modeline to it.

AdvanceMAME does not need to use double or tripler buffering nor vsync when used in this way. It has the capability to do so (should you want to use it through SDL or DirectX), but through SVGALib these things make no sense, as you are sending exact modelines that are in perfect sync with the game. There is no tearing and no flickering - images are drawn exactly in sync with the modeline, just like on a PCB.

I urge anyone who has made it this far through this post to go and read this:
http://easymamecab.mameworld.net/html/monitor1.htm

The first few 9 pages are generic monitor theory. Page 10 and on explain how AdvanceMAME works, and how it creates arcade-perfect modelines.

If you are still unconvinced that this is the case, you will need to read the SVGALib documentation, and what it does. When you understand how AdvanceMAME works, and more importantly how it interacts with SVGALib and in turn the framebuffer of your video card, you'll understand why it is entirely possible to create perfect modelines for use with arcade emulation.

My existing MAME cabinet uses Slackware Linux 9.0 on a 2.6.8 Kernel. I set that up quite a long time ago. I've since bought another cabinet and will be building another Linux/SVGALib/AdvanceMAME cabinet on a newer build of Linux (probably Debian, as I like the way it is designed). When I do so, I will document the entire project COMMAND BY COMMAND, and put it on my site. It is not a trivial process (certainly not "turnkey" like most people think), and is something that last time took me quite literally several days worth of time (spread out over a fortnight or so) to get working 100%.

There are also some other nuances that need recognizing. I recall AdvanceMAME and SVGALib being picky about which versions to use, as well as which kernels they worked with. Again, when I do my next cabinet build I'll document this process every single step of the way for others to reproduce should they wish.

[antron]

Thanks elvis, I've been waiting for this.

[Ex-Cyber]

With regard to processor selection:

In layman's terms: both clock speed and having 2 cores are important now if you care about 3d games like Blitz, Carnevil, or Vapor TRX (more than 2 slows down in again in many cases). So buy the fastest Core 2 Duo you can and you'll do fine.

If you only want to play 2D stuff, dual-core probably doesn't offer as much and I'd expect that something like a Pentium E2180 would be fine.

edit: d'oh, I think I got the E21xx and Core2-based Celeron mixed up.

[ReKleSS]

Seconding elvis' advmame recommendation, I run much the same setup. I also have xorg tuned for the cave specific video mode (640x240, 57.???hz). Messing with Xorg is a pain, but necessary if you want a mame version newer than 106. I've been experimenting with using XRandR to let X create perfect video modes, but I've run into some problems - if I mode switch too much on my laptop X crashes out. The radeon driver also has some issues with my video card - I need to run advmame first to get the video card set up right, _then_ X will work. If I can get this to work it should be possible to have this stuff working under X, which will result in better compatibility (and sdlmame, which is actually up to date.)

[Dave_K.]

AdvanceMAME is the ONLY MAME build that can achieve this. You ca get very, very close by creating your own custom modelines in either X-Windows or Microsoft Windows using a tool like Powerstrip, but the hardware abstraction layers sitting between you and the framebuffer still add delays. I challenge most people to notice these, but for the sake of this post and the theme of this thread, they are not "perfect enough".

Yep, this is pretty much as far as I got...almost perfect with powerstrip. I did try DOS/Advmame with SVGAlib but for some reason was still getting the same tearing, and the Advmame linux LiveCD was not recognizing my hardware correctly, I think thats when I threw in the towel. Seems I'll have to do a proper linux build and compile everything as you suggested.

Thanks again for the details elvis, and I'll keep you all updated as I begin this journey yet again.

[antron]

you know if someone built a fullly configured distro like this their name would be revered by gamers for generations to come

[cools]

I used to use Advmame running on the framebuffer (Matroxfb) rather than SVGAlib.

The matrox framebuffer driver didn't need patching at the time, and allowed 15KHz modes. As a bonus, using the framebuffer means you can have the console displaying perfectly from bootup by adding video mode kernel parameters.

This was with Gentoo as it's a cinch to fiddle about with and cut down to size (and since everything's source based it made sense to me to continue with that theme - compiling advmame etc). If I was to do it again, which is highly unlikely, it'd be with Debian.

[Dave_K.]

After some initial digging, seems RekleSS' comment above is rather important. AdvanceMame development has formally stopped as of October of 2006. So should I invest time into Advmame + SVGALib knowing there is no support for latest mame rom compatibility, or go down the path of the new SDLMame (which by default has framebuffer support)?

[zakk]

After some initial digging, seems RekleSS' comment above is rather important. AdvanceMame development has formally stopped as of October of 2006. So should I invest time into Advmame + SVGALib knowing there is no support for latest mame rom compatibility, or go down the path of the new SDLMame (which by default has framebuffer support)?

sdlmame doesn't do the auto-modeline/timing type stuff that advancemame does, so you'll have to define all your own modelines and all the fiddly stuff that's required along with that.

The problem is at some point there was a huge internal overhaul of the mame codebase; which means it's not trivial to patch new game/driver support into advancemame. The way to go would be to modify sdlmame to do the same modeline twiddling advancemame did, but so far no one has taken up that task.

[elvis]

The AdvanceMAME project stopping was a great shame. I completely understand of course - projects like these are a thankless job. I've developed lesser software before and seen the amount of crap you get in emails and mailing lists where people whinge and bitch that your software isn't good enough, or doesn't do enough. Particularly when you do it for free and in your own spare time, it's disheartening.

I hope someone picks up the project and continues it. I only wish I had the coding smarts to do it myself.

With my next cabinet project I also want to test something else: there are a number of tools out there that will calculate modelines for you and spit them out in xorg.conf format. I want to write a trivial script that will ask a particular build of sdlmame for all the output modes it wants, generate each modeline separately, and then plonk the whole lot into a text file to copy and paste into your xorg.conf file.

I'm fairly confident that the script and modeline calculation part will work. What I don't know is whether or not Xorg/SDL won't add additional lag and/or tearing without the aid of a lower-level library like SDLMame or FBDev. Hands on testing is the only way I'll find out.

[cools]

It is still possible to merge the advmame sources with the official mame ones, and compile correctly. A friend of mine produces his own personal build (with all drivers enabled, splash screens disabled etc) like this.

With my next cabinet project I also want to test something else: there are a number of tools out there that will calculate modelines for you and spit them out in xorg.conf format. I want to write a trivial script that will ask a particular build of sdlmame for all the output modes it wants, generate each modeline separately, and then plonk the whole lot into a text file to copy and paste into your xorg.conf file.

This same friend also has his own tools for this, and does exactly the same thing but for advmame (every resolution that mame wants, tweaked so that they are centred).

I'll point him towards this thread, he might be interested enough to chime in with some thoughts

[Dave_K.]

I'll point him towards this thread, he might be interested enough to chime in with some thoughts

That would be great, thanks!

[it290]

This site:

http://easymamecab.mameworld.net/

And this one:

http://kirurg.org/emame/

are of great help when setting up MAME for proper arcade monitor output. In my personal setup I use FBdev rather than SVGAlib because it was the only way I could get the pixel clock low enough with my ATI video card. Even that required patching the kernel. The main thing to work on is getting the lowest resolution modes to work properly, because once you get those, the rest are easy.

[elvis]

Yes, that would be awesome. He would have a large audience available to him if he ever decided to organise those thoughts onto a website/blog somewhere.

[Dave_K.]

And this one:

http://kirurg.org/emame/

Hah! I had just discovered this site yesterday and was amazed at the info! I like his minimalist approach starting with Busybox, as I'd also like to do this on a USB stick so I don't have mess up my normal windows (boot) partition.

[it290]

I have my setup running from a 4G Ubuntu partition, and that includes X11, a couple of playstation ISOs, and a bunch of vertical shmups (all the Raizing/Cave/Psikyo/Toaplan games and miscellaneous others), so a USB stick is easily doable. Another option would be running off a CompactFlash card, as if you get a cheap ($20) adapter, the computer views it as a regular IDE device, so you can avoid some of hiccups that bootfing from USB sometimes causes.

[Dave_K.]

Another option would be running off a CompactFlash card, as if you get a cheap ($20) adapter, the computer views it as a regular IDE device, so you can avoid some of hiccups that bootfing from USB sometimes causes.

Very good point! As ultimately I'd love go the embeded route and get one of those single board computers and run it off a CF slot, just like he is doing here.

[ReKleSS]

With my next cabinet project I also want to test something else: there are a number of tools out there that will calculate modelines for you and spit them out in xorg.conf format. I want to write a trivial script that will ask a particular build of sdlmame for all the output modes it wants, generate each modeline separately, and then plonk the whole lot into a text file to copy and paste into your xorg.conf file.

I'm fairly confident that the script and modeline calculation part will work. What I don't know is whether or not Xorg/SDL won't add additional lag and/or tearing without the aid of a lower-level library like SDLMame or FBDev. Hands on testing is the only way I'll find out.

This is not difficult. However, for any given resolution, xorg will only pick the optimal (highest refresh, I believe) modeline. Try looking into XRandR 1.2 - it allows you to add modelines on the fly. I don't believe there should be any lag issues, as sdlmame paints either through OpenGL or an SDL overlay - it's talking to the video card directly. Try this:

Code: Select all

./mame -listxml | grep '<display' | uniq

It is still possible to merge the advmame sources with the official mame ones, and compile correctly. A friend of mine produces his own personal build (with all drivers enabled, splash screens disabled etc) like this.

I've looked into doing this myself, and due to the source reorganization it's a huge mess. I can see that it's possible, but not without a huge amount of work, which would be better spent rewriting advancemame as an OSD module for the new codebase. Am I missing something?

[zakk]

Code: Select all

./mame -listxml | grep '<display' | uniq

Pipe the grep output through sort first, makes a huge difference. (Uniq only knows how to remove duplicate adjacent lines). On the few month old version of sdlmame I had on my mame box, without the sort it was 1661 lines, with it was 453.

[elvis]

Code: Select all

./mame -listxml | grep '<display' | uniq

For some reason uniq doesn't work fully on mame's output. There's a few games in there where the XML output is different, despite having the same resolutions.

Here's what I did on my laptop where SDLMame is installed:

Code: Select all

sdlmame -listxml | grep '<display' | awk -F "width\="" {'print $2'} | awk -F """ {'print $1, $3, $5'}  

That will spit you out a space delimited output of "width height refresh".

From there I chuck the lot into a MySQL table, and do a "SELECT DISTINCT". The "wc -l" command on "uniq" gives me 1072 different resolutions. Just eyeballing the output I can see that's wrong. Out of the MySQL table I get 310 distinct resolutions.

Output looks like (truncated with "head"):

Code: Select all

dan@danmobile:~$ mysql -u user -ppasswd -D mame -ABN -e "select distinct r from res;" | head

288 224 60.606061
256 224 60.606061
288 224 60.606060
272 236 60.000000
224 224 60.606061
256 224 60.000000
240 224 60.000000
288 224 60.000000
320 240 57.000000

Once in this format, I can feed it via a "while read" loop to lrmc (Low Resolution Modeline Calculator) which will then in turn generate all the modes I need for Xorg.

http://lrmc.sourceforge.net

Again, truncated output looks like:

Code: Select all

dan@danmobile:~$ mysql -u user -ppasswd -D mame -ABN -e "select distinct r from res;" | head | while read res ; do ~/src/lrmc-0.9.2/src/lrmc ${res} -cga -l ; done
Try `/home/dan/src/lrmc-0.9.2/src/lrmc --help' for more information.

    # 288x224x60.61 @ 15.750kHz
    Modeline "312x240x60.11"  5.922000  312 320 352 376  240 244 247 262  -HSync -VSync

    # 256x224x60.61 @ 15.750kHz
    Modeline "280x240x60.11"  5.292000  280 288 320 336  240 244 247 262  -HSync -VSync

    # 288x224x60.61 @ 15.750kHz
    Modeline "312x240x60.11"  5.922000  312 320 352 376  240 244 247 262  -HSync -VSync

    # 272x236x60.00 @ 15.750kHz
    Modeline "280x240x60.11"  5.292000  280 288 320 336  240 244 247 262  -HSync -VSync

    # 224x224x60.61 @ 15.750kHz
    Modeline "480x240x60.11"  9.072000  480 496 544 576  240 244 247 262  -HSync -VSync

    # 256x224x60.00 @ 15.750kHz
    Modeline "280x240x60.11"  5.292000  280 288 320 336  240 244 247 262  -HSync -VSync

    # 240x224x60.00 @ 15.750kHz
    Modeline "520x240x60.11"  9.828000  520 536 592 624  240 244 247 262  -HSync -VSync

    # 288x224x60.00 @ 15.750kHz
    Modeline "312x240x60.11"  5.922000  312 320 352 376  240 244 247 262  -HSync -VSync

    # 320x240x57.00 @ 15.750kHz
    Modeline "336x252x57.07"  6.300000  336 344 376 400  252 257 260 276  -HSync -VSync

Some of those modes look odd, however. I wonder if I'm supposed to compensate for blanking lines? Input here is appreciated.

So I've got the output, but haven't tried it yet (I don't have a machine running Xorg hooked up to a 15KHz monitor - the one I do have is an SVGALib box). I do have a spare 15KHz cab (currently hooked up to a PS2), so I'll grab myself a JPAC and begin testing soon.

[zakk]

As I said, sort before applying uniq. Uniq only removes adjacent matching lines.

320x240 60
320x240 60
320x232 60
320x240 60

will become this after being run through uniq
320x240 60
320x232 60
320x240 60

If you sort it first, all the 'same' lines will become adjacent and then uniq will properly work.

ninja edit:

I just tried your awk piping but with a sort, I get 308 resolutions. This is an older copy of sdlmame so I'm probably missing a few games compared to something current.

Also you probably want to throw a 'grep -v vector' in there.

Also also: the reason you get too many resolutions if you grab the raw -listxml through sort/uniq is that some of them are the same except for the 'rotate' attribute.

[elvis]

As I said, sort before applying uniq. Uniq only removes adjacent matching lines.

Ah, well that makes sense then. I can eliminate the need for the MySQL database, and write a monster one-liner script to do the whole thing now.

Thanks for the feedback.

[zakk]

I've been messing around with sdlmame, modeline generators and advancemame for the last 24 hours.

I've been using gigawing as a test, because my CPS2 board was sitting in the cab next to my desk anyways, so I can flip back and forth via my video switcher.

Mame info says gigawing is [email protected]

Advancemame's video menu says it's doing 832x240, pclock 17.5, hsync 15.6, vsync 59.6

My D9200's status display says the hsync is 15.5, but whatever.

The D9200 says the CPS2 board is 15.3khz@59hz. I'm not so worried about small horizontal sync variations though.

So if you punch 384 224 59.633333 into lrmc, with -cga -l, you get something that works, but is very horizontally squished. If you use -cga -h instead, you get the advancemame modeline.

The problem is it seems impossible to get sdlmame to auto-pick that res, since 384 is no where near 832 the resolution matching weights it really low. I can't seem to manually pick it either, I get an error.

There's some dim recollection in my head that CPS2 uses a weird pixel aspect ratio, so maybe this isn't the best test of things?

[Dave_K.]

There's some dim recollection in my head that CPS2 uses a weird pixel aspect ratio, so maybe this isn't the best test of things?

Yeah, its closer to 16:9 than 4:3 aspect. Go into the test menu and pull up the test grid. If you make the grid square, you will see lots of room above/below. So your 384 224 59.633333 with -cga -l was probably right if you then adjust the vertical size on the monitor.

[zakk]

There's some dim recollection in my head that CPS2 uses a weird pixel aspect ratio, so maybe this isn't the best test of things?

Yeah, its closer to 16:9 than 4:3 aspect. Go into the test menu and pull up the test grid. If you make the grid square, you will see lots of room above/below. So your 384 224 59.633333 with -cga -l was probably right if you then adjust the vertical size on the monitor.

Yeah, thought so. I'll try with something less strange, probably Dangun and see how that goes.

[elvis]

There are very few games out there that have square pixel ratios. When talking analogue/CRT monitors, the concept really doesn't matter, as horizontal "resolution" is fairly meaningless.

[zakk]

Actually I'm just retarded and forgot to tell AdvanceMAME it could use low pixelclocks. The reported resolution in Dangun now makes sense and involves no resizing. Durrrrrrrrrrasggd


Ok, generated a modeline and used sdlmame. SDLMame's switchres stuff is annoying. So the modeline generated with -cga -l comes out as 336x250 instead of 320x240. But there's a built-in non-15khz 320x240 mode in X11 that always matches. If you force it via -resolution0 it works really well, though. I can tell it's pretty accurate because it confuses my capture card in the exact same way my board does.

Although it may need to be hand-tweaked a bit; not 100% sure it's got the vsync perfect.

[wrdaniel]

remembered this thread as i read the news about new mame 0.123u3

mame 0.123u3

... Updated info.c to output raw video parameters (pixclock, htotal,
hbend, hbstart, vtotal, vbend, vbstart) via -listxml if they have
been given. [couriersud] ...

maybe its usefull for you

[cools]

Ooh. That *is* interesting