Note: This section is not a Unix tutorial. You need to know some basic Unix commands to compile and install xmame/xmess.
GNU make is MANDATORY in ALL Systems, even if you use a different compiler.
On all platforms zlib is now needed since the core uses it. If you don't have zlib, a stripped version is included with xmame. See: FAQ: Why do I get gz_open symbol not while compiling? and FAQ: Why do I get zlib.h not found?
You are encouraged to use a GNU development environment: gcc, gmake, GNU ar. Lots of problems are found due to the very permissive syntax in gcc, so if you use a strictly ANSI C compiler, you'll get lots of warnings, and if the version of xmame/xmess is not fully debugged, compilation errors.
Xmame compilation breaks when using egcs-1.1.x or gcc-2.95, use -fno-strict-aliasing to fix it. gcc-2.95.1 does work with -fstrict-aliasing, and gives a nice speed increase.
Xmame compilation also breaks when using Red Hat 7's latest (as of 16 January 2001) update for gcc. If you experience problems, please either downgrade your compiler to the one included on the Red Hat 7 CD-ROM, or try replacing “gcc” in the Makefile with “kgcc”, which will invoke egcs-1.1.2. (But please see above about the -fstrict-aliasing flag.)
See Compile Notes for Specific Operating Systems for platform specific compiling information.
See Display subsystem specific comments and notes for special display methods information.
Download the xmame/xmess source files archive.
Move the xmame/xmess source files archive to a suitable work directory. When you extract the archive, sub directories will be created under the work directory.
Use bzcat and tar to decompress the archive. For example:
bzcat xmame-0.81.1.tar.bz2 | tar xv |
There are other ways to extract the archive, such as the great “atool” script.
After extracting the archive, change to the subdirectory created by the extraction process. For example, after extracting the xmame-0.81.1.tar.bz2 archive, a directory named xmame-0.81.1 is created; change to it. This directory is the top of the source tree.
Edit the Makefile (a link to makefile.unix) and change the settings according to your system. The default makefile.unix is preconfigured to run under X11/Linux. Be careful when you edit this file.
If you intend to compile in X11 joystick support, type the following to see the available Xdevice list:
make xlistdev; ./xlistdev |
Choose the desired device and re-edit Makefile, setting the option X11_JOYNAME to the correct device.
Compile xmame/xmess by typing:
make |
If the compile fails, report the problem to the author.
*** YOU MAY NEED TO BE root TO PERFORM THIS STEP *** To install xmame/xmess, type:
make install |
If you want you can now build xmame/xmess for another target/display method, otherwise skip to the next step.
If you want to also build for another target repeat repeat the “make” and “make install” steps adding “TARGET=<target>” to the make command for example:
make TARGET=mess make install |
If you want to also build for another display method repeat the “make” and “make install” steps adding “DISPLAY_METHOD=<method>” to the make command for example:
make DISPLAY_METHOD=svgalib make install |
You can also combine the 2 above for example:
make TARGET=mess DISPLAY_METHOD=svgalib make install |
In your home directory, create a subdirectory called .xmame.
From the top of the source tree, copy the file doc/xmamerc.dist to the ${HOME}/.xmame/ directory. (For xmess do this for xmessrc)
If desired, copy xmamerc.dist to the global xmamerc location as "xmamerc" (for xmess, copy xmamerc.dist to xmessrc). The global xmamerc location is defined in the Makefile.
Edit ${HOME}/.xmame/xmamerc to match your preferences. (For xmess, edit ${HOME}/.xmess/xmessrc)
Be sure that the DISPLAY and PATH environment variables are set correctly.
Make sure your ROM images are installed.
Start the X-Window System. (Unless you compiled for a different display method in which case you skip this step.)
Start xmame/xmess. For example:
/usr/local/bin/xmame.x11 dkong |
Read (the recent parts of) Changelogs. They might contain some hints about recent changes which aren't fully documented yet.
Check Compile Notes for Specific Operating Systems for operating system-specific notes. You may need to do something special for your operating system.
Check Display subsystem specific comments and notes for display subsystem-specific notes. You may need to do something special for your display system.
If you get an error about gz_open and a bunch of other functions not found during linking, read: FAQ: Why do I get gz_open symbol not while compiling? and FAQ: Why do I get zlib.h not found?.
Be sure that the rompath in your xmamerc/xmessrc is correct; see FAQ: Where do roms.images.etc go?.
Check xmamerc/xmessrc: Is it configured correctly?
Are you getting messages that you are missing files? Maybe you are missing PROMs; see FAQ: Why doesn't a game work? and FAQ: What are PROMs?
Is the program in your PATH?
The svgalib/xf86_dga build of xmame/xmess requires setuid root. Are your permissions correct?
Try asking the friendly folks at the newsgroup alt.game.mame to see if anyone else has experienced the same problem as you.
Try mailing to the xmame mailinglist, see Mail for more information.
If all else fails, send email to the current maintainer of the xmame/xmess project. See Mail for contact information.
Linux i386 is the platform I (Hans) use, so xmame should compile without any hassles on Linux i386. (Note: The same is true for Lawrence Gold.)
Some bugs have been found and worked around when using gcc27x, please use egcs if available. If more gcc bugs popup, egcs will be made mandatory, but I hope that won't be necessary.
It has been reported that some SoundBlaster AWE32 and VIA-82cxxx (onboard) cards do not correctly manage get_freespace(). If so, you'll get some audio_ioctl() calls failed messages in console, and if everything goes right a message that xmame/xmess is falling back to timer based audio. If this doesn't happen and sound isn't right, try forcing timer-based audio by starting xmame/xmess with -timer.
SB64/128PCI cards (Ensoniq 137x-based cards) also do not correctly manage get_freespace(). Unfortunately, this doesn't result in failed ioctl's; instead, they just ignore the calls. Xmame tries to autodetect this and to fall back to timer-based audio. If this doesn't happen and sound isn't right, try forcing timer based audio by starting xmame/xmess with -timer.
Some have reported success using ALSA with OSS emulation (see http://www.alsa-project.org/). If you experience the above problems, this would certainly be worth a try.
Also, I've tested sound using the PC-Speaker driver module. It works!! But it needs -timer. Again, it should do this automagically, but you know what to do if it doesn't.
Distribution-Specific Comments:
S.u.S.E. Linux: Besides the gcc compiler and libc libraries, which are both from the "d" series, other packages need to be installed or the build will fail. If compiling for svgalib, the svgalib package from series "d" installed. If compiling for the X-Window System, you must have xdevel package from series "x" installed. These packages can be installed using the "yast" utility included in the S.u.S.E. distribution.
Red Hat Linux is the operating system used by the author. xmame/xmess should build correctly under Red Hat Linux. :-)
Linux PowerPC should work from now on. Here's an email from Andreas Varga sid@skater.htu.tuwien.ac.at, the Linux/PowerPC maintainer, describing the necessary steps:
Required changes to compile xmame 0.34b3.1 on Linux/PowerPC with SVGALIB
Makefile:
enable CFLAGS for linux/ppc
enable DISPLAY_METHOD = svgalib
enable ARCH = linux
remove -lvgagl from LIBS.svgalib in src/unix/unix.mak (only -lvga is required)
Required changes to compile xmame 0.34b3.1 on Linux/PowerPC with X11
Makefile:
enable CFLAGS for linux/ppc
enable DISPLAY_METHOD = x11
enable ARCH = linux
Another thing... sound is not working, because sound drivers support is currently under development in Linux/PPC kernels...there is an old driver that is a hacked Soundblaster driver, and newer 2.1.1xx kernels have a sound drivers based on Amiga DMA sound drivers... Once this issues are settled there should be a full OSS-compatible driver... sound should work then...
I can't speak about Joystick support...
The original Linux/PPC target changes in the Makefile were done by me, but there are some other changes required to get it to compile... Starting from October I will have some more time to work on this, and I'll keep you updated...
Cheers, Andreas
Use the generic unix arch for those machines that have no sound support installed (xmame/xmess uses the dmedia package or the newer AL package on IRIX systems).
Silicon Graphics provides several native compilers. xmame/xmess has been compiled and tested with the normal cc. There were some problems with this when using -n32 for new style 32bit code. It does work when using -o32 for oldstyle 32 bit code. It should now also work with -n32 which is much faster.
The use of DCC is not recommended (anymore) since it's a C++ compiler and thus won't even compile xmame/xmess out of the box due to uncasted mallocs. Changing all these mallocs would be crazy, esp. since they are not only in the osd part, but also in the core which is not under our control. Besides that, mame is normal C, so please compile it with a normal C compiler.
Some problems have been reported using the GNU linker. It's recommended that you use the native one.
Use the generic unix arch.
Notes received from Danny dboxhoor@iso.vilspa.esa.es
VERY IMPORTANT!!!
The xmame/xmess CPU emulators access memory through pointers which are sometimes cast to illegal addresses - as far as the MIPS CPU is concerned. The Ultrix operating system is aware of that and fixes this "unaligned data access".
Depending on your system setup, lots of warnings are generated for certain games. Fortunately these messages can be disabled by executing the command "uac p 0" in the same shell where xmame/xmess will be running.
UPDATE: The new -DALIGN_INTS switch in the makefile fixes these unaligned accesses in the source which is probably a lot faster than hot fixing them in the kernel segfault handler.
Use gnu make.
Compile with the `c89' compiler. Though `gcc' has no problems with compiling and optimizing xmame/xmess, the resulting `c89' executable is faster on an empty machine (read: xmame can use all cpu & memory without competing with other high priority processes), so you can set `frameskip' to 1.
When compiling with `c89 -O2' don't forget to also use `-Olimit 1000'. If 1000 is not enough, the compiler will tell you to increase it.
There are 2 relevant architecture options available in the makefile:
ARCH = generic : use this for old SunOs running on Sparcs, but a Sparc running Solaris will usually handle this option too. ARCH = solaris : this is the one you should use for Sparcs running Solaris. |
Currently sound is not supported under sunos. The solaris arch does support audio.
If you are using Sun's OpenWindows implementation of X11, then make sure that the X11INC and X11LIB variables in the X11 Options section of the makefile are set properly. (There are already entries for the standard OpenWin directory there that you can uncomment.)
Of course, if you are compiling for X11 then you need to set these variables properly, no matter what implementation of X11 you are using! :)
If you are using Sun's SunPro cc compiler, then the following optimisation flags have been reported to be good:
OPTFLAGS = -fast -xO4 -native |
Finally, there has been a case of the xmame compilation processes breaking over the "ar" program. Most Solaris installations will include a set of utilities that conform to the XPG4 standard, usually in the "/usr/xpg4/bin" directory. The XPG4 version of "ar" should be avoided like the plague. Ensure that the "/usr/ccs/bin" appears in your path before the "/usr/xpg4/bin" directory and everything should go smoothly.
PLEASE NOTE : There is currently not much support for SunOS/Solaris. If you have any trouble, try to fix it yourself. If you succeed, send a message to the mailing list detailing what you did. If you don't succeed, send a message anyway and someone _may_ be able to help you. Either way, this is the only way that problems with xmame on SunOS/Solaris will get fixed.
You must use the OpenStep gnumake, not make. You must also use the NeXT/Apple cc rather than gcc. Also use only the optimisation options as recommended for OpenStep in the makefile, others will cause the resulting executable to crash. The OpenStep assembler on i386 architectures is incompatible with the mame assembler CPU cores and thus you must use the C versions (Use i386-noasm instead of i386 when compiling for i386).
The supplied complier is based on gcc 2.7.2.1 which will not compile src/profiler.c without crashing. To get around this you must turn off + optimisation when this crash occurs, re-make to compile this file only, then stop the make, re-enable optimisation, and continue.
On an OpenStep keyboard the functions keys do not all operate as expected. Using the command key in conjuction with a number key generates the equivalent function key within xmame, with 0, - and = + representing F10, F11 and F12 resepectively. Also note that the ALT + keys cannot be mapped. As most games tend to use this as the default fire button it is exteremly useful to remap this globally the first time you run xmame.