Docs + other stuff
Atari, Hatari and games
Pages from last century
Links and trivia
oak (at) helsinkinet fi
Open Source Software
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
Projects I've been involved with earlier
- BadMooD, a Doom I/II
port/rewrite for Atari Falcon (16Mhz 68030 @ 16bit bus, 32Mhz DSP).
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:
- 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.
- 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.
- 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
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
Most of these programs are games, like:
For more information, see my Atari
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.
|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
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.
Debianized sources for W are about 1.6MB:
To build them on Debian derived distributions after downloading them,
dpkg-source -x wws_1.4.5.dsc
dpkg-buildpackage -uc -us -b
Then install the produced packages normally (with dpkg,
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
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
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
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:
- Switch the game between fullscreen and windowed mode
- Decrease (-)
- Switch to previous weapon
- Increase (+)
- Switch to next weapon
- Increase/decrease the shot power
- Turn the cannon left/right
- No functionality. To exit the game, switch to windowed mode and
press the window close button until game exits.
- Saves a game screenshot in PPM format to "Images" folder.
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 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"
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,
data post-processor / callgraph generator,
+ HW bootup tester and remote console programs included with
- 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
- 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)