PDA

View Full Version : Custom modeline creation



elvis
21st July 2008, 09:19 PM
I'm going to use this thread as a scratch-pad for fiddling around with custom modelines for MAME. Once I work out something final, I'll post a definite how-to in the "tips and tricks" forum.


Looks like this thread already got moved. So I'll put a disclaimer in here - none of the following is final nor is it thoroughly tested. Please take caution when using any of the below data, as I won't be responsible if you blow up your monitor!


First a quick background on modelines:

http://easymamecab.mameworld.net/html/monitor1.htm

A modeline is the way a "resolution" is defined to a CRT monitor. The link above explains it in fantastic detail if you want to know the ins and outs. A lot of what I'll talk about in this thread will assume you understand the concepts of CRTs, such as counting lines (and not pixels), blanking lines (lines above and below the signal lines for blanking/sync signals), and whatnot.

CRT monitors are generally measured in "KHz" (KiloHertz), or thousands of refreshes per second - referring to how many times per second the horizontally drawn lines are refreshed. Along with the line count, vertical refresh (or "refresh rate" as most would know it), the data is all calculated to form a mode line.

The vast majority of older games were designed for 15KHz monitors. Roughly speaking (again, it is incorrect to use such terminology), this is about 320x240 pixels at 60 Hz (or 60 "frames per second"). Without getting into the nitty gritty of it all, this can also be 640x480 pixels, interlaced at 30 frames per second made up by 60 fields per second, with each field containing half the frame information (or more commonly, 480i). And if you'd read the link above, you'd realise that there are a huge volume of "resolutions" that can make up a 15KHz signal, not just nice 4:3 round numbers based on VGA ratios.

Which brings me to the point of this thread: calculating all the resolutions needed for MAME.

By and large software operating systems designed for modern computers will lock you out of the ability to send frequencies lower than 31KHz (VGA) out of your video card (sending a 15KHz mode to a 31KHz monitor can potentially damage it, if it doesn't have a protective shutdown mechanism - the "signal out of range" errors you see on your PC monitor sometimes).

There is however plenty of software out there that can allow you to force these low resolution modes from a wide range of standard video cards. Three I'll concentrate on are:

1) AdvanceMAME (http://advancemame.sourceforge.net/). Under Linux or DOS this software would allow you to either use pre-defined modes, or automatically create modes on the fly via svgalib or FBDev software libraries. Brilliant software, but sadly discontinued by the author who is too busy to keep working on it. Still a good pick if you're after older games.

2) Powerstrip (http://www.entechtaiwan.net/util/ps.shtm). Pay-for software, it allows you to create and use any custom modelines directly from any version of Windows (including XP and Vista). The beauty here is you can set the modelines in the software, run a standard version of MAME or MAME32, and let MAME automatically pick the matching modeline.

3) Xorg. The most common Linux and UNIX windowing system, it sits below GNOME, KDE and all the other window managers. By default the new versions auto-detect monitors and video cards, but it can still be hand-configured via a powerful config file to make custom modelines (in fact, back in the dark old days of Linux, writing your own modelines by hand were the only way to configure it!). SDLMAME is developed by MAME dev "R. Belmont", and can be configured to automatically select any modeline available to X (just like MAME + Powerstrip under Windows).

There's also projects like Soft15KHz, but I've not played with them. When I do get a chance to investigate it, I'll add it to the guide.

And of course, there is the ArcadeVGA - a hardware video card with a custom hacked BIOS to add a number of custom modelines. The downside to the ArcadeVGA is that (a) it costs a packet, and (b) it only includes the most common modelines. Games like the Irem titles (the R-Types, Hammering Harry, and others) do not have a modeline to match, and end up out of sync (video tearing, image stuttering, etc). It's worth noting that you can use software custom modelines side by side with an ArcadeVGA.

There are plenty of modeline calculators out there. I use "LRMC" (Low Resolution Modeline Calculator):
http://lrmc.sourceforge.net/

As well as that, I'm going to use some pretty standard GNU tools to automatically grab information from MAME and shove it into lrmc. These are available natively under Linux/UNIX, or can be downloaded via Cygwin (http://www.cygwin.com/) for Windows.

So onto the good stuff. I'm using sdlmame for Linux (although MAME for Windows will do the same) with the -listxml output to generate every bit of information for every game in MAME.

[edit] The following was in a code block, but parts of it kept getting dropped by the forum software, so now it's not in the block any more. It should be done on one line.

sdlmame -listxml | grep 'display type' | grep raster | awk -F "width=" {'print $2'} | awk -F "\"" {'print $2, $4, $6'} | sort | uniq | while read RES ; do ./lrmc $RES -cga -b -n -l ; done

The command above uses the awk and grep commands to pluck out the resolution and refresh strings I need, sort them and take only unique ones (obviously many games share resolutions, so I only need to generate each mode once). I've used the -cga and -b flags to force 15KHz "CGA" output only, and a best-match (ie: no artificial vsync or buffering, which adds delay and creates a non-perfect mode). -n prevents integer stretching (often done on the horizontal when low pclocks can't be done by the hardware), and -l forces the low pclock (allowing the low frequency horizontal value).

LRMC allows quite a few config options:



Usage: ./lrmc x y refresh [OPTIONS]
Usage: ./lrmc modelist.xml [OPTIONS]
Compute a modeline given a resolution and refresh rate.

-v, --vsync nearest mode in vertical syncronization
-b, --bestscan nearest "best scan" mode (i.e. no vsync)
-i, --interlace enable interlace calculations
-d, --doublescan enable doublescan calculations
-n, --nostretch disable integer stretching
-y, --ystretch assume fractional vertical stretching
-l, --lowpclock allow pixel clocks lower than 8mHz
-h, --highpclock use pixel clocks of 12mHz or higher
-w calculate interlaced mode
-z calculate doublescanned mode
-3x4 aspect ratio 3:4
-pal 15.625kHz PAL (European Television)
-ntsc 15.734kHz NTSC (US Television)
-cga 15.750kHz CGA arcade monitor
-ega 24.960kHz EGA arcade monitor
-vga 31.500kHz VGA arcade monitor
-d9200 15.750, 25.000, 31.500kHz arcade monitor
-multi 31.500-65.000kHz multisync PC monitor (default)
-x, --X11R6 print X11R6 modeline format (default)
-f, --fb print fb modeline format
-a, --advmame print AdvanceMAME format
-s, --SDL print X11R6 and AdvanceMAME SDL combination
-p, --powerstrip print PowerStrip modeline format
-r [NUMBER] [NUMBER] of reference modes
--reference=[NUMBER] [NUMBER] of reference modes
-c [FILE] use configuration file [FILE]
--configfile=[FILE] use configuration file [FILE]
--default create a default configuration file
--verbose print modeline details
--version


You'll note I can select output to match X, AdvanceMAME or PowerStrip. Handy, because I can generate config files and literally copy and paste.

So, I run the commands, and generate the following:

Xorg config (http://www.stickfreaks.com/modelines/modelines_0.125_x.txt)
Powerstrip Config (http://www.stickfreaks.com/modelines/modelines_0.125_powerstrip.txt)
AdvanceMAME Config (http://www.stickfreaks.com/modelines/modelines_0.125_advancemame.txt)

I notice in the files there are plenty of double-ups in those files, which is fair enough. MAME has plenty of modes in it for EGA, VGA and higher resolutions, and the script above is trying to force them down to CGA (by sacrificing lines - for example 640x480 will draw half the lines down to 640x240, etc).

So that's it for now. I've got a cocktail cab to finish off for a mate, and then I'll be getting into testing these. Currently my upright cabinet is running AdvanceMAME in auto-generation mode, so I don't need to add in custom modelines. But given the fact that AdvanceMAME halted at version 0.106, it means that if you want to run a new build of MAME on a real arcade monitor without an ArcadeVGA, then custom modelines are the only way to go. And I'm keen to get some CPS3 action in my cab, so it's going to be a Linux/Xorg/SDLMAME combo. But before that goes live, I'll do a Windows/Powerstrip test just for kicks.

More in another month or so.

[edit]

I will also revisit this thread and go about creating custom modelines for other styles of monitors (24KHz, 31Khz, multisync), including doubled modes for running perfect integer stretched modes on VGA monitors. This will allow people to run games at exactly double the X and Y resolution with an integer stretch in MAME, add after-effect scanlines and get a far better picture from the VGA monitors than the standard MAME software stretch. This is pretty much what the new generation ArcadeVGA does when you use it on a VGA or higher res monitor.

luddite
12th April 2009, 12:27 PM
Hey elvis - thanks for this post - ive been playing around with advancemame for a few weeks now and cant get LRMC to work at all.

But advancemame does create a screen that has the game in it.

Unfortunately the game is about a 1/4 of the screen size and is placed top middle.

I cant get it to grow to fit the entire screen - although just using mame on its own i can get wonderful fullscreen games.

Any ideas what I am screwing up on?

elvis
12th April 2009, 12:43 PM
I was thinking just this week that I hadn't had a chance to come back and do more work on this...

luddite: can you give more information? I'm assuming you've got a standard 15KHz arcade monitor. What game are you building the modeline for (what's the exact name of the ROM), what modeline gets generated, and what messages does AdvanceMAME give when you fire up the ROM (it should tell you which modeline it chose)?

It sounds to me like maybe the modeline is wrong, and it's making some incorrect assumptions about certain values. If not that, then AdvanceMAME has the correct modeline but is choosing a different one as a preference, which means you might need to prune your config file, and/or put entries in to force certain games to choose certain modelines.

luddite
14th April 2009, 09:32 PM
Hi elvis - i dont know how on earth I solved it but it has been solved. Currently its looking ok.

However my screen adjustments need to be tuned every couple of reboots- this isnt norml at all.

Maybe the modeline is faulty> Ill post it soon.

elvis
16th October 2010, 09:38 PM
Almost 18 months later and I've finally had the time to do this. (Finally got some time off work!).

So the experiments have gone well. I've used Ubuntu "Lucid" 10.04 LTS 32bit as my base, and installed a minimal command line system. I've thrown ALSA (sound) and Xorg/xinit (graphics/input) on there.

Hardware is AlthonXP 2000+ (1.67GHz), 512MB RAM, NVidia TNT2 AGP video, JPac into a Kortek 26" 15KHz (CGA) arcade monitor/chassis.

Changes made to the Linux system:

1) in the file /etc/X11/Xwrapper.config changed
allowed_users=console
to
allowed_users=anybody

This allows me to start MAME via startup scripts.

2) Added a user called "mame", and a /home/mame/.xinitrc file that has one line:
mame ssf2xj -verbose > /tmp/mame.out

This starts MAME, running Super Street Fighter II Turbo (Japanese edition), with debugging info spat out to a temporary file (that allows me to see what resolution MAME chooses).

3) Edit my /etc/mame/mame.ini file to include the following changes:

video soft
keepaspect 0
unevenstretch 0
effect none
centerh 1
centerv 1
waitvsync 0
switchres 1

4) Add a modeline to my xorg.conf file. According to this (http://maws.mameworld.info/maws/romset/ssf2xj), ssf2xj runs at a resolution of 384x224and a refresh of 59.629403Hz. Punching that into lrmc and specifying a CGA (15.750KHz) monitor, Xorg output and low pclocks:

$ lrmc 384 224 59.629403 -cga -x -l
# 384x224x59.63 @ 15.750kHz
Modeline "416x241x59.66" 7.812000 416 424 464 496 241 245 248 264 -HSync -VSync

Initially this didn't work, because Xorg only allows pclocks of 12MHz or higher by default. This forces 31Khz modes only (VGA and up). So next I had to hack the driver to fix this.

5) Hack the "nv" (NVidia) driver in Xorg manually. I downloaded xf86-video-nv-2.1.15.tar.bz2 (http://lists.freedesktop.org/archives/xorg-announce/2009-September/001031.html) and decompressed it. I edited two files:

First: src/nv_hw.c line 775 from
if ((Freq >= 120000) && (Freq <= 350000)) {
to
if ((Freq >= 100000) && (Freq <= 350000)) {

Second: src/nv_setup.c line 274 from
pNv->MinVClockFreqKHz = 12000;
to
pNv->MinVClockFreqKHz = 6000;

and line 331 from
pNv->MinVClockFreqKHz = 12000;
to
pNv->MinVClockFreqKHz = 6000;

Save the files, and run the usual "./configure ; make" to build it.

Once built:
mv ./src/.libs/nv_drv.so /usr/lib/xorg/modules/drivers/nv_drv.so

This will overwrite the NVidia driver to allow the low resolutions (otherwise you need to use high pclocks and horizontal scaling, which kills performance).

6) Now it's all ready to run. Copy the ROMs to the right place, and edit /etc/rc.local to start Xorg automatically on boot:

su - mame -c 'touch /tmp/sdlmame_out ; startx'

That will switch user to "mame", create /tmp/sdlmame_out (hard coded into MAME for it's own logging), and starts Xorg. The .xinitrc in (2) will start MAME when X starts.

Reboot, and watch it all come online.

When it boots, the following memory is used:

Xorg (graphics/input): 6.6MB
MAME running SSF2T: 73.2MB
Linux system, ALSA audio, and other stuff: 2.1MB

Grand total: 82MB used for this particular game. No doubt other games like Metal Slug or King of Fighters will chew up more RAM. But this is a good start. 100% accurate modes and bugger all memory usage.

Next step is to use the tools written by this guy:
http://forum.arcadecontrols.com/index.php?topic=106405.0;all

Which will automate a lot of the processes I covered in the first post. That includes parsing MAME's XML output, generating accurate modelines, and making MAME "ini" files for each and every game to force the correct modeline of choice from Xorg.

elvis
20th October 2010, 02:19 PM
Balls...

As per the forum.arcadecontrols.com link above, there are some rather silly things going on with Xorg at the moment. The biggest issue is that refresh rates for modelines are ignored, and everything is assumed to be 60Hz even, which means no vsync, and lots of screen tearing.

I've mucked around a bit with XRandR, but it doesn't seem to be doing things the way I want. There are two guys working on a lot of patches for it currently, but it's a headache.

So... I'm going to restart the process with Ubuntu 8.04LTS instead. It uses Xorg 7.3 (10.04LTS uses Xog 7.5), so hopefully it will be old enough that it was back when Xorg was still honoring full custom modelines properly, and not this "assume everything is 60Hz" nonsense that's going on now.

All other steps should be the same as before, so I should see by this afternoon if the issue is solved.

Overall I'm disappointed in the Xorg guys. There seems to be a lot of shortcuts going on in their code (modelines only use INT instead of REAL/FLOAT so everything gets rounded up to whole numbers, modelines just ignore refresh rates, no force vsync, half finished code, etc). And there also appears to be issues in SDL as well, where requesting modes from Xorg isn't working. Bugs everywhere!

Sloppy stuff. Although I guess, 99% of people just us flat panel monitors at 60Hz refresh these days. But they shouldn't have removed the ability for people to use custom modes. That's just not cricket.

elvis
20th October 2010, 04:41 PM
Nope, still a drama in 8.04. Much closer, but it appears the rounding up of the vertical refresh (from 59.629403 to 59.7) is enough to cause some ugly screen tearing. Fussy stuff!

BUT, the GenRes guys over on arcade controls have made yet another update. This time half the stuff needed to manually compile has been removed, which is massive. It looks like just a hack to XRandR itself, and everything is sorted.

So back to 10.04, and on with GenRes 0.11 testing.

FWIW, the GenRes guys are looking at porting their tool to Windows as well. They reckon it could be used with any Radeon card under Windows for perfect modelines (surpassing both the ArcadeVGA and Soft15Khz, both of which have a limit to how many modelines they can support due to a limitation in Windows).

GenRes's "switchres" tool creates modelines on the fly, applies them, and then deletes them when done. This removes the need for the system to store every single modeline in existence, as it only ever needs one or two in memory (one for your currently running game, and one for your frontend).

Looks like this could be a very cool project!

Brad
20th October 2010, 05:00 PM
I'd love it if they did port to windows. It'd be the best solution for sure I reckon!

Brad

elvis
20th October 2010, 06:46 PM
The "XRandR" program stands for "X Resize, Rotate and Reflect Extension". With "X" being the graphical system for Linux, UNIX and other stuff (it also works on Mac and Windows, but it's kinda pointless when they already have native GUIs).

XRandR started out as a way to easily rotate, mirror and span displays in X (previously you had to use Xinerama which was a pain in the arse to configure, or use manufacturer-specific tools that came with Nvidia or ATI drivers). They've extended it to pretty much do everything now, because it's a lot easier to call dynamic stuff through XRandR than the dark old days of Linux GUIs where everything had to be hard coded.

MAME now uses SDL as it's default core (SDL is an open source, portable media layer that handles input from keyboards and mice, and output to graphic displays, audio cards, etc). SDL talks to XRandR (and Windows) natively, and by the looks of it XRandR works on Windows too.

So putting that all together, that means whatever these guys get working in Linux, they *should* be able to port it over to Windows without too much drama. Good news for everyone who runs a MAME setup inside a real arcade machine!

The other good news is that his "switchres" wrapper script also understands other emulators. So theoretically that means not only popular stuff like Megadrive/SNES emulation to real RGB monitors, but also the MESS project which emulates literally hundreds of old systems (like the Sega SC-3000 (http://www.stickfreaks.com/sc3000h.php), which was my first computer ever!).

Good news for CRT lovers everywhere.

mamejay
21st October 2010, 12:37 PM
Hey Elvis,

How big would the basic Linux image and cabinet software be and would it be possible to just image/ghost it to a PC. I have a 400in1 box that has a faulty drive and just want something that works on an Arcade monitor? The motherboard is a Piii 1Ghz with SIS onboard video and AC97 sound. It think the current drive uses SNEKEY for the keyboard encoding done by the parallel port.

Obviously video and audio drivers would need to be added etc.
I really have never used Linux before so be kind. Would be good to get an image that I can just drop my roms and screenshots into and away I go.

Hewitson
8th January 2011, 02:11 PM
Hard to guess at the size, but I'm certain fitting it all onto one CD wouldn't be at all difficult. Rather than an image though, which would save everything including partition tables, etc, I would suggest simply compressing the filesystem into a bzipped tar and restoring it to a fresh partition with a rescue disk.

elvis
8th January 2011, 03:54 PM
The very bright young men responsible for "Switchres" (the 15KHz tool for Linux) are also developing a ready-to-roll Linux/MAME setup.

Check out the discussion on ArcadeControls:
http://forum.arcadecontrols.com/index.php?topic=106405.0

Or their dedicated site:
http://arcade.groovy.org/

Currently it's a LiveCD ISO (burn it to a CD and boot from there). Have a read through the docs and see how you go. If you run in to dramas, feel free to post here and I'll do my best to help.

mamejay
10th January 2011, 10:41 AM
Thanks for that Elvis!