Category: MAME'd Millipede :: 4. Software
I have discussed video issues in previous Electronics and Software sections of this website. For the sake of completeness, though, I thought it made sense to cover the overall procedure in one place under its own heading.
On a Linux system like mine the most functional choice for driving an arcade monitor is SVGALib. Your mileage may vary depending on a lot of different factors ranging from software versions to the type of video card and even the revision of the card's BIOS or firmware. In this case I'm using a 3D Rage Pro (rev 92) that is mounted on the motherboard of a Dell system and (as of the time of this writing) version 1.9.17 of SVGALib on a Linux kernel version 2.4.20 that I compiled.
I initially had a great deal of problems with stability of various resolutions and even mode switching between AdvanceMAME and AdvanceMenu. In these cases the machine would simply go black and lock up. This is not common behavior for a Linux box and tends to get your attention (as well as annoy the crap out of you).
As I have noted in past pages, things stabilized for me when I stumbled on a series of patches for SVGALib (some of them specifically Rage oriented) in the contrib directory of the AdvanceMAME source. I have not had a lockup of the system since. I also did not have lockups under DOS when I was testing the same system, but I found it to be a lousy alternative to Linux in many ways (speed, network access, flexibility, etc). No shock there.
From a configuration perspective, here is my /etc/vga/libvga.config file that gives SVGALib its operating parameters:
HorizSync 15.5 16.0 VertRefresh 47 63 #HorizSync 30 85 #VertRefresh 48 120 mouse Microsoft mouse_accel_type off
modeline 640x480 13.5821 640 696 760 864 480 484 491 521 -hsync -vsync interlace
It's short and sweet. Trust me - don't keep the default file in place after you compile SVGALib from source... it's far more complicated than its worth under these circumstances. I provided a little more detail on this in the Software: AdvanceMAME page.
What I'm going to describe is the simplified procedure sans all the thrashing about and making oneself crazy (your mileage may vary).
Starting with a fresh install of AdvanceMAME, I fired up advcfg, told it I had a fixed frequency monitor and selected Wells-Gardner K7200 (which just so happens to be my model). I took the test pattern it provided and exited the program with the option to save my settings. This establishes the initial device profile in your advmame.rc file that will be expected by other applications.
After this I used advv, set it for 32-bit palette mode and began to check out the various resolutions. This is going to be somewhat specific to your hardware and your games of choice. In my case I needed quite a few modelines that were exactly those of my favorite games or as close as I could come in the grand scheme of things.
I say "the grand scheme of things" here because you are highly unlikely to nail every resolution you need for every game. Some will likely just not work on your card. A few of the very lowest (sub-200 pixels x or y) were not possible with the Rage. Others are possible but only with a frequency or refresh rate that will cause some roll or strange tearing. You might be able to adjust your monitor to display it but you will likely have knocked it out of range for others.
In some cases the parameters for a given modeline are in the ballpark with the others I required but the image is too wide, rolls slowly, is off center, somewhat torn, or some combination of all these annoyances. In these cases I generally can use the keys displayed on the test pattern to adjust the pixel clock, center the image, squeeze or stretch it, etc.
Each of these changes is adjusting fundamental elements of the larger equation that make up a given modeline. There are limits and some things are just going to be outside those limits in one way or another. In some cases I will look up the true resolution of a game in its Game Information within AdvanceMAME. I will then return to advv and manually generate a modeline with those basic parameters and begin tweaking it. If I can arrive at a close (or precise) match that looks good, I will save it. Upon returning to that game I can select my newly created modeline from the list and save the game profile locked to that custom modeline.
There are a number of horizontal games that will choose resolutions in AdvanceMAME that are, unfortunately, rolling like mad or torn. These are cases where the frequencies involved are just too far outside of the majority of others upon which my physical monitor settings are based. In these situations I generally have to use something like 480x480 or 640x480 (much larger than required) to get a stable picture with the correct aspect ratio. Once this is done I will often use the resize option of AdvanceMAME within the game. If the multiples are right, the game will look virtually perfect (for a horizontal game on a vertical screen).
My priority is having perfect (or close to perfect) modelines for the classic vertical games I care about most. The horizontals and others that make demands out of my primary range are the ones I have to compromise on. Fortuantely, AdvanceMAME does a wonderful job when you consider the complexity of the task. The true answer for me is building a horizontal sister machine someday. Until then I am quite happy with the current results.
The process of tweaking modelines is a fairly low-level task that is going to require a great deal of trial and error. Don't be startled if you get errors message when you push an adjustment to some point that is either not physically possible or causes your hardware (or its driver) to barf. Lockups, black screens and error message right when you think you almost have it are not unusual. Yes, it's irritating. No, it's not impossible (usually).
In the end, you're mostly going to have to look at a lot of games (focus on those most important to you) and diddle around in advv a great deal to find that sweet spot for your system. You are welcome to download my advmame.rc for examples.