OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio


Welcome Guest ( Log In | Register )

Personal Photo
Personal Statement
danboid doesn't have a personal statement currently.
Personal Info
35 years old
Gender Not Set
Born Jan-4-1981
No Information
Joined: 26-December 05
Profile Views: 7,104*
Last Seen: 24th January 2016 - 01:12 PM
Local Time: Oct 24 2016, 10:37 AM
886 posts (0 per day)
Contact Information
AIM No Information
Yahoo No Information
ICQ No Information
MSN No Information
Contact Private
* Profile views updated each hour



My Content
10 Nov 2015
Install alsa-utils if its not already installed:

pacman -S alsa-utils

Then run alsamixer and use the arrow keys to find the channels called 'Left Mixer' and 'Left Mixer Right'. Highlight both one at a time and push the 'm' key to unmute each channel. You'll notice the two M's in each channel turn to green zeros to indicate they're unmuted. You can now push ESC (or Cancel on the Z) to quit alsamixer and run:

alsactl store 0

To save your alsamixer (audio) settings so they will be restored on the next boot.
8 Nov 2015
There are two main reasons you may need to use SDL's directfb output. You may want to run an SDL2 program from the console or you may wish to run an SDL program such as an emulator or a game at QVGA resolution from the console. SDL1 supports fbcon output but fbcon output has been dropped from SDL2 where directfb is your only real option for displaying graphics outside of X. QVGA fbcon output doesn't seem to work for SDL1 under recent kernels. To make matters more complicated, both the SDL1 and SDL2 packages in the ALARM repositories don't include directfb support and even if you do build SDL yourself with directfb enabled (without using the patched PKGBUILD below) it still won't work properly because the display isn't aligned for the Zaurus' display and your pointers orientation will be skewed using the directfb version currently in the ALARM repos, directfb 1.7.7.

Thankfully forum member daalnroti patched the directfb code of SDL 1.2.14 so that we can use directfb and see the full screen and he also patched directfb so that you can use a pointer device correctly up/down will be up/down instead of left/right. I have built ALARM packages and PKGBUILD tarballs that integrate these patches to simplify the install process.

So far we only have the previous stable release of SDL1 (1.2.14) patched so that the directfb display works properly and an older directfb with the pointer patch applied. SDL2 apps will suffer from a misaligned display until we have a similar patch for SDL2. daal's original directfb patch was for directfb 1.4.11 but it still applied cleanly to 1.4.16 which was the oldest version I could get to build under Arch. I have not yet looked into if this patch works under the latest directfb but its a very small patch so it should be trivial to update it if required.

The SDL package here was built against the directfb 1.4.16 package below.

Installing sdl and directfb

To install the attached packages you will first need to uncompress their tarballs to get the Arch .tar.xz package as well as uninstall your existing SDL and everything that depends on SDL (if you've already installed SDL1 from the ALARM repo) like so:

pacman -Rcn sdl

After installing the attached sdl and directfb packages, you will need to add both 'sdl' and 'directfb' to your IgnorePkg statement in /etc/pacman.conf. Don't forget to uncomment the IgnorePkg line as it's commented out by default!

Configuring sdl and directfb

If you wanted directfb to default to QVGA, you would create an /etc/directfbrc file like this:


You can also temporarily switch DFB settings by exporting them in a comma separated list to DFBARGS by running a command like this:
export DFBARGS="force-windowed,layer-rotate=270,mode=240x320,no-vt-switch"

Note that layer-rotate is required to use directfb in landscape display mode and it doesn't work without the force-windowed option.

You need to export your choice of video driver othewise SDL1 defaults to fbcon output:

export SDL_VIDEODRIVER=directfb

Finally you also need to export one of the following EVs to correct the displays offset:


If you want any of these exported automatically on boot, add them to /etc/profile .
Attached File(s)
Attached File  sdl_1.2.14_directfb_PKGBUILD.tar.gz ( 20.9K ) Number of downloads: 4
Attached File  directfb_1.4.16_ALARMZ_PKGBUILD.tar.gz ( 1.04K ) Number of downloads: 2
Attached File  sdl_1.2.14_directfb_ALARMZ.tar.gz ( 320.66K ) Number of downloads: 3
Attached File  directfb_1.4.16_ALARMZ.tar.gz ( 568.67K ) Number of downloads: 3
5 Nov 2015
I'm sure this was mentioned deep in one of the threads here somewhere but I thought I'd highlight it by giving the IRC channel its own thread because up until now its only been daal and I using it.

Fire up weechat or your IRC client of choice and come and discuss why running ALARM on a Z is the best retro pocket computing experience a man can have, or something, soon!

#ALARMZ on irc.freenode.net

1 Nov 2015
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 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.

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.


* 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:


Before you run M4A. If you want this env var exported on boot then you can add that line to /etc/profile


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

Attached File(s)
Attached File  mame4all.gz ( 1.82MB ) Number of downloads: 6
31 Oct 2015
Over a decade after its launch, the Zaurus is still a useful pocket computer but its 64MB RAM limitation can be restrictive, especially when it comes to building large programs. The Zaurus simply doesn't have enough RAM to compile some large source files and it just enters 'swap hell' when it gets overwhelmed. On top of this, the Zaurus is slow to compile programs it can manage so it can be a huge time saver to get a cross-compilation environment set up which enables you to utilize more powerful machines to accelerate or simply enable the building of complex software.

The cross compilaion method recommended by the ALARM developers and ultimately the fastest way to cross compile software is to use distcc. In most cases you should try setting up distcc by following the ALARM developer distcc guides first before you resort to the ARM cross compiling method described here.



To use this guide you need to be familar with the Arch package management tools and you need an ARM-based computer running ALARM that has superior specs to the Zaurus and internet connectivity so that it can download development packages. If you don't already own a modern ARM computer and you're on a tight budget then I can highly recommend the Banana Pi, which is about the same price as the RPi2 but with SATA2 and gigabit ethernet. It's not officially supported by ALARM, like the Zaurus, but also like the Z it runs ALARM very well nonetheless. If you have more money to spend you might want to check out something like the Odroid XU4 which has 2GB RAM, a faster CPU and USB3. Check out http://archlinuxarm.org for a list of supported platforms.

The key bit of software used in this guide is arch-chroot which is part of the arch-install-scripts package. I have only tested chrooting from an Arch armv7 userland into an Arch armv5 but you could probably run arch-chroot under another modern ARM Linux distro that uses systemd and get the same results. To keep things simple it is recommended you stick to ALARM for the host OS but I'm interested to hear from anyone who tries this under a non Arch-based ARM Linux distro. This guide should work for machnes running armv6h and aarch64 too.

First you need to download and extract the ALARMv5 rootfs:

$ wget http://archlinuxarm.org/os/ArchLinuxARM-armv5-latest.tar.gz
$ mkdir ~/ALARMv5
# bsdtar xvf ArchLinuxARM-armv5-latest.tar.gz -C ~/ALARMv5

Note that the extraction of the rootfs (the bsdtar command) needs to be done as root to preserve the files users and permissions but otherwise you can extract it where you wish.

Presuming that the host machine is connected to the internet, copy the host machines resolv.conf into /etc of the chroot fs:

# cp /etc/resolv.conf ~/ALARMv5/etc

You should now be able to chroot into the ALARMv5 rootfs:

# arch-chroot ~/ALARMv5

Now you're logged into the chroot, you can build Arch packages just as you normally would but there are two main things you should check when configuring an Arch package for cross compilation.

First you need to check the 'arch' statement in the PKGBUILD script for the package you are building includes 'arm'. If it doesn't then add it in so that the arch line looks like:

arch=('i686' 'x86_64' 'arm')

If the package you are building uses autoconf with a configure script then you need to add the correct --build switch option to the ./configure statement within the build() function of the PKGBUILD script to make sure the compiler builds for armv5 instead of armv7 or whatever platform your host is running. It will look something like this after modification:

build() {
  cd $srcdir/$pkgname-$pkgver
  ./configure --prefix=/usr --build=armv5tel-unknown-linux-gnueabi || return 1
  make || return 1

You might have to do some investigation to work out how to tell your app to build for armv5tel-unknown-linux-gnueabi if it doesn't use autoconf. You can often set the arch to build for by exporting it as an environment variable but I wouldn't worry too much about trying to specify the target build arch as in most cases the resultant packages will work regardless.

Providing you have enough disk space I would recommend you install your packages under the chroot after they have finished building. Not only does ths act as a test of ther validity but it is a backup too should you quit out of the chroot before backing the package up.

makepkg, packer and pacaur etc store the finished package under /tmp directory. packer for example stores its packages under /tmp/packerbuild-0/$PKGNAME/$PKGNAME where $PKGNAME is the name of the package you built. Make sure you copy the package out of the /tmp dir of the chroot after building and before you exit the chroot because everything under /tmp gets deleted as soon as you exit the chroot, which you do by typing 'exit' or hitting CTRL+D.

If you do ever need to create an Arch package from one that was previously installed but for which the package no longer exists (for example if you quit out of the chroot before copying the package out of /tmp) then you can use bacman to create the package, which comes as standard with pacman. Using it is as simple as running:

$ bacman packagename
Last Visitors

30 Sep 2016 - 7:39

6 Nov 2015 - 19:52

1 Nov 2015 - 0:08

19 Oct 2015 - 13:46

10 Sep 2012 - 10:37

Other users have left no comments for danboid.

There are no friends to display.
RSS Lo-Fi Version Time is now: 24th October 2016 - 02:37 AM