Contact:
oak (at) helsinkinet fi
Open Source Software
Contents:
- Projects I've contributed to
- My own Atari projects
- My own (multi-platform) projects
- My larger Python programs
Projects I've contributed to
I list here only projects to which I've done larger contributions. There are too many projects to list here all the patches (e.g. for Valgrind) and bug reports I've sent during the years.
Projects I'm currently involved in
- Mesa - Intel 3D driver for Linux: performance analysis and some tooling for that.
- Hatari - Atari ST/STE/TT/Falcon emulator: one of the core developers. I've done the out-of-process Python console interface and PyGtk GUI for it, automated emulator TOS bootup tester, written large part of the debugger and all the profiler functionality for the CPU & the DSP, maintain the GEMDOS HD emulation and do misc other emulation improvements + bug hunting. (hobby)
- EmuTOS - GPL ROM for 16/32-bit Atari computers and emulators. I've added all the Line-A drawing functions to it, cleaned up its code and done quite a bit of testing & writing some small test programs for it. I maintain its games compatibility list and improve Hatari debugger and profiler to help in investigating EmuTOS issues... (hobby)
Projects I've been involved with earlier
- BadMooD, a Doom I/II port/rewrite for Atari Falcon (16Mhz 68030 @ 16bit bus, 32Mhz DSP). Hatari profiling support: BadMooD tracing / profiling automation scripts, for finding slowest frames and producing CPU + DSP profiles (with callgraphs) for them. Debugging of Hatari emulation specific issue like MIDI interrupts. (hobby)
- Maemo tools
and their version control
for the 18 tools Nokia open sourced (work). Most technically advanced
or extensive of these (18) system measurement and analysis tools are
probably the resource usage tracing tools:
- Functracer - a function tracer that can attach to any functions in a remote process that are listed in its libraries debug symbols files and trace their calls, or - attach to a set of functions predefined in given Functracer plugin and trace resource usage of these functions. Currently supported resource sets include: memory allocations, file descriptors, SYSV and POSIX shared memory segments, threads, Gobject references. Unlike ltrace, this supports also threaded programs and library-library calls. Unlike latrace, this can catch calls that don't go through .PLT tables. Unlike Valgrind, this can attach to already running processes. Downside of ptrace() usage is that every architecture and CPU instruction subset (like ARM thumb) requires specific support and currently this supports only 32-bit x86 and ARM.
- Sp-rtrace - a resource tracer based on LD_PRELOAD. Unlike Functracer, this is CPU architecture independent and contains a large number of post-processing utilities (which can be used also to post-process Functracer data). Graphs include resource allocation timelines, top-down callgraphs, physical memory page utilization etc. This can be used to catch leaks which Valgrind Memcheck and Massif tools don't reveal, because former is mostly useful for finding pointer loss and latter gives only bottom-up view and doesn't help with smaller leaks. Sp-rtrace can be also do trace symbol resolving at post-processing phase on another machine if the target machine doesn't have enough memory for this.
- Gramps - Genealogy program: statistics and graphviz plugins, Finnish localization (about 4000 strings + date & relationship plugins) for v2.x and v3.0. (hobby)
- Airstrike - 2d dogfighting game: wrote nearly half of the code & did half of the ray-traced graphics. (hobby)
- Requirements + testing for following X development tools (coded by Mathew Allum, known later from his OpenedHand fame): Xephyr, XResTop and XResponse. (work)
I've also created most of the graphics (which Pov-Ray sources are available under GPL) for the SolarWolf game implemented with PyGame. (hobby)
My own Atari projects
As I'm involved with Atari emulator and TOS (ROM) projects, I've also written some Atari specific programs and ported existing Atari programs to ANSI-C & newer C compilers so that they can be updated and built for newer/current Atari machines like Firebee.
Most of these programs are games, like:
- Ballerburg
- Filler
- PUNSSi
- ST-concentration
For more information, see my Atari programs page.
My own (multi-platform) projects
These are older projects originated in 90's when I had more time for my own projects. Below are listed still available sources and binaries for things which I have ported for several systems. I update them occasionally so that they build fine at least on Linux.
W Window System
In total the whole W window system contains about 150 000 lines of C-code of which I've written about a third. I became its maintainer in 1998 when Tesche and Kay became busy with other things.
Components
| Package: | Contents: |
|---|---|
| console-board-games | 5 networked, console based board game user interfaces + computer player daemons for most of them |
| libw1.4 | The W Window System client library (Wlib) |
| libw2x1.4 | The Wlib-on-X emulation library (Wx2) which allows running Wlib and Wt based programs with the X server |
| libwt0.9 | The W Window System GUI toolkit library (Wt) |
| wlua | A Lua interpreter with the W Window System support |
| wws-apps | More advanced W Window System applications |
| wws-base | The W Window System server and its basic applications |
| wws-dev | The development files for the W Window System libraries |
| wws-games | The W Window System games, dozen Wlib & Wt based single player games & toys and Wt GUIs for the above meantioned networked board games |
| wws | Metapackage for the W window system with scripts and docs |
Applications include for example HTML v1 browser and a color terminal emulator. The server supports monochrome, 2, 4 and 8 bit graphics natively. Other bit-depths work through libSDL (for testing purposes).
Source package has also my code to get Heretic, HeightField Labratory and XMountains programs work with WWS.
WWS has at some time been working on Linux (on top of SDL, GGI, framebuffer/GPM or SVGAlib), SunOS, Amiga NetBSD, Atari MiNT and MacMiNT. The SDL backend is currently the most tested one.
For more information on (older version of) WWS, see my historical pages.
Sources
Debianized sources for W are about 1.6MB:
To build the sources on Debian derived distributions after downloading them to "wws" directory, just do:
$ cd wws $ dpkg-source -x wws_1.4.5.dsc $ cd wws-1.4.5/ $ dpkg-buildpackage -uc -us -b
Then install the produced packages normally:
$ sudo dpkg -i ../*.deb
You can start WWS as normal user under X11 (for framebuffer access you would need root rights):
$ startw
On other platforms/distributions, look into the top level README in the extracted source package for the build instructions.
Mortar, a portable, multiplayer artillery game
Mortar is a simple "Scorched Earth" game clone with raytraced graphics. It can be compiled for Linux 8/16-bit frambuffer, SDL, GGI, DOS, Amiga or Atari. Other than the SDL and Atari backends haven't been tested for a while though.
Despite the game itself being fairly simple, it has 11 KLOCs of C-code. For portability reasons game engine cannot use any other libraries beside C-library (and couple of POSIX functions), so it needs to implement everything itself, even handling of graphics data. Platform specific code (in win-*.c and snd-*.c files) is there just to change palette, open/write to framebuffer/window, get keys from the user, and (optionally) play sounds. Timings code is also somewhat platform specific.
Game itself works internally with (chunky) 8-bit graphics with palette and platform specific code handles outputting it. In Atari case this means chunky to planar conversion to screen bitdepth on every update, which slows down things. On higher bit-depth screens, it may increase speed.
Sources for the latest version with Debian packaging (540KB):
Above sources include also a Qt GUI toolkit / C++ based settings editor and game launcher for the game:
Sources for an earlier version with Debian packaging for Maemo (524KB):
Mortar for N770/N800
An early Maemo binary package of Mortar (444KB) for the Nokia N770/IT2006 (maybe also later). The keys in the game are following:
- Fullscreen
- Switch the game between fullscreen and windowed mode
- Decrease (-)
- Switch to previous weapon
- Increase (+)
- Switch to next weapon
- Up/down
- Increase/decrease the shot power
- Left/right
- Turn the cannon left/right
- Select
- Shoot
- Back/Escape
- No functionality. To exit the game, switch to windowed mode and press the window close button until game exits.
- Menu
- Saves a game screenshot in PPM format to "Images" folder.
Clac calculator
Clac calculator has readline support for the command line version (tested on different Unix versions, MiNT and DOS) + a GEM GUI interface for Atari ST and later machines. There are also filter version of the calculator (which accompanied the commercial Atari Edith text editor) and a client-server one for the Atari MiNT OS. It understands operator predecence, hex/bin/dec/oct modes, trigonometric functions and complex number calculations. It was my first larger C program.
Sources for the latest version + atari binaries (350KB) with Debian packaging:
Naputus
Naputus is a really simple memory and reflex game I wrote in Python to test the PyGame SDL bindings. It's a re-creation of a non-computer game used in Finnish "Spede show" game show...
The sources are 38KB.
Larger Python programs
In case you're interested about my more advanced Python programs than "Naputus", I've also written in Python for example:
- the Python+Gtk UI, profiler data post-processor / callgraph generator, TOS + HW bootup tester and remote console programs included with Hatari emulator
- W window system library bindings + graph classes and some simple programs using them (tester, turtle graphics, L-system parser/viewer, chat server + client) in plain Python (i.e. no C-extension is used, bindings write C-structures to socket)
- 68000 CPU instruction encoder
- callgraph script for sp-rtrace
- Statistics plugin for the Gramps genealogy application. Frequent discussions with Alex Roitman helped me to grok Gramps plugin API and him in his API refactoring (old one required a lot of boilerplate code)
- Large parts of the (somewhat ugly) HTML report generator for sp-endurance
- Python scripts to generate packing for Busybox binary and a set of symbolic link packages that correspond to GNU SW packages in Debian, for Maemo. This was done to make it possible for users to replace Busybox utilities with GNU ones, using dozens of (recompiled) upstream Debian packages. (Most of the work went to researching how well different Busybox utilities correspond to GNU utilities, differences in alternatives & essentials, package dependency bugs in different Debian versions etc)
