MAME4ALL fail to compile


15 posts
by zup » Sun Jun 24, 2012 5:51 pm
I'm trying to make MAME work in my Raspberry, and I've chosen mame4all to start with. So far, I've taken these steps:

- Downloaded and unpacked the sources from Chui's DC projects (as there is a makefile for linux).
- Altered makefile.linux: I've defined CC, CXX, LD and AS as arm-linux-gnueabihf-g++ (in makefile.gp2x are defined in a similar manner), defined CZ80=1 and commented all lines with references to raze and fame (to avoid asm in Z80 and M68000 cores).
- Altered config.mk: Commented the lines that define M68000_ASM_CORE and Z80_ASM_CORE (same reason).

It starts to compile, but when linking it shows failures in bosco.cpp, mrdo.cpp, gorf.cpp, mpatrol.cpp, 1943.cpp and blktiger.cpp. All those failures reference Z80 functions (Z80_GetHL2, Z80_GetHL, Z80_GetE and those things).

I've commented those lines and avoided use of asm to force only C code, but it seems that I've messed something with Z80 core. Anyone knows how can I fix that?
Posts: 17
Joined: Sun Jun 24, 2012 5:28 pm
by dom » Sun Jun 24, 2012 6:24 pm
Have you seen this:
viewtopic.php?f=35&t=6750

I believe mame4all runs quite well there.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4013
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by zup » Mon Jun 25, 2012 7:12 am
Sorry, but I wanted a standalone MAME, and retroarch seems to be "overkill".

BTW, (almost) the same settings compile fine in a Debian 6.0 AMD x64 (but it shows a segfault when loading roms).
Posts: 17
Joined: Sun Jun 24, 2012 5:28 pm
by zup » Fri Jun 29, 2012 5:17 pm
OK, now it's done. Messing with some compile options, I've managed to get a mame4all executable that works.

I've checked some roms and it seems to work faster than xmame-sdl 0.106 (also, I've managed to compile it from the Debian sources). Now, I have two problems:

- It seems that mame4all uses only buttons present in GP2X or PSP (A button, X button, Volume up, those things). I don't know how are they mapped to linux keyboard (and I haven't found any documentation about it).

- Also, USB joystick doesn't work.

Probably, I'm missing some configuration options, but I have no idea about that (if anyone is interested in the executable, I'll upload and post it).
Posts: 17
Joined: Sun Jun 24, 2012 5:28 pm
by mpthompson » Fri Jun 29, 2012 6:57 pm
zup wrote:- Also, USB joystick doesn't work.


Great job on getting a version of MAME working. That may be something I have to look at myself.

Regarding a USB joystick, it doesn't surprise me that the kernel leaves out the USB joystick drivers at this point. You may want to give the Raspbian alpha kernel by plugwash a try as described in this thread:

viewtopic.php?f=66&t=9486

If the joystick drivers aren't present, you can ask plugwash to enable them when he revs a future version of the kernel.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by zup » Fri Jun 29, 2012 8:33 pm
No, the joysticks are working (tested with fuse-sdl).

I've been talking with the author. mame4all is targeted for GP2X, Dreamcast and PSP, so they're not interested in Linux or Windows builds (they only use that builds for speeding up the development process) and they have not documented options nor keys.

The mappings are as follows:

Return --> START
LCTRL --> A button
LALT --> X button
Space --> Y button
LShift --> B button
Tab --> R button
Backspace --> L button
Left, right, up, down --> Joystick directions
F1 --> Select
F11 --> Volume up
F12 --> Volume Down
Escape --> Push?
F10 --> Toggle fullscreen

Also, there are another functions related to joystick but it seems that only compile when using PSP or Dreamcast. I guess some of that funcions can be activated to get USB joystick inputs.
Posts: 17
Joined: Sun Jun 24, 2012 5:28 pm
by 27feet » Fri Jun 29, 2012 9:26 pm
How about building your own control pad and using the GPIO ports to trigger the keyboard signals?

You can source arcade buttons and sticks from all sorts of places (google "arcade parts" - I can recommend a supplier I've used before but guess it's against forum rules). You'd probably need to debounce the switches but that's electronics 101
Posts: 10
Joined: Fri Jun 01, 2012 4:49 pm
by zup » Sun Jul 01, 2012 10:24 am
I've managed to modify mame4all to use USB joysticks, although I haven't changed key mappings (but it's very easy). Because mame4all was done for PSP / GP2X / Dreamcast, it seems that only support digital joysticks with 11 buttons (no matter if your USB joystick is analog, analog readings are converted to digital inputs). I guess that 11 buttons are enough for every machine, so I'll stick with that. Also, some of those buttons are reserved for coins and start, so only 8 buttons are available for arcade.

Keep in mind that I've done some quick and dirty hacks, I'm not a mame developer (and I haven't done any programming in years) so I don't know if I could be able to make mame4all (or SDL) read GPIO inputs (in a reasonable time).

I've found some problems with drz80 core (in some games z80 hangs, so far the games that hangs use Z80 as main CPU but haven't found problems when Z80 is used as a slave CPU), so I've compiled two versions. The first one has both drz80 and cyclone asm cores, and performs way faster than xmame-sdl 0.106; the second version uses z80 C core and cyclone asm core.

Also, in my first compilations mame4all used a 320x240 resolution (and it seemed to work well), but in my latest compilations my TV shows mame4all with a black border around the screen (using 640x480). I wonder it it does the same with composite video.

So far, the only changes needed would be:
- Changing the keyboard layout to match MAME default (or regroup the keys).
- Changing the resolution to 640x480 (so every monitor o TV show fullscreen without borders).
- Using some kind of acceleration.
- Using GPIO to read joysticks.

The first change is eaaaaasy, but I'm laaaaazy. The second one could be harder, mostly because I'd had to read SDL to check how to make the scaling.

The third one is hard to me, because it would involve using GLES to scale the screen (and I don't know anything about GLES). There is a version (imame4all) that already uses GLES for acceleration (and the author states that it performs better), so maybe someone could make a patch for making it work.

The last one is beyond my scope, I'm afraid (unless SDL treats those GPIO inputs as keyboard or joystick inputs... those routines are already present).
Posts: 17
Joined: Sun Jun 24, 2012 5:28 pm
by dom » Sun Jul 01, 2012 10:53 am
zup wrote:The third one is hard to me, because it would involve using GLES to scale the screen (and I don't know anything about GLES). There is a version (imame4all) that already uses GLES for acceleration (and the author states that it performs better), so maybe someone could make a patch for making it work.


There's no need to use GLES for scaling. Just make sure SDL_SetVideoMode has the required dimensions and the GPU will scale that size to fill the screen.
(If GLES can do other effects in addition to scaling it may be worth using, but will certainly be slower than the "free" scaling)
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4013
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by zup » Sun Jul 01, 2012 2:18 pm
dom wrote:There's no need to use GLES for scaling. Just make sure SDL_SetVideoMode has the required dimensions and the GPU will scale that size to fill the screen.
(If GLES can do other effects in addition to scaling it may be worth using, but will certainly be slower than the "free" scaling)


I thought that SDL will try to do software scaling (hardware scaling is not available in framebuffer, directfb or X11), so using GLES to do some hardware scaling seemed logical. I will try to compile 640x480 executable to check if it is done automatically (and change keyboard layout).
Posts: 17
Joined: Sun Jun 24, 2012 5:28 pm
by dom » Sun Jul 01, 2012 2:45 pm
zup wrote:I thought that SDL will try to do software scaling (hardware scaling is not available in framebuffer, directfb or X11), so using GLES to do some hardware scaling seemed logical. I will try to compile 640x480 executable to check if it is done automatically (and change keyboard layout).


SDL inside X, yes. SDL without X, then the framebuffer will be scaled by GPU. See here:
viewtopic.php?f=35&t=9583&p=112992

I've just debugged that and I can confirm that a 640x480x8bpp framebuffer is directly given to GPU, and the palette lookup and scaling to 1920x1080 is done by the hardware.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4013
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by zup » Sat Jul 21, 2012 7:13 pm
Finally, I managed to get a working mame4all (but still with some bugs). I've made a patch to update Chui's mame4all source code, and some binaries for Raspbian.

Also, I've made an article explaining some things about the compilation process and some instructions (in spanish).

Compiling mame4all:
    -It compiles in Raspbian (use HARDFLOAT=1 in Makefile.pi), but is not tested in Debian (please someone compile it and tell me if it works).
    -There are two binaries: mame4all and mame4all.drz80 (if you use the RASPBERRY_DRZ80=1 directive). The later binary uses an asm Z80 core that makes it faster, but also unstable (some games may fail). I suggest keeping BOTH binaries so you can choose.

Using mame4all:
- Mame4all is an SDL application, so it can be run from console or X.
- Mame4all expects that roms are into a roms folder in the same folder where the binary is located.
- To select a game use Up/down and Enter. Use Esc to go back.
- To insert coins, use F1 to F4 keys.
- To start a game, you can use 1 to 4 keys. Enter serves as player 1 start.
- Player 1 can use keyboard or the first joystick.
- Player 1 can move using the cursors. The buttons are Z to V keys, and A to F keys.

Known bugs:
    - The sound has bad quality, and I don't know how to fix it.
    - Mame4all uses a 320x240 "window" and tries to get that video mode. If it is not available, SDL will choose the next bigger video mode, but it won't scale the graphics (so you will get a 320x240 windows with a black frame). I don't know how to fix it.
    - 4 joysticks are supported, but the first one is mapped to the first player. Two players will need two joysticks (playing using a keyboard and only a joystick is not possible).
Posts: 17
Joined: Sun Jun 24, 2012 5:28 pm
by crookedmouth » Sun Oct 28, 2012 1:47 pm
Mame4all runs quite a bit faster then advancemame, thank you for compiling and posting the binaries. I love the built-in gui of mame4all. If only it ran full-screen.
User avatar
Posts: 66
Joined: Tue Sep 18, 2012 1:13 am
by mikie » Tue Nov 27, 2012 11:07 pm
Hi,

I've just tried the binaries but just get an unrecoverable blank screen (composite output). Neither Ctrl-C or ESC (or anything else it seems) gets me back to the command prompt (apart from a power cycle). Would you know what's causing this?

Also, would it be possible to post a more detailed sequence of how to compile mame4all? I tried to compile it but it bombed out after a while with the error "SDL_mixer.h: No such file or directory".

Your help would be appreciated! Thanks :D
Posts: 7
Joined: Sun Oct 09, 2011 3:36 am
by JF002 » Sun Dec 09, 2012 7:02 pm
I'm compiling mame4all right now.

I had the same error. I assume that the following command line would fix it:
Code: Select all
sudo apt-get install sdl-mixer1.2-dev
My blog [FR] : http://blog.slashome.fr.cr
Posts: 80
Joined: Sat Feb 04, 2012 8:49 am