Archive for the ‘ Tips ’ Category

Arduino: a board and a philosophy

I’ve been working at my new job for over a year and what’s really different from all my previous jobs is the close relation that I have now with hardware.  Of course, programmers use computers, which is primarily “hardware” but most of the hardware I use now is built on the spot.  And meeting all the tech guys that actually handle the hardware (both on the building and programming sides) is really interesting: I can peek into one’s microscope to see the boards up close, ask them questions about things that I never learned in programming classes, about compilers, peripherals and all sorts of hacks …  This got me a little more interested in building my own small electonic projects but I didn’t know where to start.

So one of my colleagues directed me to a fine website called Hack a Day, which, according to him, is a good start for an amateur like me.  They have all sorts of posts for beginners to look into, especially a great article on various development boards to choose from.  I heard a lot about the Arduino board, which claims to be “open-source”.  I got curious and read a little about it.  The site also featured this wonderful documentary on the Arduino: Yes!  Open-source hardware exists and it’s something that falls right into the kind of things I’m interested in. This documentary didn’t just give me some bits of information, it explained to me a philosophy; something, I believe, should always be a part of the art of programming.

Now I haven’t really used one yet, mind you. But this got me really interested on getting one very soon.

You can check out the documentary below (and use full screen) or check out for other viewing / downloading options.

Happy hacking.

Converting *.mp4 to *.wav with MPlayer

Recently, my Japanese teacher has been sending me audio dictations in mp4 formats. It’s not a problem in itself since MPlayer or any other Linux player can read it. But nothing beats Audacity for listening and re-listening the hard parts (and change the tempo when things get really hard) but it doesn’t support MPA’s (or rather, it simply and unequivocally crashes). For the last 3 or 4 lessons, I still haven’t mastered this single line of Kung Fu to convert it with MPlayer:

mplayer -ao pcm:file=<out file>.wav <in file>.mpa

Notice how the pcm:file replaces the old syntax. MPlayer (on Ubuntu at least) will warn you about this.

Hopefully I’ll stop scouring the ‘Net and go straight to this page if my memory fails. And I hope you do too 😉

More Doom obsession with Ubuntu PowerPC

Continuing with my obsession with Doom – as decribed in my previous post – I tried compiling my modified original source on a PowerPC running both Mac OS X and Ubuntu Linux. Since they both have the X Windows system, it should work. Today’s post will be about Ubuntu.

Relevant libraries

I guess I got ahead of myself last time when I suggested to simply type ‘make’ to compile. In fact, they are a few packages that must be installed on Ubuntu. So install the relevant X developement libraries like so:

sudo apt-get install xlibs-dev x11proto-xext-dev libxext-dev

Compiling linuxdoom will yield a new set of errors that I hadn’t notice the first time around on a Intel x86 PC.


Endianess, for those who might not know, is how computer store numbers in the processor and, corollarily, on other devices in the system. On a big endian system, like a PowerPC, the numbers are stored, byte per byte with the highest values first. On a little endian system, such as the Intel x86 family, it’s stored with the smallest values first. Originally, Doom used a little endian scheme under DOS, so a Linux port that runs on an x86 would have no trouble with it. For big endian, you need to swap the values. Not necessarily all of them but certainly those who affect the devices: video, filesystem, etc. There are many references in linuxdoom to macros called SHORT() or LONG() that wrap certain values for this purpose. So the Doom porters added some extra pre-processor switches where a conversion will happen if you happen to compile on a big endian system. But is this enough … ?

Here’s what you get in m_swap.h:

// Endianess handling.
// WAD files are stored little endian.
#ifdef __BIG_ENDIAN__
short	SwapSHORT(short);
long	SwapLONG(long);
#define SHORT(x)	((short)SwapSHORT((unsigned short) (x)))
#define LONG(x)         ((long)SwapLONG((unsigned long) (x)))
#define SHORT(x)	(x)
#define LONG(x)     (x)

And here’s what you get in m_swap.c:

// Not needed with big endian.
#ifndef __BIG_ENDIAN__

// Swap 16bit, that is, MSB and LSB byte.
unsigned short SwapSHORT(unsigned short x)
    // No masking with 0xFF should be necessary. 
    return (x>>8) | (x<<8);

// Swapping 32bit.
unsigned long SwapLONG( unsigned long x)
	| ((x>>8) & 0xff00)
	| ((x<<8) & 0xff0000)
	| (x<<24);


First, even as #ifdef __BIG_ENDIAN__ in m_swap.h will set prototypes for the swap functions SwapSHORT() and SwapLONG(), it is incompatible with the fact that w_swap.c wraps these functions with #ifndef __BIG_ENDIAN__. We couldn't notice this error under x86 compilation - although the compiler could have warned us that the prototypes were missing - but on a PowerPC, it will fail.

So change the line in m_swap.c from

#ifndef __BIG_ENDIAN__


#ifdef __BIG_ENDIAN__

Next, the values between the prototypes and the definitions are all wrong. In the header file, SwapSHORT() and SwapLONG() both take and return signed values, whereas in the .c file, they're all unsigned. Change the signed ones in m_swap.h like so:

unsigned short   SwapSHORT(unsigned short);
unsigned long    SwapLONG(unsigned long);

These changes should make the linuxdoom code compile (with all its usual sets of warnings).

The sound server

What about the sound server ? It does compile and is set up to its right endianness. But the sound comes out all scratchy. It is possible that the conversion process was not complete. For the moment I have no solution for that. You can still compile the main linuxdoom source without the -DSNDSERV flag in the Makefile.

Final words

So, just like the x86 version on my previous post, start a new X session in 8 bit colors, open a console, set the environment variable for DOOM, make sure your Doom IWAD is present (and the sound server if you like scratchy noises) and voilà.

Next stop: Mac OS X.

return top