OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - Arch Linux ARM support => Topic started by: danboid on November 01, 2015, 12:53:39 pm
-
All the effort I put into upgrading my Banana Pi to the latest ALARM kernel and figuring out how to cross-compile for the Zaurus recently has paid off as I'm proud to announce that I have MAME4ALL (http://chui.dcemu.co.uk/mame4all.html) running like a dream under Arch on my Zaurus so I can now carry a full arcades worth of games as well as a complete Linux box in my pocket!
To run MAME fullscreen under the console you need to install customised builds of both sdl and directfb. (https://www.oesf.org/forum/index.php?showtopic=34405)
There is a weird bug where sometimes mame4all doesn't find any of the ROMs. I've found that if you simply exit MAME, rename the roms folder to anything then rename it back to roms fixes it.
M4A compiled with only a few small changes to the Linux Makefile - the only addition I had to make was to add -lm onto the end of the LDFLAGS.
[size=]
INSTALLATION INSTRUCTIONS[/size]
* Download mame4all.gz, ungzip it and copy it into /usr/local/bin or /usr/bin on your Z and make sure its executable, which it likely already is.
* Make a directory called /mame4all/roms and copy some MAME4ALL (MAME 0.37b) compat. ROMs into it.
* If you're not using the patched sdl and directfb to enable a fullscreen display then you will need to export:
export SDL_VIDEO_FBCON_ROTATION=CW
Before you run M4A. If you want this env var exported on boot then you can add that line to /etc/profile
[size=]USAGE[/size]
Just run `mame4all` to start M4A. Use the arrow keys and ENTER to select and run ROMs whilst pushing TAB moves down one page through the ROM list.
Calendar/Sync key = Insert coin
ENTER = Player 1 start
CTRL = Button 1
ALT = Button 2
LEFT SHIFT = Button 3
CANCEL (ESC) = Return to the main menu
CTRL+C = Quit M4A
-
This is great, Dan!
Thanks for all the work and sharing it....
Will give it a try when I have some time....
-
I got Quake running on my Z today!
However, its not really playable yet as there seems to be an issue with directfb output under both SDL1 and 2 at both VGA and QVGA resolutions that causes the display to be 'cropped'. The screen is offset a number of pixels down and to the left as if it needs its top-right hand corner to be dragged back into the right position. The good news here is that QVGA directfb output is closer to working properly with SDL than SDL's QVGA output via fbcon.
The build of MAME4ALL I posted in the OP was compiled with directfb support but sadly neither SDL1 nor SDL2 in Arch have directfb support compiled in as standard so I've had to create custom directfb-enabled SDL packages. I have attached my directfb-enabled build of SDL1 (as used by MAME4ALL) to this post.
Note that to install the attached SDL package you will first need to uncompress the tarball to get the Arch .tar.xz package as well as uninstall your existing SDL and everything that depends on SDL like so:
pacman -Rcn sdl
After installing the attached SDL, you will be required to (re)install both sdl_mixer and directfb before you can run mame4all:
pacman -S sdl_mixer directfb
To get mame4all to use directfb at QVGA resolution, run the following before you start mame4all:
export SDL_VIDEODRIVER=directfb
export DFBARGS="force-windowed,layer-rotate=270,mode=240x320,scaled=320x240"
After we have directfb working correctly under MAME4ALL I'll release my SDL2 and Quake packages and update the OP in this thread to instruct users to replace sdl and use the directfb EVs from this post (or something like them) instead.
-
That's excellent news and great progress!
Keep us posted....
-
Here are some screenshots of what the MAME4ALL menu looks like at QVGA using SDL1 + directfb as well as what tyr-quake looks like at VGA using SDL2 and directfb.SDL2 has no support for fbcon output like SDL1 does. You can see they both suffer the same display problem.
-
Those pics were took under Linux 4.2.3. I've just tried with 3.11.3 but I get the same results.
-
Looking good....
Thanks again for sharing...
-
daal has had success with using directfb on the Zaurus before. I suspect he was using an older kernel when he got Descent and Flashback running on the Z but he may have encountered and fixed this issue before, with any luck!
I know directfb is something he wants to use himself so hopefully he'll have an easy fix for us. I've looked at the various directfb options and tried the ones I thought could help but the screenshots demonstrate the best directfb results I've managed so far.
-
daal has had success with using directfb on the Zaurus before. I suspect he was using an older kernel when he got Descent and Flashback running on the Z but he may have encountered and fixed this issue before, with any luck!
I know directfb is something he wants to use himself so hopefully he'll have an easy fix for us. I've looked at the various directfb options and tried the ones I thought could help but the screenshots demonstrate the best directfb results I've managed so far.
Hi Dan,
it is possible to get the window correctly aligned if you patch SDL.
You can also have the mouse orientation corrected by patching DirectFB.
If you are keen, try these patches. Keep in mind this is somewhat experimental and just a dirty hack that is confirmed working only with the versions mentioned below :
fix mouse orientation on DirectFB 1.4.11 : http://pastebin.com/kYr24M07 (http://pastebin.com/kYr24M07)
fix qvga/vga alignment with SDL 1.2.14 and the DirectFB backend : http://pastebin.com/3CRrsGJb (http://pastebin.com/3CRrsGJb)
The SDL patch allows you to center the frame by setting :
SDL_VIDEO_DIRECTFB_POS=qvga
SDL_VIDEO_DIRECTFB_POS=vga
or place the frame at the top left corner by setting :
SDL_VIDEO_DIRECTFB_POS=topleftCheers!
-
Hi daal
It looks to me like you'll have to rewrite your SDL directfb patch. It would not apply to SDL 1.2.14, 1.2.15 or 1.2.13 so I attempted to do the patch manually but it appears to be patching an already patched file in that the diff references (tries to remove) functions and variables that are not present in the original version of the source file in all of those three releases. Also the line numbers for the bits I found that matched for version 1.2.14 are quite different to what the patch is expecting.
I'm glad to hear you have fixed ths problem before, at least with SDL1 as this should fix my problem with the video output under MAME4ALL being too small. I expect we'll need a separate patch for SDL2 to fix the same issue so that we can get Quake running properly.
Did you ever try getting your directfb patch merged upstream? It's prob too late for SDL1 now but if you manage to fix it for SDL2 then maybe that could be upstreamed? On the otherhand maybe this is a Z-specific issue?
On a related note, I was excited that I got PCSX-ReARMed (a ARM-optimized PlayStation emulator) to compile for the Z yesterday but unfortunately its currently unusable because the Z lacks any kind of hardware video scaling:
https://boards.openpandora.org/topic/560022...rus-arch-linux/ (https://boards.openpandora.org/topic/5600227-pcsx-rearmed-under-zaurus-arch-linux/)
-
Here's the PKGBUILD I used to create the SDL package above:
https://gist.github.com/danboid/4c0a28f286a33af0bd7f (https://gist.github.com/danboid/4c0a28f286a33af0bd7f)
I don't think --enable-video-directfb is really needed so long as directfb is installed at build time and nor do I think --build=armv5tel-unknown-linux-gnueabi is required unless you're compiling with distcc, maybe, but I didn't think it could cause any harm to have it in there.
If you're creating a new separate SDL package then you'll want to change the name of this package to sdl-dfb or whatever and add:
conflicts=('sdl')
I believe, daal, but I expect that's nothing you didn't already know.
Mr daal hopes to fix our SDL directfb and pointer-related woes in the next couple of weeks when he finds the time.
-
Here's the PKGBUILD I used to create the SDL package above:
https://gist.github.com/danboid/4c0a28f286a33af0bd7f (https://gist.github.com/danboid/4c0a28f286a33af0bd7f)
I don't think --enable-video-directfb is really needed so long as directfb is installed at build time and nor do I think --build=armv5tel-unknown-linux-gnueabi is required unless you're compiling with distcc, maybe, but I didn't think it could cause any harm to have it in there.
If you're creating a new separate SDL package then you'll want to change the name of this package to sdl-dfb or whatever and add:
conflicts=('sdl')
I believe, daal, but I expect that's nothing you didn't already know.
Mr daal hopes to fix our SDL directfb and pointer-related woes in the next couple of weeks when he finds the time.
I had a look at the SDL 1.2.14 and SDL 1.2.15 code at libsdl.org.
It seems the code for directfb has changed significantly since my 1.2.14 svn checkout few years back.
The patches will need to be rewritten and tested with SDL 1.2.15 and I do not have time for this currently.
I will look into this further once I find some time, maybe in later this month or in December.
So, I have attached my patched DirectFB 1.4.11 and SDL 1.2.14 source, this should help to get you going in the meantime.
These sources should still compile fine, fingers crossed.
-
I thought SDL deserved its own thread now we have packages:
https://www.oesf.org/forum/index.php?showtopic=34405 (https://www.oesf.org/forum/index.php?showtopic=34405)
The display is aligned correctly using the patched SDL package but I've not been able to get the keyboard to work under MAME4ALL / directfb. If it does work it inputs to a terminal displayed behind the MAME 'window' but all the options I've tried (using the no-vt options, disabling spawning a new VT, disabling transparency, grabbing the input devices, setting the input devices manually in directfbrc...) failed to get the keyboard to work with MAME.
-
You can now play MAME4ALL fullscreen if you installl the customised ALARMZ packages for SDL and directfb!
The OP has been updated with the details.
-
Well done, Dan!!