2013-10-13

odroid-wheezy-retro 0.8.2 released: kernel 3.8 and updates

With this release I am proud to announce that 3.8.11 is stable enough for our retro-gaming purposes, thus it has been integrated in my retro image.


 
  • now using hardkernel official 3.8.13.10 linux kernel
  • fixed support of Hardkernel upgrade script
  • added MFC firmware (s5p-mfc.fw)
  • supports XBMC (not included)
  • most recent Debian 7.1 packages
  • default partition size is now 2G
  • most recent RetroArch + cores
  • fixed bug with network at 1st boot

2013-09-08

Let's play X-COM on the ODROID U2

One of the classic games I always dreamt to play again (on bigger screens, with huge blocky pixels) is the original X-COM: Enemy Unknown (a.k.a. Ufo Defense).


Not many of them survived every time I played this game


Spoiler: Enemy Unknown works fine on our beloved U2s thanks to OpenXcom :)

I will explain here how to get it running in a few steps. You will need some patience and the original X-COM 1 game. See also OpenXcom's README.

Installing yaml 0.5 packages


You will need slightly more recent yaml packages than those provided with Debian Wheezy.

wget http://ftp.debian.org/debian/pool/main/y/yaml-cpp/libyaml-cpp-dev_0.5.1-1_armhf.deb
wget http://ftp.debian.org/debian/pool/main/y/yaml-cpp/libyaml-cpp0.5_0.5.1-1_armhf.deb

sudo dpkg -i libyaml*.deb

Compiling the sources


git clone https://github.com/SupSuper/OpenXcom.git --depth=0 
cd OpenXcom
mkdir -p buildcd build
cmake ..
CFLAGS="-marm -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard" \
CXXFLAGS="-marm -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard" \
ASFLAGS="-marm -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard" \
make -j5

mv bin/data ~/.local/share/openxcom/data
## customize target of link with your favourite binaries location
ln -s $PWD/bin/openxcom /usr/local/bin/openxcom


At this point, if everything went fine, you have almost finished.


Using the original game


Run the game by providing the original game's directory:

SDL_AUDIODRIVER=alsa /usr/local/bin/openxcom -data /path/to/XcomEnemyUnknown/


NOTE: The prefixed SDL_AUDIODRIVER variable is needed to force usage of ALSA, since I get garbled sound with pulse. If you don't have pulse installed then it's safe to assume that you won't need this environment variable

Game options

From options, select full screen and change resolution to 1280x720 for best gaming experience.

Enjoy it! :)

2013-09-07

Postfix, virtual mailboxes and aliases: priority matters

Sometimes - either for work or leisure - I need to configure Linux servers, and also mail servers.

The '90s lovely logo of Postfix

postfix is a great software that I like to use for mailservers; in this post I want to describe you one feature that works in a counter-intuitive way.

In postfix you can define mailboxes by specifying in your /etc/postfix/main.cf:

virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps

Official virtual MAILBOX example here

You can also specify aliases, e.g. mailboxes that directly forward to other mailboxes, by specifying:

virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps

Official virtual ALIAS example here
Aliases are useful for example when you want to define a catch-all alias forwarding all mail to the postmaster address.

Priority matters!

However, what I dislike is the priority applied to both: aliases have higher priority than mailbox maps (yes, you've read right).

The first time I configured an alias I got all mail delivered to the catch-all address because I thought that - being less catchy - the catch-all addresses would have less priority.

What you need to do is instead add identity definitions to the aliases map, this way:

john@example.com   john@example.com
mary@example.com   mary@example.com
berry@example.com  berry@example.com
@example.com       postmaster@example.com

In above example of virtual_alias_maps, the last line is the catch-all line, while the other lines are inherent to mailbox maps defined in virtual_mailbox_maps.

Now tell me if that's not counter-intuitive, error-prone (because of the duplication) and less easy to mantain.

2013-09-01

The state of hardware acceleration on ODROID U2: 3rd round

There has been fermentation and progress regarding the ongoing 3.8 issues (performance degradation, FIMC/FMC), today I have tested the 3.8 hardkernel linux tree, added some missing patches and could finally complete my benchmarks.

Kernel X11 Driver Resolution glxgears es2gears glmark2-es2 glmark2-es2 --fullscreen
3.0.90 ARM mali 720p ~ 140 fps ~ 599 fps 142 81
3.0.90 ssvb sunxi 720p ~ 144 fps ~ 620 fps 156 91
3.8.13.7 ARM mali 720p ~ 139 fps ~ 659 fps 143 81
3.8.13.7 ssvb sunxi 720p ~ 144 fps ~ 447 fps 87 48

You can compare these tests with the 2nd round of my benchmarks: did you notice the difference? :)




Yes, the performance degradation bug is fixed. Many thanks to ovversun, memeka and mdrjr for all their work and tests!

2013-07-28

Why eBay should disappear tomorrow

I have been using (or better: being affected by...) eBay for almost a decade now. What is my opinion?

It's the worst corporate-blind company in the world, not caring a dime about its customers and enjoying a de facto monopoly as much as they can.
Image courtesy of http://whyebaysucks.info/

This is the list of complaints I have for eBay:
  • crappy user interface that didn't change in the last years, no improvement, no nothing. If the cash cow is milking well, why change anything, right?
  • you cannot change the user interface language and it must be the same language of the nation you have a living address in. Microsoft has the same habit. The message I perceive is: we don't care about you people moving across country borders. How you dare!
  • The HTML editor is...horrible
  • if you save your item as a draft, and then save another item as a draft..*puff!* your previous item is gone. No warning, no nothing.
  • where are our well paid government officials when it's about antitrust? By buying PayPal they created the best monopoly ever, and basically you are forced to use it when using eBay. There are little to zero alternatives, and using others you loose all the "protected customer" rights
  • account verification is a joke. It has a lot of glitches, it keeps looping in a stupid sequence of 3 forms if you haven't yet verified your account from PayPal. So cheap for such a big company, and the problem has been there at least 5 years already!
  • it doesn't matter if your item is conform to description. If the buyer complains, he will get the money back. You are on the weak side by selling on eBay.
  • if you want to sell abroad, eBay will show you that you need 10 feedback comments and 90 days must have elapsed after last sale. But only after you completed the insertion, just to make it more fun for you.
 There are no sound alternatives that I know of, but I seriously hope that they will come to light...this online "service" already smells very bad these days.

2013-07-16

odroid-wheezy-retro 0.8.1 released: ALL RetroArch cores & fixes

A new release!

  • compiled RetroArch with NEON-optimized sound resampler (thanks to Squarepusher)
  • enabled page flipping (DRI2_PAGE_FLIP) for smoother RetroArch experience
  • added vim and missing packages for eduke32 and RetroArch-Phoenix
  • removed modelviewer core, added all RetroArch cores
  • added ~/libretro-super
  • enabled all joystick drivers in kernel

2013-07-14

odroid-wheezy-retro: wishlist & work-in-progress

These days I have been hacking around the ODROID U2 to improve RetroArch performance and better exploit the device's features.

One important achievement is that DRI2_PAGE_FLIP is confirmed to not be negative (at least on 3.0 kernels), but instead gives a positive performance improvement, so please enable it in your xorg.conf configurations.

This is my current wishlist, in priority from most important to lowest:
  • good GPU performance on 3.8 kernel, there has been some progress on this front recently but we are not yet there, 3.0 gives best performance so far Update 1 September 2013: there has been some progress :)
  • G2D support on 3.8 kernel, a support comparable to 3.0 kernel
  • G2D example usage, see also my hello-g2d-odroid and this forum thread
  • G2D-accelerated X11 driver, this could definitively possible once we have a working example
  • MFC-accelerated video decoding, there has recently been some progress on this
  • VSYNC on 3.0 kernel, basically this patch needs to be back-ported so that VSYNC ioctl calls actually do wait for VSYNC - done! Thanks to mdrjr for the patch; it is however verified that VSYNC is not working because of a hardware issue with the HDMI PHY :(
The last one seems easy to accomplish, and the G2D example usage is definitively possible to complete, although nothing else is at my reach :(

G2D acceleration is important to achieve because it would help at scaling anything using the hardware acceleration SoC.

2013-07-11

odroid-wheezy-retro 0.8.0 released: more RetroArch cores

I have been doing some usability testing with Squarepusher and I have applied some improvements that were missing, so here you are with the 0.8.0 cumulative upgrade release.

ODROID Debian Wheezy, retro flavour

Download area

2013-07-10

Windows Update NoNag

Most advanced users, sysadmins and developers that I know are extremely pissed off by the looping nag-screen that Windows Update shows after you install updates.

a bright example of an anti-feature
Although I have found online countless explanations about how to disable the above bastard dialog, they never worked quite well for me.

Since I am a developer, I switched to heavy artillery:

https://github.com/neagix/misc/tree/master/WindowsUpdateNoNag

You can grab the binary directly from here:

https://github.com/neagix/misc/raw/master/WindowsUpdateNoNag/WindowsUpdateNoNag-AnyCpu-1.0-binary.zip

Right after you see that lovely dialog again, run this with Administrator privileges.
NOTE: this tool will disable it only till your next windows update

2013-06-26

ODROID forum members Monthly Award of June

Yesterday I have received news that my project has won the ODROID community Project Monthly Award! Yuppiee!!
One more reason to party :)
Many thanks again to mdrjr and Lisa from Hardkernel for this awesome award - this is really one of the best forum communities I have ever partecipated in. 
I always start trying to make something cool with Gimp, then I end up with some awkward graphics like this. Fair enough, I can't do better anyway :)
This means an extra U2 to play with :) However, I have already 2 and I am not greedy, so I started thinking what it would be the natural usage of such great dev board...

Got any idea?

RetroArch! I quickly decided to have the RetroArch project, in the person of Squarepusher, receive this hardware as a gift for the best of both our growing communities. I see potential for the combination ODROID+RetroArch and on the U2 RetroArch truly shines as a comet of power and great features (like the RGUI).
See how poetic and generous I become when I think about my beloved U2 and retro gaming? :)

More to see on this channel...

My commitment to ODROID community and RetroArch will now be even more motivated. I keep taking care of these releases and news because, as I said in the beginning, I would like to see a skilled development community grow up around these great hardware/software projects.
I have plans for better integrated releases and also tighter testing/development support of RetroArch cores..keep tuned and/or join the efforts if you feel the challenge :)

2013-06-22

Duke Nukem 3D on ODROID

Chocolate Duke Nukem 3D: a sad story


I am a Duke Nukem 3D aficionado and I've recently read with interest Fabien Sanglard's review of Duke Nukem 3D source code. As he writes, the original source code was really horrible.

The Duke on his glorious cover - 3D Realms page here

Fabien also started a Chocolate port, so I grabbed it to try to run the Duke glories on ODROID/Linux.

I realized - in disappointment - that this was a quick hack to have it running on Mac, not a proper chocolate port.
Furthermore the provided Visual Studio solution files were referring to some previous version of the project, with non-matching paths and broken includes - making it also not possible to build it on Windows (this portable is not, my young padawan).

During my own quest to have it building properly on Linux I decided to use Canassa's patches, since they seemed to be done in the reasonable framework of a chocolate port, and then I wrote my own Linux makefiles because Canassa is apparently also a Mac user - thus no Linux portability efforts were added at any time.

My chocolate improvements

In my fork I have added proper CMake support, grab it here: Chocolate Duke Nukem 3D with Linux compile support

However the status of this codebase is almost hopeless:
  • will not work on anything else than 32bit systems
  • some glitch when player dies
  • the 3D Realms logo has some palette quirk, doesn't look like it used to be
Me unhappy :(


If you try to run it on a 64bit system you get only the initial animation, then it goes on "Segmentation fault". That's kind of expected, given the waterfall of integer-to-pointer and pointer-to-integer warnings shown during compilation.

Next step: eduke32


I didn't start from this more advanced port because I wanted to use a faithful version of Duke Nukem 3D, however I am now pleased to see that customization of the built eduke32 is possible to an extent that most advanced features can be turned off.

This is perfect for our ODROID retro-goals! :)

I have done some fixes and prepared a build script, grab them here: eduke32 patch to run on ODROID + optimized build script

Diplomacy is the best feature of this game, as I remember

And enjoy Duke Nukem 3D - it runs flawlessly fast on my U2!

P.S.: I have added the eduke32 binary to release 0.7.3 of odroid-debian-wheezy, or you can download it from here (will only work with Debian Wheezy 7.1 ARM hardfloat)

2013-06-19

odroid-wheezy-base (new image) & odroid-wheezy-retro release update

Time for release! A bugfix release for odroid-wheezy-retro and a new image, even smaller! :)



The new base image, odroid-wheezy-base, contains:
  • debootstrapped Debian root filesystem
  • wired network configured for DHCP
  • SSH
  • configured serial login on UART
  • nothing else!

This is ideal to setup a Debian server with your ODROID, or to kickstart any other customization project you might have. To name only a few: (web)servers, robotics, domotics, top-boxes, you name it!

Release update for odroid-wheezy-retro


The nasty network issue is solved in 0.7.2:



The wildness of the network issue

Some users have reported network issues, however I was never able to reproduce them. At some point I did, and the nature of this issue manifested itself as a very nasty heisenbug.

On first boot the ethernet MAC address was randomly generated and the SSH keys regenerated; it turns out that some randomly generated MAC addresses would make the ethernet never come up, with an error like:

RTNETLINK answers: Cannot assign requested address
Listening on LPF/eth0/xx:xx:xx:xx:xx:xx
Sending on LPF/eth0/xx:xx:xx:xx:xx:xx
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
send_packet: Network is down
receive_packet failed on eth0: Network is down


Correlation is not causation

However, getting to the above conclusion was not easy because last week I observed the following and made wrong correlations:
  1. downscaling issue with one of my customized wheezy-retro SD images (no reason yet verified for this issue, although it is specific that SD image)
  2. network issue with the dedicated wheezy-retro SD image (this was due to the smsc95xx_mac_addr file), letting me for the first time verify the issue of users
  3. found some corrupt (all null bytes) files in the dedicated wheezy-retro SD image
Since file corruption can "taint" everything it touches, I assumed that both the downscaling and network issue were correlated and caused by the first-time observed file corruption.

The lesson is that these issues should instead be considered separate (except 1 and 3 that still need to be verified for correlation), and I have applied mitigation (rsync checksum verification) for (3).

2013-06-09

odroid-wheezy-retro 0.7.1 released: now with desktop icons

0.7.1 released

From the ChangeLog:
  • added idesk as desktop manager
  • added all quicklaunch icons (lxterm, glxgears, es2gears, glmark2-es2, retroarch)
  • other minor improvements/fixes
  • version bump (to 0.7)

Summary

In this version I am glad to introduce a nice & handy addition: desktop icons!

Looks much better now
Due to the constraints of this image (to be lightweight and development-oriented) I did not want to add any proper desktop environment and I fixed & compiled idesk instead. It draws icons. That's all I wanted for this image.

You can launch straight-ahead from desktop the following:
  • LXterminal
  • GLX gears demo
  • ES2 gears demo
  • glmark2-es2 benchmark suite
  • RetroArch (with my patches)

IDesk (fluxbox complement) forked

In odroid-debian-wheezy-retro I am using the great fluxbox as a very lightweight window manager. An useful addition would be icons on the desktop to quick-launch applications.

This is one of the screenshots found at original IDesk SourceForge project. Seriously? >.<

My first choice, fbdesk, is unfortunately broken, so I digged around and the available options for a lightweight desktop were rox-desktop and idesk. rox-desktop comes with a whopping 20 dependencies and idesk is outdated (2005).

The problem with adding so many depencies to a development-oriented distro is that it breaks the philosophy and goals behind it. Instead, by using the most lightweight choice (although less functional) you always leave the user the opportunity to easily make a choice and pick their own, and this is important.

I ended up picking up the orphaned codebase, applying a few patches and polishing it for 2013 :)

Here's my fork: https://github.com/neagix/idesk

I will be mantaining it for a while, so please feel free to use the github facilities to contribute with patches or issue reports.

The state of hardware acceleration on ODROID: 2nd round

Today I have repeated tests with current kernels:

Kernel X11 Driver Resolution glxgears es2gears glmark2-es2 glmark2-es2 --fullscreen
3.0.80 ARM mali 1080p ~ 143 fps ~ 590 fps 137 35
3.0.80 ssvb sunxi 1080p ~ 140 fps ~ 615 fps 151 40
3.0.80 ARM mali 720p ~ 140 fps ~ 600 fps 142 81
3.0.80 ssvb sunxi 720p ~ 144 fps ~ 620 fps 156 92
3.8.13 ARM mali 720p ~ 136 fps ~ 226 fps 61 37
3.8.13 ssvb sunxi 720p ~ 143 fps ~ 226 fps 66 42

Performance seems still halved with 3.8 kernel.
The automated test suite will be released in odroid-wheezy-retro as a script.

2013-06-01

odroid-wheezy-retro 0.0.7 released

0.0.7 released


In this release:
  • kernel 3.0.79 (with disabled fan PWM kern.log verbosity)
  • added xf86-video-sunxifb, you can enable it by copying /etc/X11/Xorg.conf-sunxi to /etc/X11/Xorg.conf
  • added glmark2-es2 binary
  • updated RetroArch binary
  • enabled HDMI 1080p output, (advice: disable it and use instead 720p to use RetroArch)
  • using EXT2 instead of EXT4
  • fixed a few issues related to bootstrapping
ODROID models X/X2/Q are supported by replacing kernel and modules before flashing to SD card, you can get them from mdrjr's builder download area.

Download odroid-wheezy-retro-0.0.7


You can always check the ChangeLog and NextRelease (suggestions are welcome).
Official ODROID forum discussion here.

2013-05-31

The state of hardware acceleration on ODROID (xf86-video-sunxi, xf86-video-mali and kernel 3.8)

Yesterday I tried xf86-video-sunxi (thanks to ssvb, rz2k and xjuan for the support!) and I have to say that this driver bears promise, in particular regarding G2D support, that hopefully in future will bring us 2D hardware acceleration.

The rotating horse is always fun, even when you rotate it.
I have run tests with the following combinations (some old test logs available here):

Kernel X11 Driver Resolution es2gears glmark2-es2 glmark2-es2 --fullscreen glxgears
3.0.79 ARM mali (31 may) 720p ~ 345  fps 160 96 125 fps
3.0.79 ARM mali 720p ~ 345 fps 160 96 125 fps
3.0.79 ssvb sunxi 720p ~ 261 fps 153 89 125 fps
3.8.13 ARM mali (31 may) 720p ~ 226 fps 61 37 ~ 140 fps
3.8.13 ARM mali 720p ~ 226 fps 61 37 ~ 140 fps
3.8.13 ssvb sunxi 720p ~ 226 fps 66 42 ~ 144 fps

Update 8 June 2013: see 2nd round of tests

The compiled sunxi driver and glmark2-es2 are included in version 0.0.7 of the odroid-wheezy-retro SD image.

RetroArch

With both kernels and with both X11 drivers RetroArch performs well in windowed mode (50FPS with rare frame drops with the 3.8 kernel).

Conclusions

  • there is currently a performance issue on kernel 3.8, our beloved mdrjr is working on it
  • glxgears is always software-rendered (see HardwareAcceleration), it's included only for reference
  • 1080p resolution is slow with all configurations, thus I have not targeted it for testing
  • the new Mali drivers (r3p2 released on 31st May) are the same as previous
  • xf86-video-sunxi starts to perform better on kernel 3.8, probably because of the NEON bug that affects 3.0
For now I will keep using kernel 3.0 and ARM mali drivers in odroid-wheezy-retro SD image, however I expect great improvements on both fronts (3.8 kernel and sunxi driver).

2013-05-28

A couple of updates for odroid-wheezy-retro (kernel 3.0.79 and 3.8.13)

I have released 2 scripts to upgrade your odroid-wheezy-retro image to a more recent kernel:


  • upgrade-3.0.75-to-3.0.79.sh, this will upgrade to the most recent 3.0.y kernel. This is currently stable & supported (by me) and will be in next SD image release (0.0.7); also contains a patch to silence the fan message spam in kern.log
  • upgrade-3.0.y-to-3.8.13.sh, this is experimental and subject to change without notice. This script will upgrade to a recent (consider it a nightly build) 3.8 kernel, complete with modules
NOTE: it does not work perfectly with X/X2 e.g. you will have to fix some issues manually
I have not yet decided when to put 3.8 on the odroid-wheezy-retro image - I am going to do some testing before that.

If you are installing 3.8 remember to change your device from /dev/fb6 to /dev/fb1 in /etc/X11/xorg.conf

Official ODROID forum discussion here.

2013-05-27

PCSX-ReARMed on ODROID-U2 (through RetroArch)


These notes are useful to get PCSX-ReARMed (by notaz) running on an ODROID-U2, with full ARM optimizations.

Due to some bug in the current configure/Makefiles, you will not be able to compile&run it succesffully. I got errors like this:
RetroArch [ERROR] :: dylib_load() failed: "pcsx_rearmed_libretro.so: undefined symbol: gteNCLIP_arm".
RetroArch [ERROR] :: Failed to open dynamic library: "pcsx_rearmed_libretro.so"
RetroArch [ERROR] :: Fatal error received in: "load_dynamic()"
And this:
RetroArch [ERROR] :: dylib_load() failed: "pcsx_rearmed_libretro.so: undefined symbol: gteRTPT_neon".
RetroArch [ERROR] :: Failed to open dynamic library: "pcsx_rearmed_libretro.so"
RetroArch [ERROR] :: Fatal error received in: "load_dynamic()"
 
So here you are some instructions to get it running.
First thing, get the libretro port:
git clone https://github.com/libretro/pcsx_rearmed

Apply this patch:

diff --git a/Makefile b/Makefile
index a472492..ed95702 100644
--- a/Makefile
+++ b/Makefile
@@ -10,6 +10,9 @@ CXXFLAGS += $(CFLAGS)
 #DRC_DBG = 1
 #PCNT = 1

+ARCH = arm
+HAVE_NEON=1
+
 all: config.mak target_ plugins_

 ifndef NO_CONFIG_MAK
diff --git a/Makefile.libretro b/Makefile.libretro
index 9436c8a..8a0d67a 100644
--- a/Makefile.libretro
+++ b/Makefile.libretro
@@ -97,8 +97,6 @@ else ifeq ($(platform), arm)
    DRC_CACHE_BASE = 0
    BUILTIN_GPU = neon
    ARCH = arm
-   CFLAGS += -marm -mcpu=cortex-a8 -mfpu=neon
-   ASFLAGS += -mcpu=cortex-a8 -mfpu=neon
 else
    TARGET := $(TARGET_NAME)_retro.dll
    CC = gcc

Now you're (almost) set. Run this script:

export CFLAGS='-marm -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard'
export CXXFLAGS='-marm -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard'
export ASFLAGS='-marm -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard'
./configure --enable-neon

make -j5 -f Makefile.libretro platform=arm

And enjoy PCSX-ReARMed on your ODROID :)

Issues

It is very slow! It's not performing very well, although all possible optimizations have been enabled. Update 26 June 2013: It's working very fast! Thanks to Squarepusher for the tip of using platform=arm :)

Furthermore, CSO/ISO are not working. Update 26 June 2013: I don't yet know how to work-around this, will publish a new post when I do

2013-05-18

odroid-wheezy-retro 0.6 released: you get kernel 3.0.75, 24bit HDMI output and wifi support!

As per title I have just released version 0.0.6 of the image that contains:
  • Hardkernel's linux kernel version 3.0.75, that comes with forced 24bit HDMI output (thanks to libv for the patch)
  • extra wifi drivers :)

If you have kernel 3.0.63 and want to upgrade just use the upgrade script from repository.

I am planning to release an even more streamlined release, so keep tuned! :)
Official ODROID forum discussion here.

2013-05-14

Recipe: compiling BSNES debugger (laevateinn) on Linux

BSNES is the best emulator around, there's little to say about that. Unfortunately the debugger is no more available in current higan because of refactoring and othe changes the author is making.

Let's get the last working bsnes debugger, laevateinn, compiling & working (spoiler: it.does.not.work) on Linux:

git clone git://gitorious.org/bsnes/bsnes.git
cd bsnes
git checkout v089
cd bsnes
nano nall/Makefile # replace "gcc-4.7" with "gcc"
make -j3 target=laevateinn

Finally the debugger will be found in out/laevateinn, but we are not yet there! It can only work with "cartridge folders".

So let's compile purify as well, and run it:

cd ..
cd purify
nano nall/Makefile # here replace "gcc-4.6" with "gcc"
make -j3
./purify output your-rom-path/ target-directory/


Now we are ready to run laevateinn:

cd ..
bsnes/out/laevateinn target-directory/

However, I could not use it because it shows me a non-sexy black screen :(
Possibly you might pick up the task from there.

Meanwhile I am using T.Geiger's snes9x debugger and I have contacted the author about sharing the sources (fingers crossed!)

Update 23 July 2013: instructions for Ubuntu 13.04 provided by user Jay Oster
NOTE: bsnes looks for its system ROMs in ~/.config/laevateinn/

Dependencies

$ sudo apt-get update
$ sudo apt-get install git build-essential libgtk2.0-dev libasound2-dev
# FOR PURIFY
$ sudo apt-get install libx11-dev

Build Laevateinn

$ git clone git://gitorious.org/bsnes/bsnes.git
$ cd bsnes
$ git checkout d418eda9
$ vim bsnes/nall/Makefile # replace "gcc-4.7" with "gcc"
$ make -C bsnes -j 8 target=laevateinn install

Build Purify

$ vim purify/nall/Makefile # replace "gcc-4.6" with "gcc"
$ vim purify/Makefile # add "link += `pkg-config --libs x11`"
$ make -C purify -j 8

PUTRIFY your ROM library

$ ./purify/purify output your-rom-path/ target-directory/

2013-05-11

odroid-wheezy-retro: updated wiki & release

I have started to populate and mantain some wiki pages for odroid-wheezy-retro


ODROID Wheezy Retro Wiki

It's hosted within the Google Code project's wiki, and it fits the purpose quite well so far.

Current release is 0.0.5, I have fixed the nasty issue with Debian automatic network udev rules, thanks to user be.lietaus for reporting it.

Many thanks to mdrjr for providing a backup location for the release files, that you can find here.

Are you an ODROID forum member? Please vote for me on this thread! Well, only if you like this release and want to see more about it coming  :)


2013-05-08

Neagix' excellent (and unofficial) Debian Wheezy Development&Emulation SD image


I have packaged a minimal Debian Wheezy downloadable SD image which achieves the same goals of my previous tutorial (and adds a bit more).
What You See Is What You Will Get 1/3

What You See Is What You Will Get 2/3
What You See Is What You Will Get 3/3

Features of this release

  • very small (187M packed), based on odroid.us base rootfs image
  • using stable kernel 3.0.68 released by Hardkernel
  • X11 hardware accelerated EGL, GLESv1 and GLESv2 (through Hardkernel's proprietary drivers)
  • boots automatically into Xorg 
  • it will not automatically turn off HDMI output when idle (so be careful with your LCDs!)
  • basic development packages already installed (gcc, g++, make, autoconf, automake etc)
  • scripts to fetch and build my fork of retroarch (+ related libretro cores)
  • retroarch (with snes9x-next core) and retroarch-joyconfig ready-to-run binaries included (these versions have my patches)
  • testing scripts for sound and 3D

Coming soon features

  • 3.0.75 kernel (I am testing it before adding to next release, but if you prefer you can upgrade using this script)
  • 24bit HDMI output support (I am not sure about this)
The first time you boot the image it will automatically re-generate SSH keys and assign a random MAC address (see /root/bin/bootstrap.sh for reference), so it might take a few seconds longer.

See project home page and instructions to flash the SD image.



Many thanks to mdrjr and all the other nice IRC people for the help provided since the beginning!

DISCLAIMER: this SD image is not officially supported by Hardkernel, nor I assume any responsability for its use and misuse

Previous posts on this subject:
http://neagix.blogspot.com/2013/04/retroarch-on-odroid-u2-with-hardware.html
http://neagix.blogspot.com/2013/05/retroarch-on-odroid-u2-revisited.html

2013-05-05

RetroArch on ODROID-U2, revisited

After my previous blog post I am considering creating a stand-alone, auto-updating modified Linaro image for RetroArch on ODROID-U2, but don't hold your breath for this now :)


Tip: listen to this great song while reading and hacking your ODROID+RetroArch setup

Update 7 May 2013: I released neagix' excellent (and unofficial) Debian Wheezy for Development&Emulation (with X11 hardware acceleration), get it while it's hot!

Some general advices for people approaching console emulation on ODROID-U2:
  • there is currently no known way to natively exploit the ODROID framebuffer (Exynos 4), thus we have to go through Xorg to run any emulator
  • composing desktop environments are bad for you, so no Unity/Compiz/you-name-it, use instead LXDE or XFCE
  • I have experienced kernel panic/oops/alignment trap issues when using my own compiled version of the kernel, thus I advice to stick to kernel 3.0.63 for now (this has proven to be stable so far) issue was due to PSU
  • remove xscreensaver and other screensaver packages, then modify xorg.conf to not automatically turn off DPMS and other screen blank settings
  • RetroArch runs fine with GL video driver and SDL input
  • be kind with your MCC/SD support, it's not like a regular hard disk and wearout factor is present. Nothing to be scared of, but consider moving write-often directories to external mountpoints
  • create a backup script and run it regularly. You don't know when, but your SD/MMC will one day wake up and tell you "So long, thanks for all the fish..."
  • use nobootwait in your fstab mountpoints, and if you are using NFS mountpoints specify an option for short timeout, like timeo=5
  • disable the long timeouts in /etc/init/failsafe.conf, and feel free to comment lines 34-35
  • if you are using lxdm as login manager, consider enabling autologin by uncommenting autologin=username in /etc/lxdm/lxdm.conf (username shall be your actual username)
  • if you are using LXDE, edit/create ~/.config/lxsession/LXDE/autostart and add a single line @retroarch (retroarch binary must be in your $PATH for this to work), this way once you boot ODROID you will be presented with retroarch
Suggested settings block for  ~/.retroarch.cfg:

video_driver = "gl"
video_fullscreen = "true"
video_windowed_fullscreen = "true"
video_aspect_ratio = "1.33333333333333"
audio_enable = "true"
audio_driver = "alsa"
audio_sync = "true"
input_driver = "sdl"
input_joypad_driver = "sdl"


Please note that only the first definition in the configuration file will be read, so I advise to remove duplicate definitions to reduce confusion.

Some patches for RetroArch

After my unsuccessful attempts at contributing RetroArch I've decided to publish these patches in my retroarch fork, hopefully they will be useful by people affected by my same problems.
Issue: when using RGUI and loading a saved state the button release is passed to the underlying core, causing all weird undesired actions

Fix: wait for all input to be released before starting the core, commit patch here

Issue: rather difficult to troubleshoot input issues might be related to wrong joystick configuration, that is also difficult to detect without a jstest-like program

Fix: enable logging of input events directly in retroarch, commit patch here
Feature: halt the system from RetroArch menu, commit patch here

Leaderitis acutis in open source

Leaderitis acutis

In the last days I wanted to contribute to an open source project with some feedback and bugfix/enhancement patches. Although I fully recognize my non-excellent C++ skills, I found the project to be affected by one of the most common diseases in the FOSS world: leaderitis acutis.

This is a purely fictional disease that I just invented and that I have been thinking about recently (I later found out it's used in american politics jargon, although I don't know how closely matches by what I describe here).

I have always been interested in open source philosophy (and also in free software to a lesser extent), thus I always find it appalling deludent when open source projects do not meet the essential expectations (that is very often for the smaller projects around these days).

Symptoms

  1. Project has very few developers and it has not been exposed to the beneficial strength of the "many eyes"
  2. The most prominent developers use the project to foster all their favourite code smells and anti-patterns (lack of comments, cryptic/mangled code, Baklava code, you-name-it)
  3. Issues, patches and any feedback is negatively considered as a critic or even as an offence (although this might have roots deep into cursed developers' personality)
    Sketch by 3-3 studios
  4. The attitude towards any form of feedback that is not a plain compliment is "Sheesh! This is my little precious, you won't touch it!", missing the point that open source is not your own thing, not even when you start it or are the main contributor
  5. As a last resort solution to any civil and logic argument, developers/mantainers will assert that you have no right to express your opinion, or that your opinion is not supposed to be worth anything in first place. To justify this assertion and enforce the paradigm that they should be trusted as superior, God-gifted owners of truth, they will either:
  • specify that your total contributions amount to 0% and their contributions to 99%, cheerfully living in a chicken-and-egg paradox (or simply barring entry to potential contributors to mantain their sphere of influence untouched)
  • possibly try with any form of personal attack like "you make mistakes, thus your opinions are not trustable".

Cure

There is no known cure for leaderitis acutis, although progress has been verified with personal growth of the involved developers and mantainers that generally happens when time tells them that open source is not about going solo/berserk.

2013-04-15

RetroArch on ODROID-U2 (with hardware acceleration, yes!)

ODROID-U2

I have tried to run decent console emulation on Raspberry Pi, without success.

So I recently got my hands on an ODROID-U2 (that comes with a respectable more powerful hardware) and that can potentially carry out my console emulation and preservation dreams.

In the below pictures you can see it shily coming out of the box:

A small package to rule them all

Better use a fan if you want to overclock this little beast!


















This development board comes with 4 ARM Cortex A9 CPUs and the Mali 400 GPU (more about this later); when choosing a development board you should really pay attention to the planned shelf life, the expected community size and the GPU driver support. There's really nothing else that will matter more for you than the open source/closed source drivers.

In these regards the vendor, Hardkernel, gets my kudos as I see they are working hard to deliver the best to the community that's aggregating around ODROID (but keep in mind that it's not yet very big right now, so weaponize yourself for all cases!).

As far as I understood the driver is partly closed-source, for longer term dreams (full open source Mali400 driver) you could check out the Lima project, although nothing usable is available at time of writing.

I was expecting some geeky adventures to achieve my goal, and I wasn't disappointed. In the last few days I had to learn all my way through forums, IRC, blog posts and generally fragmented and incomplete information - but finally after a few strong machete cuts I have been able to see the light!

Do-it-yourself

I didn't want to release the result of my efforts as Debian packages or complete SD images (update: I did!), so I will provide you with a walkthrough and the necessary steps.
The reasons are:
  • possible licensing concerns, it is not fully clear to me if I am entitled to release these (for example the vendor-provided drivers);
  • releasing concerns, once you release something you should take care to mantain it;
  • philosophy: if you are using a development board you should really get in touch with all the layers to better understand how things work.

I used this blog post as starting point and also other resources here and there; in this blog post I am focusing only on SD card booting and ODROID-U2 specifically.
Although I didn't follow it originally, you might also want to read the official post about ODROID-U2 and then come back for the other steps about Xorg configuration and RetroArch.

Update 7 May 2013: I released neagix' excellent (and unofficial) Debian Wheezy for Development&Emulation (with X11 hardware acceleration). I advise to use the image as information in this post might be obsolete.

Prerequisites

In the following steps I aim to provide an aid at getting a fully functional RetroArch on ODROID-U2.

If you can use debian apt-get/aptitude and SSH you should be able to follow it. Also you might want to use Google in case of some strange error that is not covered by this tutorial.

This is not a from-scratch tutorial for complete newbies, so please don't expect so.

Update 25-April-2013: the more advanced cores will not exhibit a great performance, but you should be fine with emulation of 16bit (and less) consoles

Step 1 - booting the device


Insert the microSD in a Linux PC, then check with dmesg|tail what is the dev node. On my PC it was /dev/mmcblk0. Please take note of the root device, not the partition device (that would be /dev/mmcblk0p1 and so on).

Now download a prepared ODROID-U2 Ubuntu image and flash it to the microSD card.


wget http://www.mdrjr.net/odroid/mirror/ODROID-U2/Ubuntu/odroidu2_20121231-linaro-ubuntu-desktop-uSD.zip
7z x odroidu2_20121231-linaro-ubuntu-desktop-uSD.zip
sudo dd if=odroidu2_20121231-linaro-ubuntu-desktop-uSD.img of=/dev/mmcblk0 bs=24M

Update 14 July 2013: use instead the odroid-wheezy-retro image, instructions here

At this point I advice to eject/insert the microSD card, then run the following:

sudo resize2fs /dev/mmcblk0p2

This will resize the linux partition to the maximum available space on your SD card.

Before proceeding to next step you might want to mount the /dev/mmcblk0p2 partition and change some files there for easier initial setup (like wired network, for example).

And now...ready for the show! Put the SD card back in the ODROID device and boot your device.

Step 2 - First boot operations

The first time you boot you should connect through SSH to your device, default users have the following usernames/passwords:

root / root
user / user

As first operation change those passwords, and possibly you might want to use usermod to rename 'user' to something else.

After that re-generate the SSH keys:

sudo rm /etc/ssh/*_key /etc/ssh/*.pub
sudo dpkg-reconfigure openssh-server

Modify /etc/rc.local by adding these lines before the last exit 0 line (reported for reference):

cpufreq-set -g ondemand -d 200Mhz
chown .video /dev/ump
chown .video /dev/mali
chmod 0660 /dev/ump
chmod 0660 /dev/mali


Install now cpufrequtils package if you are not going to do Step 3.

Also make sure that your user is in the following groups:
user adm cdrom sudo audio dip video plugdev lpadmin pulse

Step 3 - Trimming down the installation (optional)

In this optional step (that is also untested!) I explain how to remove a lot of packages that come by default installed with Linaro Ubuntu, you can skip it if you prefer to customize it by yourself.

Download odroid-u2-slim-package-selections.txt and then restore the selections by running:

sudo apt-get install dselect
sudo dpkg --clear-selections
sudo dpkg --set-selections < odroid-u2-slim-package-selections.txt
sudo apt-get -y update
sudo apt-get dselect-upgrade

A lot of packages will be removed and you should get XFCE installed in place of Unity (although I advise using LXDE).

When you have finished, please run:

sudo dpkg-reconfigure -a

To go through all necessary configuration steps.

Please note that the display manager will also not work! So don't expect any output on HDMI yet. Real men/women use terminal ;)

Step 4 - Getting the bare metal hardware (acceleration)!

It is necessary to update the kernel to use proper Mali400 hardware-accelerated GPU drivers.

We will use the 13th February release:

wget http://dn.odroid.com/Ubuntu_U2/20130213/linux-3.0.63-odroidu2_20130213.tar.gz
tar xvfz linux-3.0.63-odroidu2_20130213.tar.gz
cd linux-3.0.63-odroidu2_20130213
rm fstab
sudo ./install.sh


At this point a reboot is necessary to make the new kernel effective, I will ask you for such reboot at a later step.

Now we will install the vendor-provided mali400 drivers:

wget http://dn.odroid.com/MALI400_R3P2/20130222/mali_packages.tar.gz
tar xvfz mali_packages.tar.gz
cd mali_packages
sudo dpkg -i mali400_2.1-13_armhf.deb mali400-dev_2.1-13_armhf.deb xf86-video-mali_1.0.1-7_armhf.deb
sudo rm -rf /usr/lib/arm-linux-gnueabihf/mesa-egl /usr/share/X11/xorg.conf.d/99-hkl_mali.conf


Please note that we are removing 2 objects here:
  • mesa-egl, because would prevent you from getting the Mali EGL acceleration
  • 99-hkl_mali.conf, that is the default Mali configuration and consitutes just a source of confusion (it always overrides your xorg.conf)

Step 5 - Build your own xf86-video-mali (optional)

This step is optional e.g. you don't need it, I am keeping it here for reference.
Install xorg-dev, xutils-dev, automake, autoconf and libtool, then download the sources from ARM website (I've used release of 11 March 2013 called Linux EXA/DRI2 and X11 Display Drivers r3p2-01rel1), then enter the proper directory and run the following script build.sh:

#!/bin/bash
set -e
ODFLAGS="-DUMP_LOCK_ENABLED=1 -mfpu=neon -mfloat-abi=hard"

autoreconf -rfi
CFLAGS="$ODFLAGS" ./configure --prefix=/usr
CFLAGS="$ODFLAGS" ASFLAGS="-mfpu=neon -mfloat-abi=hard" make -j5

This will quickly deliver an usable xf86-video-mali that you can use in conjunction with the mali400 driver package from step 4.

NOTE: on some older versions of autoconf you can only do autoconf -fi

Step 6 - Starting XFCE4

If you have not before, reconfigure X11 to allow any user:

sudo dpkg reconfigure x11-common

Make sure that "Anybody" is selected and save.

Now let's setup /etc/X11/xorg.conf:

Section "Device"
        Identifier "Mali-Fbdev"
        Driver  "mali"
        Option  "fbdev"           "/dev/fb6"
        Option  "DRI2"            "true"

        Option  "DRI2_PAGE_FLIP"  "false"
        Option  "DRI2_WAIT_VSYNC" "false"

        Option  "UMP_CACHED"      "true"
        Option  "UMP_LOCK"        "false"
EndSection

Section "Screen"
        Identifier   "Mali-Screen"
        Device       "Mali-Fbdev"

EndSection

Section "DRI"
        Mode 0666
EndSection


Please note the DRI2_PAGE_FLIP setting above, set to disabled. If you enable it your applications performance will start to thrash after a couple of minutes. For example RetroArch had a constantly falling down FPS because of this. I have also experienced instant crashes (SEGFAULT) with fullscreen applications using it.
Update 13 July 2013: The segfault was due to using the setting "DefaultDepth 16", and DRI2_PAGE_FLIP does no more show a negative behaviour, actually a positive one - so feel free to enable it. VSYNC can be enabled but it's not effective, see also this post

Update 05 May 2013: I have provided with a more recent version of xorg.conf here in this post, that adds only turning off DPMS

Now we're ready again. Reboot the system (and check that you are running kernel 3.0.63 through uname -a), then run:

startxfce4

XFCE4 will display in all its glory. Your Xorg.0.log will contain:

(EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/Mali DRI2_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/Mali DRI2_dri.so: cannot open shared object file: No such file or directory)
(EE) AIGLX: reverting to software rendering
(II) AIGLX: Screen 0 is not DRI capable
(II) AIGLX: Loaded and initialized swrast
(II) GLX: Initialized DRISWRAST GL provider for screen 0

You can completely disregard the above as hardware acceleration will instead work, and we are now going to verify it.

Bit depth

By specifying a DefaultDepth of 24 you will get a segfault right after the GET_UMP_SECURE_ID_BUF1 line in the log.

Update 18 April 2013: libv has personally sent a patch to mdrjr so that HDMI output up to 32bit will be supported, stay tuned! :)
Update 21 April 2013: by recompiling the 3.0 kernel (provided by Hardkernel) with CONFIG_VIDEO_EXYNOS_24_FORCE=y you can use HDMI in 24 bit mode, many thanks to libv for the patch

Step 7 - Rotating horses and crates!

Now it's time to see hardware acceleration in action.

You can use 3 programs to check the status of hadware acceleration on your ODROID:
  • glxgears, a classic tool to test GLX
  • es2gears, for ES2 testing
  • glmark2-es2, that is actually a benchmark and you will score 92 if everything went right
If your hardware acceleration is enabled you will see FPS above 100 in all of them (although not in all glmark2-es2 tests).

If you verify hardware acceleration to be working, feel free to continue to step 7.

Step 8 - Time for RetroArch

Unfortunately I have not been able to use KMS with Mali 400, I think it's not supported, but I managed to use RetroArch in accelerated X11.

Let's download and compile RetroArch:

git clone https://github.com/Themaister/RetroArch.git
mv RetroArch retroarch 
cd retroarch
CFLAGS="-mfpu=neon -mfloat-abi=hard" ./configure --enable-x11 --enable-gles --enable-alsa --disable-oss --disable-jack --disable-pulse --disable-kms --disable-vg
ASFLAGS="-mfpu=neon -mfloat-abi=hard" make -j5


If you get gcc errors about virtual memory exhausted or other weird corruptions, try to set the governor to userspace for the length of compilation operations.

At this point you should have a compiled retroarch binary, we are ready for Step 8.

NOTE: I have only a small patch, you might want to use it in you have an error there (compiling with VG support):
diff --git a/gfx/vg.c b/gfx/vg.c
index c5b92e0..bbfc3a8 100644
--- a/gfx/vg.c
+++ b/gfx/vg.c
@@ -99,7 +99,7 @@ static void *vg_init(const video_info_t *video, const input_driver_t **input, vo
    RARCH_LOG("Detecting screen resolution %ux%u.\n", vg->mScreenWidth, vg->mScreenHeight);

    vg->driver->swap_interval(video->vsync ? 1 : 0);
-   vg->driver->update_window_title(true);
+   vg->driver->update_window_title();

    vg->mTexType = video->rgb32 ? VG_sXRGB_8888 : VG_sRGB_565;
    vg->mKeepAspect = video->force_aspect;
@@ -387,7 +387,7 @@ static bool vg_frame(void *data, const void *frame, unsigned width, unsigned hei
    if (msg && vg->mFontsOn)
       vg_draw_message(vg, msg);

-   vg->driver->update_window_title(false);
+   vg->driver->update_window_title();

    RARCH_PERFORMANCE_STOP(vg_fr);
    vg->driver->swap_buffers();


Step 9 - We need a core


RetroArch cannot do anything if you have no cores. Let's build snes9x-next.

git clone https://github.com/libretro/snes9x-next.git
cd snes9x-next
mv snes9x-next libretro-snes9x-next
make -j5 -f Makefile.libretro


Now you will have snes9x_next_libretro.so, take note of the path to this file by copying the output of:

ls $PWD/snes9x_next_libretro.so

Now let's go back into retroarch's working directory and run RetroArch:

DISPLAY=:0 ./retroarch -L /your/complete/path/snes9x_next_libretro.so SNES9X\ Demo\ V1.16\ \(PD\).smc

If you are typing this into an XFCE terminal, then you can omit the DISPLAY=:0 part.

Now you should see the ROM being emulated with FPS count on the window title bar.
You can install the other cores manually (one by one) or by using the libretro-super scripts.

Step 10 - Packing up together


It is advised to use different CPU settings when running retroarch; for this reason I use a script similar to this snes9x.sh:

#!/bin/bash
sudo cpufreq-set -g ondemand --min 1.6Ghz
DISPLAY=:0 ./retroarch -L /your/complete/path/snes9x_next_libretro.so $@
sudo cpufreq-set -g ondemand --min 200Mhz

This script will effectively change the minimum frequency when you are using RetroArch, and then restore it back when you exit (unless you use Ctrl+C, so don't!).

You can even use a higher minimum frequency if you experience slowdowns, however please pay attention that a fan might be needed when overclocking! Please refer to official ODROID information regarding this.

Step 11

SNES9X Demo ROM (Public Domain)

Enjoy it! :)

Conclusions


I think that ODROID-U2 has a lot of potential, I plan to do other interesting things in future with this development board.

Please let me know your feedback if there are errors or possibility of improvements by using the official ODROID forums discussion thread.