PulkoMandy news

Gravis Interface Protocol

Ever heard of the Gravis Gamepad Pro ? It's a gamepad using the old-fashioned PC gameport. It looks quite like the original Playstation controller and has a very solid build quality.

Those of you who know about the gameport limitations will quickly notice that there must be something non-standard about it: there are 10 buttons, while the gameport only allows 4. Even better, you can actually use 2 gamepads at the same time on a single port.

There are several modes accessible with a switch under the gamepad. These are 1-player, 2-player, and GrIP. In 1 player mode, you get 2 axis and 4 buttons. In 2 player mode, you get 2 axis and 2 buttons, and you can use 2 gamepads. In GrIP mode, each gamepad can use all 10 buttons, but this is not compatible with the games expecting a standard joystick.

I have some of these gamepads around, but my PC don't have a gamepad anymore. Since I'm not very happy with replacement hardware (I tried the Logitech Precision USB gamepad, but it doesn't look as nice and colourful), I'm thinking about building an adapter for these gamepads to plug them on an USB port. Of course, without opening and rewiring them. Not only this would void the long expired warranty, but I may still want to plug these gamepads to the system they were intended for (my 1995 Pentium 166 MMX).

There is some information on the internet about the protocol, but it's not easy to find. Heer is what I could get : a textfile with some info and the Linux driver for these joysticks. Since the textfile does not say everything the driver does, here are some notes that duplicate the text file and add the info from the driver.

First, the gameport pinout. It's a SUB-E 15 connector. The following pins are relevant:

1,8,9,15: 5V power
4,5,12: GND
2,7,10,14: buttons 0,1,2,3

(the other pins are axis 0, 1, 2, 3, they are not used in GrIP mode).

When you use only one gamepad, buttons 0 and 1 are used as data lines. Button 0 is a 20kHz clock. On each rising edge of this, you can read the state of button 1. Frames are 24 bits long and holmd data as follows:

0 1      1     1      1    1
0 Select Start R2     Blue
0 L2     Green Yellow Red
0 L1     R1    Down   Up
0 Left   Right

The frame starts with a start bit, then 5 bits set high. Since the button data is split in 4-bit words with a 0 interleaved, there can't possibly be 5 set bits anywhere else, this makes it possible to detect the start of a frame.

Transmitting a full frame at 20KHz will take exactly 1.2ms. This is more than fast enough. It's likely that Gravis drivers on windows only polled the gameport only 20 or 25 times per second (or even less), and waited up to 2ms for a frame start. This was the only way for them, because these gameport buttons are not triggering interrupts.

When there are 2 joysticks connected, the second one uses buttons 2 and 3 exactly the same way. The Gamepad Pro has a pass through connector that swaps buttons 2 and 3 with 0 and 1 for the second device, like any Y-doubler joystick cable does.

My plan is to use a Stellaris Launchpad LM4F120 as an adapter. Why ? Because I have one and want to try playing with it. More interesting, this board has 4 SSI/SPI channels and they can be configured for up to 16 bit frames (where an AVR can only do 8 bits). Since our frames are actually 24 bits here, we'll have to cheat a bit. The plan is to use 2 12-bit frames. Another problem is since the bits come in in a continuous flow, there's a risk of getting out of sync. What I will try is configuring the SSI, reading 2 frames, and see if one of them starts with 0111110. If so, the system is in sync and should stay so forever. Else, wait for 1/20ms, reset the SSI and try again. This should shift by one bit until we get it right. If this approach fails, I'll have to revert to using GPIO and external interrupts. At 20kHz I think the Launchpad can handle it, even with 4 gamepads plugged in. Since the USB is handled in hardware I shouldn't run into as much problems as my amiga keyboard to USB adapter.

Discovering the STM32F3 Discovery

So I just got this STM32F3 Discovery board. This is a development board from ST with a Cortex M4 chip, the mandatory leds and buttons, and some accelerometers and sensors.

The main problem is, as often, ST only offers code samples for commercial development environments. And I'm more of an open-source kind of guy. So let's setup some toolchain with free software.

First of all, get the files, this will be more convenient. This archive has the OpenOCD config file, the linker script, startup code, Makefile, and a stupid C code to show it all works (not even blinking a LED!).

Programming the board

That's the easy part. The STM32F3 Discovery has an embedded STLink/V2 interface. A nice thing about it is there are jumpers that allow to use the STLink part to program another device. However, there's a catch: the STLink can only be use to program STM32 and STM8 chips. It's not as flexible as other JTAG adapters.

Unfortunately, STM32F3 support is not part of OpenOCD sources yet. They have a patch set waiting, however:

Do not use OpenOCD 0.6.0 release packages, they don't have these patches in. You will need to get the sources from git and apply the patches above. Then, building OpenOCD is a rather straight-forward process (at least under Linux):

./bootstrap
./configure --enable-maintainer-mode --use-stlink
make
sudo make install

you need to enable access to the STLink hardware for openocd. Create the file /etc/udev/rules.d/99-stlink.rules and add :

ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", MODE="0666"

Then test everything is allright. We use the config file for the STM32F4 since OpenOCD doesn't provide one yet for the STM32F3 discovery. They are close enough for this small test, but we'll need a more specific one later on.

Enter the following commands:

openocd -f /usr/local/share/openocd/scripts/board/stm32f4discovery.cfg &
telnet localhost 4444
reset init
reset run

When you enter 'reset init', the STLink should reset the CPU and the ledswill stop blinking. 'reset run' will make it run again and the led should resume blinking. If everything is ok, you're (almost) ready to debug!

Compiling

The Cortex M4 chip is some kind of ARM CPU, so you need an ARM toolchain. There are several to chose from: Linaro, Sourcery CodeBench Lite, a plain vanilla gcc, and so on. I used Sourcery Codebench, because I already have it installed. But it shouldn't matter anyway: we're not going to use their linker scripts or standard library at all. Just make sure you have some arm-none-eabi-gcc or similar compiler available in your PATH.

Linker script

To make it easier to use different toolchains, it's better to use our own linker script. I derived one from here.

The linker script tells the linker about several things. It defines the memory areas available in the chip, then tells where each section generated by the compiler must go. For example, all code sections are usually allocated in flash memory, while the variables are put in the RAM alongside the stack. Reset vectors usually need to be put at the start of the flash so the CPU knows what to do when booting.

Writing a linker script is not as hard as some toolchain-provided ones make it sound. If you only want to write plain C code, you can get away with something very simple. I plan to use C++ as well, but that doesn't add that much more stuff. I added comments to the linker script, so you should understand what's going on.

Startup code

An usual C program starts with a main() function. However, when working with microcontrollers, there are some things to do before you can reach it. These tasks are performed by the boot code, usually in a function named _start or something similar. This includes setting up some things required by the C language:

Setup some hardware so the C code can be used at all (on more complex devices this could include initializing SDRAM controllers or so, on CortexM3 there shouldn't be much to do)
A stack, so we can call functions, pass parameters and return (on Cortex M this is done by the CPU hardware as part of the reset handling)
Initialize all the global and static variables (so you thought that was done magically?)
For C++, call global constructors so the global objects (if any) are in a coherent state,
And finally call the main() function, eventually with the argc and argv parameters (but most of the time you don't need that)

Check everything is ok

With a fairly simple program it's easy to look at the final elf file using the

arm-none-eabi-objdump -d

command. This will dump a complete disassembly of the code, so you can check the reset vectors are at the right place as well as the startup code.

The code should start with _start, which will point first to the stack (somewhere in RAM), then to the reset vector which is stored right after it. See the startup.s file to see how that's made.

Debugging

We'll be using OpenOCD again. While we used the TCL interface to quickly try it out before, OpenOCD is really meant to be used together with gdb. This way, it's possible to debug your code on the chip just like youwould debug any unix application on your PC. How nice is that ?

So, let's load our executable now !

openocd -f /usr/local/share/openocd/scripts/board/stm32f3discovery.cfg &
telnet localhost 4444
reset halt

flash erase_sectors 0 0 127
flash write a.out 0x8000000

So, the first step is to reset the CPU and halt it to make sure it isn't runnning code from the flash while we're erasing it. Then, we erase the flash, bank 0, sectors 0 to 127 (that's the whole flash of this chip). Finally, we write our new code. Notice the 0x8000000 offset: while the code is executed from address 0, the flash must be written from address 0x8000000. This is related to the way the STM32 chip can boot. Depending on the state of the BOOT0 and BOOT1 pins, the address 0 will be mapped to eitehr the flash, the SRAM, or the system ROM holding ST bootloader. But writing can only occur at the "e;real"e; flash address.

Now that our program is flashed, let's attempt to debug it. Exit the openOCD telnet prompt, but leave OpenOCD runnning. Now connect to it with GDB:

arm-none-eabi-gdb
target remote localhost 3333
file a.out
stepi
break main
cont
step

First we connect to the OpenOCD server through the GDB port. Then, we load the file to get the debugging symbols from it. The first stepi command is to sync gdb with OpenOCD. From then on, we can set breakpoints, and run/debug the program as usual. Happy hacking!

Back from BeGeistert

I'm heading home from the BeGeistert event that just ended today.

For those who don't know, BeGeistert is the european meeting of all Haiku (and BeOS) developpers and enthusiasts. This year, Haiku has seen its third alpha release, and we feel that R1 shouldn't be too far.

So, what happened there ? Over the weekend we had multiple conferences. The first one on saturday morning was a discussion on Haiku's release process and roadmap for the future. We didn't have time to solve all the problems, but at least one important decision was taken : after delaying the switch to git to after alpha3, then after gsoc, we finally decided it was about time to actually flip the swith. This is scheduled for the 12th of November.

Speaking of Git, Oliver Tappe made a talk about how to use it and the main differences with the current Subversion, and presented the work done so that Haiku developpers don't get lost.

Then, there were talks from Ingo and Oliver about package management, with an impressive demo of the current status It's working, but there are some problems with it like deskbar replicants not working anymore because of the readonly nature of packages (that was solved later during the coding sprint).

Stippi presented us the layout API and some examples on how to use it. The Layout API is an extention to the interface kit that allows much more easier design of window layouts.

FranÃ§ois Revol presented us a proposal for UXA, an unified extended attribute scheme to efficiently share attributes between different OSes. While many filesystems and OS now support attributes like Haiku (NTFS, ReiserFS, ...), they all use their ownscheme and the conversion from one to another isn't always a reversible process.

We also had a presentation of an application called VOPTOP, which is a nice peer-to-peer VoIP chat application. The main feature is it uses peer to peer routing to make the communication. This makes it needed to use encryption to make sure one pf the peers doesn't spy the communication.

Finally, Matt Madia told us about the status of Haiku, Inc. Besides helping with the funding of BeGeistert, they are paying mmlr for a full-time year working on Haiku, which is likely to bring us much nearer to R1. The donated amount to Haiku, Inc. this year was rather impressive, which makes it possible to think about more contracts for Haiku developpers, but also things such as giving Haiku shirts to people showing out Haiku at various free software conferences (to strenghten the image of the project).

Axel proposed a patch hour on sunday. An ongoing problem in Haiku is the unability to handle patches submitted by users on Trac. Our policy is to review the patch, and ask the author to improve it. Quite often several rounds of improvements are needed, and people don't react too fast or give up on the amout of work needed to get the patch in. So, the patches tend to accumulate in trac and never get commited. They get out of sync with svn trunk, and it is not possible to apply them anymore. So, Axel took the list of 144 patches waiting on Trac, and wrote the ticket id of each of them on a piece of paper. Each of us was given 5 tickets to look at and make a decision. Either cleanup and apply the patch, or reject it if it doesn't work. At the end of the hour, about 40 tickets were closed. Some of us continued looking at the list over the week, and now there is less than 80 patches left, so the list has decreased by half.

As the weekend was over, the coding sprint started. 9 developpers were present this year : Matt Madia, FranÃ§ois Revol, me, Olivier Coursiere, Ingo Weinhold, Michael Lotz, Oliver Tappe, and Rene Gollent. With the imminent switch to Git, Matt worked on getting a buildbot running with it to replace Build-O-Matic that only does SVN. However, he ran into some weird problems with building the now 10 years old gcc2 on FreeBSD, so not everything is working yet. FranÃ§ois worked on bringing the 68k port of Haiku back in compiling state, as it was broken by some architecture changes. This was a success, as we can now run KDL on the aranym emulator. The work stopped at needing a build of the ICU package, which is a bit painful to do for platforms other than x86. Olivier worked on Lazarus, a Qt-based Delphi clone that now mostly runs in Haiku. He also made some stress testing of Haiku by copying the OpenOffice sourcecode around. Eventually, he found a bug in DiskUsage and fixed it. Michael and Ingo started tracking a memory corruption bug that may be the cause for the few remaining cases of FS corruption. But this ended up in writing KDL tools for tracking memory use, which will come in useful to track memory leaks, looking at pages owners and similar stuff. Oliver worked on fixing our wchar_t support. He got it working but needs to test compatibility with BeOS applications. The change involves the compiler support for wchar_t, and any application using that needs to be rebuilt. If we can't get it working in a way compatible with BeOS, it's likely that only gcc4 built parts of the system will get the fix. Rene Gollent worked on some TODOs for the debugger. One part was saving and resoring the view layout of Debugger accross sessions. The other was starting to add a CLI mode. When both are done, Debugger will replace GDB as the default debugger for the system. The CLI mode is needed mostly to debug app_server crashes. I worked on various areas of the system, but most notably reworked (again) the notification windows (I'm now rather happy with the result), and fixed bugs in the game sound API which now seems to be working fine.

Overall this coding sprint week was very productive, with several hundred commits improving the Haiku codebase. This also apparently boosted donations to Haiku, Inc. quite a bit. I'm ready to attend the next one.

RSS feed generator

Any modern website needs an RSS feed. I added the feature to PulkoCMS.

The script is rather simple: it looks for all articles in the main category and create matching RSS feed entries. Since the main category has links to the most recent articles, this works rather well.

The code is not too clean (yet). I should start cleaning up and extract common stuff with index in an helper file, before it becomes a copypaste mess!

Get sourcecode

Publishing the recent articles on the homepage

I decided to show the recent articles from all the categories on the hormapge. To do that, a small script in the /etc/cron.daily folder is enough.

This will delete all the symlinks in the main category, then recreate links to most recent articles in all categories.

The script will also create links to the comment files, so the comments will also be forwarded to the homepage.

Since there is no database, the website is static. So there is no real way to do queries. This is not really important, because :

You usually know when you publish a new article, so you can run the script by hand at that time,
You can also put the script in a cron job so that it works automagically. The only drawback is it will take up to 24 hours for your articles to go on the homepage (I do run the script daily).

I split the script in two files, because my sh skills are limited. It should be possible to do it in one file. If you do it, tell me so.

Part one, script to actually run (as a cron job for me, put it in /etc/cron.dayly)

#!/bin/sh
cd /path/to/pulkocms/cat/
find -maxdepth 1 -type l -delete -name "*.{article,comment}"
find . -wholename "*/*.article" -type f | xargs -d\\n ls -t1 | head | xargs -d\\n -L1 /var/www/pulkocms/dolink ;

And here is the dolink script that creates links.

#!/bin/sh
ln -s "$1" .
ln -s "`echo $1 | sed -e 's@\(.*\)article@\1comment@' | sed -e 's@ @%20@g'`" .

Some explanations. The first script will first delete all the symlinked articles on your home page/main category. It goes to depth one so you can have symlinks in other categories if you want (for multi-categories articles). It also delete the linked comment files.

Then, it looks in all categories for all article files. It pipes them to ls -t which sorts them by date. Head takes the 10 newest files and and send them (one at a time) to the dolink script.

dolink then just create a link to the found article in the main folder. It also link the comment file (which may not even exist yet). There's a subtle trick, the comment-file has its name url-escaped, so we have to fake that with sed. I chose to only replace spaces, but you can do more if needed.

Anyway, tell me if you improve it in anyway, or if you otherwise use and enjoy PulkoCMS!

Some projects

Some time ago I set up a trac install on my server to put all my running stuff. As I ended up using the provided wiki for tech documents, there is nothing visible on this website. This article list all these projects so they are linked from somewhere, maybe this way Google will index them better.

Project list

Configuring MSYS for real work

People always request Windows binaries for some of my project, so I'm using a fairly complete MinGW/MSYS setup to get this done. However, the default setup for MSYS is not very efficient and doesn't manage to blend well in a Windows install (which is kind of expected). Here are some tricks to make it behave a bit better.

Bash prompt

An improvement on my existing "exit-status-colored" bash prompt. In Windows the path get long very easily (starting with "/c/Document and Settings/user/My Documents" before you've even got anywhere!). So here's a bash prompt that looks just like the previous one, but truncates the path to the last 4 elements. It's rather useful for other OSes, as well.

function exitstatus {
 if [ "$?" -eq "0" ]
 then
	COLOR=32
 else
	COLOR=31
 fi
}

PROMPT_COMMAND=exitstatus

PS1='$(
 IFS="/"
 d=3
 p=($(echo "\w"))
 e=$((${#p[@]}-1))
 P="\w"
 if [ $d -lt $e ]; then
 b=$(($e-$d+1))
 P="${p[$((b++))]}"
 for ((;$e-$b+1; b++)); do
 P="$P/${p[$b]}"
 done
 fi
 echo -n "\[\e[01;$COLOR;40m\]\u@\h\[\e[39m\]:\[\e[01;34m\]$P \[\e[0m\e]0;$P\$\a\]\$ "
 )'

While you're setting up bashrc and profile, you likely also want to setup $EDITOR, and the usual ll and la aliases (to ls --color).

Terminal emulator

The default setup uses Windows' DOS shell window to run bash. This gets annoyingvery quickly : it is not resizeable and has a lot of other bugs. I tried Console2 for a while but wasn't too happy with it either. The MinGW-provided rxvt seems to work fine. MinTTY looks interesting, but I didn't notice it before I was done with rxvt. Maybe next time...

Anyway, the default settings for rxvt are not too nice. I did some changes to make it a bit nicer and more useful. The first step is to open MSYS.BAT and replace the rxvt start command (start %WD%rxvt ...) with this:

set HOME=/home/USER
start %WD%rxvt -backspacekey ^H -sl 2500 -fn "Lucida Console-11" -fb "Lucida Console-11" -sr -geometry 132x50 -e /bin/sh --login -i

The HOME variable is set so rxvt can find .Xdefaults, and I also changed the font, increased the window size, and removed some color-related options.

Next step is to add a .Xdefaults file in the aformementionned HOME directory. There we'll setup the colors to look a bit nicer. Notice I used the same font for bold and normal text (rxvt bold rendering looks bad). So I set up different colors for bold and non-bold, so I can see all the 16 colors (rxvt could support up to 256, but this is not compiled in the mingw version). Here's my colorscheme.

Rxvt*color0: black
Rxvt*color1: orangered
Rxvt*color2: forestgreen
Rxvt*color3: gold
Rxvt*color4: dodgerblue4
Rxvt*color5: indigo
Rxvt*color6: cyan4
Rxvt*color7: azure3
Rxvt*color8: darkgrey
Rxvt*color9: crimson
Rxvt*color10: darkolivegreen1
Rxvt*color11: darkorange
Rxvt*color12: dodgerblue
Rxvt*color13: deeppink
Rxvt*color14: aquamarine
Rxvt*color15: white
Rxvt*background:gray7
Rxvt*foreground:aliceblue

More apps

Now install vim and svn (tortoiseSVN provides svn command-line client as an option in the installer), add them to bash path, and you're ready to go.

A little annoyance left : when started from bash, vim will read config in /home/user. When started from anywhere else, it will read in document and settings/user instead. So you have to copy your vimrc and vimfiles in both places.

IUP portable user interface

Just a quick note to say I started a project with IUP as the framework for user interface. After spending some time with Qt and wxWidgets, I've finally found an UItoolkit that just does what's expected. No need for a precompiler, no replacement of my main function by some wrapper, no rewrite of the C++ STL.

IUP is written in C, but has a nice attribute-based interface that makes it very easy and pleasant to use. I've made good progress on building my windows and the layouting system is nice to work with (still fighting with Qt one...). IUP is cross platform as it uses either comctl32, GTK or Motif. I think I'll write an Haiku/BeAPI backend for it as it's going to be rather useful.

It's quite easy to install in MinGW, just get the prebuilt binaries (either dll or static linked) and includes and drop them at the right place. No need to recompile for hours like wxWidgets.

I still have to see how integration of custom widgets is possible. This gets useful quicker than one may think, as soon as you need an hex-editor, a music-tracker like interface, or something similar. But these seem to be handled by IUP with a generic "grid" control that looks quite flexible. In wxWidgets both of these were a mess, with no easy way to do a custom control like an hex spinbox, and a button grid giving very bad performance. Having to manually call freeze() and thaw() on widgets got boring really quickly. Not to mention the complete lack of threading support...

Let's see how it goes in a few weeks!

IUP with C++

While the documenation suggests a way of using IUP in C++ and encourages it, I was not so happy with using friend functions or static methods. So I came up with my own solution involving a bit of C++11 magic (variadic templates). The result is the IUP++ class that reigsters itself as an IUP callback (with any arguments) and forwards the call to a C++ object and method. It's used this way :

Callback<Gui>::create(menu_open, "ACTION", this, &Gui::doStuff);
Callback<Gui, int, int>::create(toggle, "ACTION", this, &Gui::doMoreStuff);

Where Gui is the class you want to answer to the event, menu_open and toggle are IUP handles to UI objects, "ACTION" is the callback name, this is the object to forward the event to (an instance of Gui), and doStuff and doMoreStuff are methods called. Notice the Callback also needs the parameters to these - that's the second "int" in the second example (the first one being the return type, that defaults to int if missing, but is needed when you add parameters). I'm looking for suggestions on how to make this simpler, as there is still some repetition in it...

Smarter vim filetype detection

Vim is, as you may know, is my favorite editor for all development purposes. The syntax highlighting is powerful and extensible easily. Most of the time, the file type detection for this is based on file extensions. Works well, unless you have files named .src or .asm for assembly language on different CPUs...

Vim documentation only shows how to set the filetype guessing from the file extension. Here's an example of doing something a bit more smart.

The idea is to put the CPU name on the first line of the file (in a comment). Then use the powerful regexp match features of vim to detect it:

; vimfiles/ftdetect/z80.vim
au BufRead,BufNewFile *.z80	set filetype=z80
	; The usual way to do it for clear file extensions

func! s:detect()
	if getline(1) =~ z80
		set filetype=z80
	endif
endfunc

au BufRead *.src	call s:detect()
au BufRead *.asm	call s:detect()
	; And the smart one. Note it is useless on BufNewFile,
	; as the file will not have the header yet.

Do a similar file for each of your CPUs.

Note, it should be possible to scan fr the use of particular mnemonics to go without the header, but that requires a bit more work to identify many CPUs. Any volunteer ?

Programming ARM chips with OpenOCD in Debian

I bought an LPCXpresso board from NXP for toying around. Unfortunately, the JTAG interface built in this board can only be used with codeRed tools, and the free edition has a limit of 128k of flash memory. I want to use freely available tools, so I cut the board to remove the JTAG part and plugged in my Altera USB-blaster instead.

However, I quickly noticed that the version of OpenOCD built in Debian doesn't work well with it. Searching the web shows it's a bug in libftdi, and you have to use the closed-source libftd2xx instead. The installation works fairly well, just get libftd2xx from FTDI website, copy the so files in /usr/local/lib, then download and compile OpenOCD.

LibFTD2xx install

cd libftd2xx1.0.4
cp build/x86_64/libftd2xx.so.1.0.4 /usr/local/lib
pushd .
cd /usr/local/lib
ln -s libftd2xx.so.1.0.4 libftd2xx.so
popd
cp ftd2xx.h WinTypes.h /usr/local/include

OpenOCD 0.5.0 install

./configure --enable-usb_blaster_ftd2xx
make
# ... fix a warning as everything is built in -Wall mode ...
make
# there seem to be a bug with OpenOCD tools, where it forgets the -lftd2xx here. Do it ourselves :
gcc -std=gnu99 -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o openocd main.o  ./.libs/libopenocd.a ../jimtcl/libjim.a -ldl -lftd2xx
sudo make install

Address change

Following some problems with my router and DynDNS settings, the site is now available at http://pulkomandy.lexinfo.fr . Please update your bookmarks.

Site launched

C'est maintenant officiel : ceci est le nouveau site web de la pulkoteam!

Voilà, c'est tout... bonne visite

Ah oui, je ne savais pas trop où mettre ma vieille page avec des logos divers vectorisés... donc voilà ça c'est fait.

Hello World

This is the new server of the PulkoTeam! Enjoy your stay here.

Everything is still work in progress, so please be patient.

Warning: this site looks simple, but it uses css3 features and some other things that require a modern browser. It was tested with Opera 10, Firefox 3, Internet Explorer 8 and Chrome 3. Anything older may not work. Don't complain, upgrade your browser or disable css.