Posts from: January '11

PIC 3 RC2

I was in the lets-solder-something-just-for-the-heck-of-it mood so I grabbed the soldering iron. The results: my box mover now has a capacitor-based redundant power supply, implemented on a separate perfboard:




I haven't tested it thoroughly, but it easily survives at least half an hour without mains power. Nanotechnologies rock (I mean, 1F caps are surely awesome)!.

The original mission is probably about to fail: the plant has not shown any signs of turning red anytime soon. I'm going to tease it for another month, though.

Unrelated: want to know when you should celebrate the 10000th day since you were born? Check this out!

Posted in category Hardware -- 27 Jan 2011, 00:24, 0 comments

Benchmark week

It's been a benchmark week - I worked on two benchmarks simultaneously :)

UCBench 2011

A new version for the new year :) The website is http://anrieff.net/ucbench2011.
We're still cracking .RAR archive passwords and benchmark the cracking speed, however we're now 8-12% faster. And it has better CPU speed detection, equalized Linux vs Windows performance, and lots of tweaks and improvements on the website and the program itself.

Fract Benchmark for Android

I was following this article about using SDL on Android; however, it turned out to be a plunge in the wrong direction and I lost a few hours in fruitless attempts:

1) The SDL that gets compiled that way does not work with Android 2.2, it lacks /dev/tty0 and other related devices;
2) For some reason it requires root access. You have to root your phone. Also, as it does not create an .apk directly, you need to run the benchmark from the command line.

So, what I find out in the end was to simply use the latest SDL 1.3, directly sourced from the Mercurial repository. It has a wonderful README.android that explains it all. You just put your C/C++ sources inside a mock "Java"+JNI project, type a few commands and you get an .apk. Plain and simple.

The porting of Fract itself was also easy and I quickly got to this point:



The score is somewhat disappointing, especially considering the benchmark is run in reduced 400x300 resolution - so I delved into the generated object code and saw (to my astonishment) that the instructions were FPU-less, the compiler issued software floating-point code. Well, you can't assume a FPU on the ARM, but the newer devices do have FPU units (two, to be more precise - a VFP, which is similar to x87 in the PC world, and NEON, which compares to SSE1). So, to compile the NDK-part of your project with FPU support, you need to specify a slightly different architecture, using this build command:

ndk-build TARGET_ARCH_ABI=armeabi-v7a

I recommend you add V=1 in the end of that, so you can see what commands are being executed exactly. -mfpu=vfp is the relevant GCC option.

The two builds (FPU and non-FPU) can be found here:
http://anrieff.net/pocketfract.
Go test your android :)

Some results: a stock HTC Desire / Android 2.2 gets around 5.5 FPS. In comparison, Asus Eee PC 901, using the same fract sources and --no-sse --no-mmx --no-mmx2 --xres=400 --cpus=1 yields 11.7 fps. So far x86 wins :)

Posted in category Open source -- 19 Jan 2011, 10:11, 0 comments

Tube sound

Hey guys, happy new year to all of you!

I got recently into the audio hardware mood and did some testing at home - I have a couple of unused car audio speakers, and I went to check out whether it was worthy to assemble a DIY audio system, based on them. Basic PC usage, that is. After all, any audio geek out there would tell you that the speaker size is a key factor of the sound quality - good sound requires bigger speakers. Well, what I have here are 6.5" speakers, compared to the 3.5"-4.5" that are commonly available in consumer desktop PC speakers.

Well, after some testing, I concluded that the car audio speakers are inferior. So, if you want a decent sound, you should start with a pair of specialized, high-quality speakers - the ones used in cars are not good.

During testing, I tried what would happen if I put a small light bulb in series with the speaker:

DEMO

Enjoy the "warm", "tube" sound :)
What you won't hear from the youtube clip is that the bulb acts as an active component of the system, it is not just a blinking coolness! Remember that a resistor (the wire in this case) becomes more resistive as the temperature increases, so when the bulb shines bright after a powerful bass-kick, its increased resistance attenuates the sound a bit (not much, but it's quite noticeable). So, in short, it acts like a slow-acting audio compressor. Combined with the thermal inertia effects, I was truly amazed by the amount of functionality that can be achieved by a simple hot wire!

Posted in category Hardware -- 8 Jan 2011, 20:57, 0 comments