Defense of my dissertation
On Monday, I successfully defended my dissertation about "Securing
Graphical User Interfaces". In the thesis, I describe how to
resolve the conflict between four principle goal of GUI architectures,
which are security, compatibility, performance, and quality
of service. The presented techniques are the outcome of various
exhaustive experiments conducted during my time at the university,
in particular DOpE, Nitpicker, Scout, and Overlay WM. I plan to make
a slightly refined version of my thesis publicly available soon.
In addition to the presentation of my own work, I had to give a
"scientific talk" about a topic unrelated to my research.
I presented an intriguing approach of using machine learning to
improve compiler-optimization heuristics brought forward by the
European MILEPOST project.
Genode FX on the Virtex4-based ML405 evaluation platform
Since the initial release of Genode FX, support for other boards than the
Spartan3A Starter Kit had been added. Thanks to community contributions, the
project works now also on S3AN boards and support for S3E board is in the
works. Furthermore, Matthias Alles ported Genode FX to the Virtex5-based ML507
platform using the PowerPC 440 core. This week, I further increased the number
of supported platforms by porting Genode FX to the ML405 evaluation platform.
As this porting work was a good opportunity to document the process, I created
a porting guide document that I will release soon. The ML405 version will be
made publicly available with the next official release that is planned for
Genode FPGA Graphics project launched
The FPGA-graphics project that Matthias Alles and me conduct together since
2005 raised quite some interest, which motivated us to publicly release
the source code of our hardware and software components and to continue
the development as an open-source project. In addition to maintaining the
open-source version, we at Genode Labs offer commercial licensing options
and support. You can read the official release announcement here:
Genode Labs newsletter
Have you subscribed to the Genode Labs newsletter, yet?
To keep up-to-date about our progress at Genode Labs, you may check out the link below:
First release of the Genode OS Framework
We at Genode Labs are very happy to announce the first official open-source
release of the Genode OS Framework. The released source code contains
everything needed to build and run the graphical demonstration scenario
as seen at the front-page the genode.org website.
More detailed release notes and the source code are available from the
download section of genode.org.
Community website for the Genode OS Framework
The community website for our main project, the Genode OS Framework,
is online. This marks the beginning of conducting this project as
an community-driven development. To spawn interest of developers
in our project, we put a lot of energy in creating good architectural
and technical documentation including an API reference for the
complete base API. Furthermore, the site provides community resources
such as a Wiki, mailing lists, and our Sourceforge project.
In addition to creating actual content,
I did most of the web develoment work for both the Genode Labs company
website and the genode.org project website. In the meanwhile, Zope
and Plone have become pretty close friends of mine ;-)
BTW, we still rely on GOSH for our texual work. During the past
two weeks, the flexibility of this tool was extremely beneficial for
our work. And of course, I know the code of GOSH in and out, which
enables me to adapt GOSH to our needs in almost no time. Even
though I really like Docutils as stated below, GOSH is here to
Cool alternative to GOSH
Since 2003, I rely on my custom text-processing tool called GOSH
for all my textual work such paper writing, managing web content, and
writing technical documentation. In short, GOSH converts Usenet-style
plain text to different output formats such as HTML, Latex, or
manpages. Over the years, GOSH became a pretty mature and reliable
tool. I created my entire dissertation using GOSH without triggering
a single problem. Since I explored the world of Plone and ZOPE, however,
I discovered that there exists a much more powerful alternative called
Python-Docutils that are using a markup (restructured text)
very similar to the one I used for GOSH. Compared to GOSH, the
development of Python-Docutils is much more ambitious and vibrant.
Hence, I am thinking about switching to Python-Docutils in the midterm.
For an easy migration, I created a GOSH backend that outputs
restructured text (rst). Most of the basic text markups such
as accentuations, document structure, verbatim text, items,
enumerations, are already working. I will expand the backend
on demand to support more advanced features such as
tables, and cross references.
Genode Labs website launched
Two days ago, we launched the website of our company.
The website is realized using Plone3 and Zope, which is
a pretty powerful yet very complex framework. The design
and graphics are custom made. To get everything displayed
correctly with Internet Explorer was quite a challenge.
Exploring content management systems
With our company, we plan to launch two websites in the
foreseeable future. Of course we will have a company website
providing information about our product portfolio, our
offered services, and contact information. In addition,
we will create a dedicated project website for our
flagship product, the Genode OS Framework, which is our custom
OS framework previously codenamed Bastei.
For both websites, we need a content-management
system that scales towards typical community-portal functionality.
After some days of investigation, we settled on using
Plone/Zope, mainly because it seems to be a very mature
and scalable solution and there exists plenty of documentation.
Furthermore, we appreciate the fact that Plone/Zope is written in Python.
Starting my own company called Genode Labs
I just left the university to start my own company together
with Christian Helmuth. With this new startup company, we
strive to bring forward the practical application of the OS
technology that we developed. The official name of the company
is "Genode Labs, Feske & Helmuth Systementwicklung GbR". The
rather lengthy name is attributed to our chosen legal form,
which requires us to mention our names with the company name.
End of silence
During the last half year, this website was quite unmaintained.
There are plenty of reasons. First, having two children now
leaves very little spare time. Second, I worked hard to finish
my PhD thesis until the end of April. Now, the
thesis is complete and ready be submitted. Certainly, I will
have to refine the document according to suggestions by
reviewers but the major work is done. Third, I prepared
the launch of an own company that I will start together with
Christian Helmuth in mid of May. The volume of preparation
work was pretty demanding, primarily because of our lack of
sufficient knowledge about economics, law, taxes, and marketing.
To improve our competencies in these areas, we took part in
crash courses provided by a local institution called Dresden Exists,
talked with a lot of people, and spent time on studying.
My second son is born
Today, Christin gave bith to our second son Alan Feske at 10:24.
Alan weights 3880 g and he is 51 cm tall. Both Christin and Alan
are well and happy!
Sudden Fan of Death
It seems I am one of some-thousand unhappy Apple customers
who experience the famous Sudden-Fan-of-Death phenomenon
with Apple's iBook line of computers. From one day to another,
my iBook just stopped working for no reason at all. The web is full
of failure reports about this problem and I found some
valuable suggestions for interim fixes such as clamping the
notebook to a desk such that pressure is issued on a
particular part of the main board. By reading a bit further,
I learned that the problem is a chip that is loosening from
the motherboard because the soldering was not done right.
The suggested fixes had the effect of pressing the chip
onto the motherboard - with my iBook, these kind of fixes
worked...for some time. Then it started to fail again.
Two days ago, I decided to re-solder some of the pins of
the said chip and since then, my iBook works flawlessly
Development session with Charon
I just took one week off my regular job at the university
to spend my time with Matthias Alles and do some FPGA
Porting Bastei with L4/Fiasco to Gamepark's GP2X
Some time ago, I ordered a GP2X hand-held device and planned
to use it as an experimentation platform for Bastei on ARM.
In fact, the GP2X approximates very well a typical smart phone
platform of today, it is very well documented as its firmware
is based on Linux, and it costs less than 250 EUR.
During the last three weeks, I dedicated my spare time to
do this porting work. As a precondition for the actual development
work, I created work-flow tools for comfortably bootstrapping
a custom kernel on the GP2X. Rob Brown's SDK2x was of great help here.
For the actual porting work, I had to create new drivers for UART,
interrupt controller, timer, display, and user input specific
for the MMSP2 chip set and port Bootstrap and Fiasco to this
platform. This was my first experience with Fiasco hacking and,
to my surprise, it went pretty smoothly. The biggest issues
that I stumbled across had been getting the cache and TLB code
right and finding a problem caused by an ARM instruction in the
exception-handler-exit path that behaved unreliable on the specific
ARM core. After I managed to successfully execute Fiasco, I
ported the Bastei user land to this architecture. Thanks to
my existing ARM-specific work for Bastei, this process was
relatively straight forward. For accessing peripheral devices,
I decided to put all GP2X-specific driver code into one
single server because all devices share the same MMIO registers
anyway. At the moment, this server contains drivers for the
frame buffer and a user-input driver that is capable of
emulating a mouse from gamepad input. Finally, I was able
to run Nitpicker, Launchpad, and some example applications
on the device.
Bastei running natively on L4/Fiasco on PC hardware
I finished the work on my input-device drivers such that we can
use the PS/2 mouse and keyboard. Combined with Sebastian's
VESA video driver that initializes the graphics card by
executing the graphics card's BIOS code via an
x86 emulator taken from XFree86.
Furthermore, I optimized memory blitting for x86 by expoiting
MMX instructions. As a result, Nitpicker with Scout, DOpE,
Launchpad, and some further test applications are running
pretty responsivly on plain PC hardware.
Input device driver for Bastei
Based on Krishna's preliminary experiments some months
back, I created an input-device driver for
PS/2 keyboards and mice. The device part functions properly
but the Bastei session frontend is still missing.
Refined locking semantics for Bastei
To support controlled destruction of threads, I introduced
cancelable locks to Bastei's base framework and enhanced Core
to support the unblocking of threads. By using the new mechanisms,
threads are enabled to return to a consistent state, for example
by releasing held locks, before destruction.
C++ Parser and Coding-style checker
Managing coding-style consistency manually is a boring task.
Therefore, I created a C++ parser, which translates C++ source
code to an abstract syntax tree. This tree, in turn, is then checked by a
second tool with regard to coding-style compliance.
The C++ parser is written in Tcl and it is fairly complete.
I will enhance both tools on demand in the future.
Bastei's Core abstractions revisited
To support the upcoming work by Torsten Frenzel to create
a user-level debugger for Bastei, I enhanced serveral
services of Core. For example, the CPU session can now enumerate all
existing threads of the session and the thread state
can be exported for each thread.
BasteiLinux and DOpE on Bastei
This place got a bit silent recently as I am currently working on the
text of my PhD thesis instead of doing development work.
However, there are some news regarding the Bastei OS implementation.
First, Stefan Kalkowski's proof-of-concept port of L4Linux to Bastei
works! That means that we have now a container for executing
unmodified Linux applications on top of the L4/Fiasco version of Bastei.
Secondly, I ported a version of my DOpE windowing system to Bastei.
It is executed as a client of Nitpicker. Guided by my experiences with
porting DOpE to Charon's FPGA board, I realized the port by turning
the DOpE server into a library that provides the same
interface as the original DOpE client library, but it contains the
complete windowing system rather than client-communication stubs.
This multiple-instanciation approach maximizes the isolation between
different GUI clients but maintains compatibility to existing DOpE applications.
Instruction prefetch trickiness
This weekend, I continued my work on the instruction prefetch unit
of my processor, which turns out to be quite a challenge. On one hand,
I want to support program memory with arbitrary latencies, for
example, to store the bootstapping part of the program in the ROM
of the FPGA (with a latency of only one cycle) and then dynamically
load other parts of the program into the SRAM (with a latency of
four cycles). On the other hand, I want to feed one instruction
per cycle to the decode unit of my CPU - but only if the pipeline
is not stalled. So there are a lot of conditions to consider.
For example, a conditional jump instruction may cause a prefetch
buffer miss. While fetching the required instruction, the fetch
unit has to feed NOPs to the pipeline and maintain the
old program counter value. I got my design to work but I am not
perfectly happy with it, yet.
Update of my overlay window management drivers for X.org
Some interfaces of X.org changed from version 7.1 to the 7.2 (now
called 1.3.0), for example the shadow fb module. My overlay
window management drivers for X.org, however, relies on this
functionality. I updated my Linux RAM-Disk to the current
Debian unstable version and adapted my drivers to X.org's changes.
Now, the Nitpicker setup works with the most recent Fiasco kernel,
L4Linux 2.6.21, and X.org 1.3.0.
Paper about dynamic RPC marshalling
I have written a paper about one interesing aspect of the Bastei
experiment. For this experiment, I implemented a C++ framework
for RPC communication instead of employing an IDL compiler.
Originally intended as an interim solution, the framework
turned out to be very convenient to use and to be fast.
Therefore, I conducted a detailed comparison of this new
approach against IDL as the de facto standard solution.
The resulting paper is entitled "A Case Study on the Cost
and Benefit of Dynamic RPC Marshalling for Low-Level System Components"
and it will be published in the SIGOPS OSR Special Issue on Small-Kernel Systems in July.
OpenGL on DOpE
Thomas Zimmermann ported the software-rendering version of
MESA to DOpE. He also creates some example programs, for
example GLXgears for DOpE. Very cool, indeed!
Bastei on ARM Platform
I ported Bastei to the ARM Integrator Platform. The porting
work went pretty smoothly. The few tricky things had been:
As a result, the Core of Bastei with all its services
runs on Qemu/ARM and loads the Init process. Init starts
to execute and tries to load further processes, which,
of course, are not there yet.
- Getting a simple L4env-based setup to boot on the
platform to have a working setup as a reference.
- Installing a cross compile toolchain. Crosstool is
a very handy tool for this purpose.
- Disabling hardware FPU instructions because Fiasco
does not handle the FPU on ARM.
- Enhancing the Bastei build system with some cross-development
- Applying some small generalizations to the Bastei ELF loader.
- Changing the thread creation code in the Bastei Core and
the user-level framework because the ARM calling conventions
function a bit differently than the x86 calling conventions.
- Porting of Bastei to use the L4.x0 kernel API instead of
L4.v2 as the ARM version of Fiasco only supports L4.x0.
I enhanced my fetch unit to use an instruction prefetch
buffer. This will become useful when the programs are
stored in normal SRAM instead of the internal ROM of
the FPGA. The SRAM has a latency of four cycles.
Therefore, a prefetch buffer of four instructions
seems appropriate. I have prepared the fetch unit to apply
different heuristics for predicting the instruction
addresses to fetch.
To prepare data-memory load and store instructions to be included
into my CPU design, I implemented support for controlling pipeline
stalls from the execution unit. My current plan is to issue memory
transactions already in the decoding stage such that the execution
stage only needs to check if the memory transaction got acknowledged.
Otherwise, the pipeline will be stalled until the acknowledgement
This way, successful write operations to the SRAM will not stall
the pipeline and thus, will enable maximum write troughput from the
CPU to the SRAM. Of course,
reading from memory will be much slower because of the 4-cycle latency of
Coding Week at Charon's place
Since I had some vacation days left from last year, I decided
to take some days off from job and family, visit my friend Charon
in Kaiserslautern, and tinker with his
custom-made FPGA board.
This week had been great fun. I am very grateful to Christin for
taking care for our son Kevin without me during this week. Also big
thanks to Charon for his hospitality and helpful advises. Development sessions
with Charon are always greatly productive and just a pleasure!
I took the following notes here and then during our session.
Got framebuffer working - the screen displays now a constant
image of noise. This indicates that the SRAM controller
is working. I also reworked my VGA timing code.
Analysed ISE build process and created a custom makefile
with all required dependencies. Now, working with VHDL
sources via VIM and GNU tools is much more convenient than
with using the ISE IDE (highly subjective).
SRAM works with second port and interleaved read and
write accesses via the two ports. Added byte select
signals to SRAM controller to support 16bit write
transactions. The testbench draws beautiful diagonal
Restructured and cleaned up the frame-buffer code. Introduced
packages. Started developming my custom CPU and outlined
the instruction and register set. I have implemented the
program ROM and the register file but these components are
not tested yet.
Started using the GHDL simulator. For this, I first created
proper build-system support for doing simulations and viewing
the results in gtkwave. Fetched first instruction from
program ROM. Added condition code register and program
counter. GHDL works excellent!
Got pipelined design to work. After my first attempt to loosely
couple pipeline stages via handshaking protocols and observing
the high number of wasted clock cycles because of the handshaking
overhead, I decided to go for a completely synchronous pipeline.
I think, this is the standard solution. Still, this was a nice
excerise. I implemted LDI (load immediate), LDU (load unsigned immediate)
and LDH (load upper half immediate) into the new design.
LDH is quite problematic because it combines the old register
content with some bits of the instruction word, thus reading source register.
Now all the typical pipeline-hazard problems arise. Because of
my four-stage pipeline (fetch, decode, execute, write back),
two NOPs are required between subsequenting LDI-LDU instructions
refering to the same register. I think, this is quite bad and
so I decided to resolve these pipeline hazards by back-feeding
results of the execution unit into the decode unit and the
execution unit itself. Charon told me that this technique is
called pipeline forwarding.
I furthermore tried out the 'generate' primitive of VHDL and
made the presence of my decode pipeline stage configurable.
Now, I started to work on tricky stuff namely the control
flow handling. The program counter corresponds to R15.
Therefore, jumps can be implemented a simple LDI instruction.
I struggled a while to reduce the pipelining effects on the
instruction level by introducing pipeline forwarding where
possible. Depending on the presence of the decode stage of
the pipeline, there are still two or three branch delay slots.
For looking at conditional branches, I need an ALU and
condition flags first. So I created simple ALU that features
basic math and logical functions and exports flags for
zero, negative, overflow, and carry. The condition bit mask
in the opcode corresponds to the m68k bcc bits.
Finished implementing the control flow primitives and
conditional execution into the CPU. Now the only thing
that is missing are memory read and write instructions.
To reduce the number of branch delay slots, I moved
the program counter register to the fetch unit instead
of accessing it via the normal register file and only
provide the current program-register signals to the
register file such that PC can still be addressed at R15.
Write operations to R15 by the execution unit are now
directly handled by the fetch unit. Depending on the
number of configured pipeline stages, there are now
1 to 3 branch delay slots.
After an exaustive Strombach-Session, I started tinkering
with Charon's digital camera module for his FPGA board.
I created a VHDL model that reads image data from the
camera, writes the pixels via my SRAM controller to the
memory and that features a VGA framebuffer that outputs
the same memory region. The result is an extremely smooth
camera picture on the VGA screen. When Charon and me did
the YUV2RGB conversion routine in hardware, we noticed
that certain bit patterns caused noisy pixels. The reason
was a bug in the timing of my SRAM controller, which I
Continued to play with the digicam and combined it
with Charon's audio Codec to let the YUV2RGB conversion
take the audio input as parameter for some real-time
color distortion. I also further improved the build
environment for simulating and synthesizing my VHDL
code. I also generalized the support for the board components.
Supporting other boards than Euterpe from the build
environment should be no problem now.
To sum up, this week had been extremely productive. I am
now very confident in the correct working of my memory
controller, have successfully built a frame buffer, my
custom CPU already works fairly well (only the data memory
interface is missing), and I can even sample a real-time
digicam image into the memory. Now, there are thousand
ideas in my head of how to combine all these things.
Telling you that I am excited about all this would be a barefaced
New GOSH version
Today, I released a new GOSH version that includes a new and much
improved table parser. Originally, the table feature was only meant
as an experiment but it turned out to be used very frequently by
a number of GOSH users. Apart from the new table code, I also refined
the Latex backend.
Design of the Bastei OS Architecture
During the last months, this place was quite silent - mainly
because I was busy with writing up documentation about past
work and with planning my personal future roadmap. I came to the conclusion that now
is a good time to lift the curtain about the Bastei experiment that
I conducted together with Christian Helmuth during the year 2006. Today,
I published a technical report about our new operating-system
architecture. You can find the document here:
The document describes the goals of our experiment, the structure of
the architecture, the interfaces of its key components, and it gives
an overview about frameworks for developing software ontop of
First stage of the Bastei experiment completed
Today, Krishna and me gave a research-group-internal talk about the results of
our experiments regarding our new operating-system design. Part of our talk
was a live demonstration of our result.
This day marks the preliminary end of my practical work on this project. From
now on, I will focus my attention to my actual PhD topic about securing
graphical user interfaces.
Krishna and me will summarize our experiences with Bastei in the form of a
technical report in the next weeks. Furthermore, we plan to release the
Bastei code base under GPLv2. (the release date is not fixed yet)
Launchpad for Bastei
Based on the code base of the Scout tutorial browser, I created a simple
launchpad program for starting and killing programs on Bastei. When launching a
program, its memory quota can be configured using the GUI. This is a very handy
tool to validate the quota trading concepts of Bastei for different scenarios.
Nitpicker C++ re-implementation for Bastei
For the planned demonstration of Bastei, we need a GUI. The obvious
choice was to use Nitpicker as the GUI foundation for Bastei. However,
the original Nitpicker implementation is written in C whereas the Bastei
infrastructure relies on C++. Instead of porting and integrating the
original Nitpicker C code to the Bastei platform, I went for a complete
re-implementation of Nitpicker in C++. I wanted to do that sometime anyway
because I was curios to compare the code complexity of a C++ implementation
against the C version.
The new C++ version is better portable (the core part has no
platform-dependencies at all) and more flexible (e.g., the graphics-backend
implementation is independent from the color depth). The code complexity of
the new and more powerful version is about the same as the old C version. (less
than 1,500 lines of code)
I added a section to this website that contains the history of my
past and current projects.
News items on this website became very rare during the last months. The
reason is my extreme busyness with the Bastei Project.
Krishna and me implemented all the basic infrastructure of
this new OS architecture including build tools, system abstractions,
the core components, test cases, and a preliminary demo scenario.
To summarize the Bastei development, everthing seems to be on the
right track and we both are looking forward to evaluate our implementation
against complex usage scenarios.
Escape Paint on current XaAES
I haven't touched the source code of Escape Paint for years now but when
I played with the latest version of MiNT + XaAES on my CT60 Falcon, I
noticed that Escape Paint won't work at all under this OS environment -
a perfect reason to start tinkering with the Escape Paint source
code again (1 MB Pascal + 1 MB assembly code). The graphical Pure
Pascal development tools do not work under MiNT but fortunately, the
compiler, assembler, and linker are available as plain command line programs
as well. This way, I can use GNU make for compiling. The compile speed on
the CT60 Falcon just blew me away. At one evening, I resolved all Escape
Paint issues that I stumbled across, for example the allocation of memory
via MxAlloc, adaption to some XaAES-specific GUI behaviour, some missing error checks,
and a problem with the system color table. Now, Escape Paint runs fine
on the CT60 + MiNT + XaAES.
X-Grabber support for Image Magick
On the Atari Falcon, there exists a really cool screen-shot program called
X-Grabber. After taking about 300 screen shots, I noticed that the output
format is pretty much unsupported by any available graphics software.
The format is just a dump of the frame buffer, the video registers,
and color tables. The high range of possible graphics modes (bitplane
modes, hicolor modes, double scan etc.) however make a X-Grabber import quite
complex. X-Grabber comes only with a small tool that lets you convert images
with certain properties (e.g., hicolor only) to another awkward format, one
picture at a time. I did not want to spent a whole weekend for converting the
images to a standard format. Therefore, I implemented support for the X-Grabber
format for the Image Magick tools. Although the support is not 100% complete
(e.g., there is no support for ST compatibility modes), yet,
I got my 300 images converted by issuing only one command line.
Free software makes it possible!
May 1st is a holiday in germany - a perfect opportunity to continue by work
on the SRAM controller for Charon's FPGA board. I managed to get my pipelined
design to work for read and write accesses on one port. However, I will
need some intensive testing because dealing with half-phase-shifted clock
cycles for the SRAM chip is very tricky. Later, I will add the second port
that will enable me to use the SRAM as framebuffer as well as for another
component in an interleaved way.
Communication infrastructure for Bastei
During the last two weeks, I designed and implemented much of the IPC-related
infrastructure for Bastei. This is a tricky thing to do because Bastei is
meant to work on L4/Fiasco (current implementation), the L4.sec kernel as well
as on our future hypervisor, developed within our group. These three kernels
provide different mechanisms for communication and different control flow
schemes, which makes it hard to define a unified user-level API.
Anyway, I created a working IPC abstraction and a framework for building
client-server communication ontop.
Memory management for Bastei
For our Bastei experiment, we need to manage memory at various places, for
example, we need an allocator for physical memory with an arbitrary
memory layout, heap allocators etc. First, I created a custrom AVL tree
implemementation (that will also be used for other purposes) and a slab
allocator. Based on that, I created a best-fit allocator that enables
us to decouple metadata storage from the managed address space.
Debugging console for Bastei
Today, I had the need to print debug output for our Bastei project
and started extracting the printf function out of uclibc when I
noticed that this means adding more then 1700 lines of code to our
core components. So I decided to implement a custom printf function that
supports only the features we need (signed/unsigned, long, int, hex, octal,
pointer, characters, strings, zero-padding). My implementation consists of ca.
160 lines of C++ code.
Bastei build system and initial directory structure
Today was the first day in a series of intensive coding sessions with
Krishna. We will team up to bring forward the practical realization of
our next generation userland architecture.
As a first step, I created a (make-based) build system on the basis of my build
system that I used for Coldfire-related developments. The build system supports
recursive library dependencies, build directories, and an arbitrarily
structured source tree with any number of build-targets scattered within the
tree. Still, it is very easy to use.
Design paper of Bastei
Krishna an me developed the design of Bastei much further and compiled
a design paper describing our rough ideas. This document will develop
while we conduct our practical experiments.
New project: Bastei
Our research group requires a more secure and low-complex alternative
to the currently used userland (L4 environment). The new userland
needs to provide flexibility with regard to security policies, enforce
resource accounting, support local names for each system component,
and enable highly dynamic system structures (for killing and loading
whole subsystems). I presented my ideas about such an architecture
to our group and these ideas will form the basis of our first experiments.
We named our experimental project Bastei.
TUD:OS Demo-CD released
Today, I released the TUD:OS Live-Demo CD.
Photos of Kevin
As requested by several friends, I picked some photos of my son
Kevin and put them at a dedicated page:
Finishing touches of the TUD:OS Demo-CD
During the last weeks, I had been very busy with finishing the TUD:OS
Demo-CD. This involved a lot of testing, bug-fixing, coordinating
all contributors, integrating all the demo scenarios, tweaking
configurations, writing lots of scripts, creating a website and the
content, polishing graphics, and a lot more.
For my time being at the OS Group, these past weeks had been the most
Kevin is born
Today, Christin gave birth to our son Kevin. We curiously look forward to our
life as a family.
FPGA coding week with Charon
For the last week, Charon stayed at my place to do things on his
custom-made FPGA board. I am new to VHDL and thus, decided to
go through some practical exercises first while Charon ported
an arcade machine implementation (e.g., pacman) to his board.
During the week, I created working VHDL models for a serial
controller, a PS2 keyboard controller, a VGA controller, and
some fun test models. Thanks to the great help by Charon,
my learning curve was quite steep and I was enjoyed the
FPGA coding a lot. I also took a first look at the GHDL
simulator that is available as GPL. After these first
steps, I started implementing a SRAM controller. I managed
to perform subsequent write and read accesses but my
attempt for a pipelined design did not work out, yet.
Thanks to Charon for this great experience. This was the
greatest hacking session since a long time!
RAM-Disk creation tool supports X11 and OvlWM
I enhanced my RAM-Disk creation tool to support X11 via Xorg and
WindowMaker. There is now also the option of including Overlay WM
support. So the RAM-Disk is now in a usable state for the Demo-CD
and can completely replace my old hand-made RAM-Disk.
Revised Nitpicker and OvlWM
With regard the upcoming Demo-CD project, I revisited a lot of components
that I will use for the presentation.
Nitpicker provides now support for handling multiple Desktops. Each client can
define a view that is used as background. When any view of the client becomes
the focused view, this background becomes visible. This way, Linux desktop
environments become fully usable with Nitpicker. On antoher note, Nitpicker
supports now the handling of client-side windows that stay always on top of
other windows of the same client. I also enhanced the X11 window event
tracker to report more robust information about window state changes.
For making the enhanced Nitpicker functionality available to the Overlay WM
interface, I revisited Overlay WM and all its components (libraries, the
implementations for DOpE and Nitpicker, and the X11 drivers).
Furthermore, I made Nitpicker compliant to run on VMware.
Back from ACSAC'05
I just returned from the ACSAC'05 Conference, held in Tucson, AZ,
where I presented my work on Nitpicker. I gave my talk by using
our custom software stack (Fiasco, L4Linux, DOpE, Nitpicker,
Presenter, X11 etc.) and everything went well.
First functional version of the Tutorial browser
I finished my work on the first functional version of my tutorial
browser and ported it to Nitpicker, DOpE, and the L4 Console.
Linux Ramdisk distribution
I started to develop a new tool for creating a ramdisk image with
a bootable Linux from a Debian host Linux system. Dependencies
of binaries to shared objects are resolved automatically and the
whole directory structure is created from scratch. Right now,
I can already boot into the ramdisk and login as root but there is no
support for X11, yet.
This weekend, I visited the annual Paracon Atari convention.
Together with Charon, I fixed some issues and optimized the performance of
DOpE when running on his custom FPGA board. Charon
also started to teach me some basics about VHDL programming and (yippie)
lend me one of his two self-made boards. So now, I can start playing
with VHDL, too.
For enabling other people to understand what kind of research we are
doing, we want to create a Demo CD of our experimental research OS.
This Demo CD will feature a small tutorial explaining the OS. I am
currently developing a tutorial browser for this purpose.
I use a custom GOSH backend to generate the document representation
from a GOSH text automatically. The frameworks for storing the
document structure and for graphics are working already. This time,
I choose C++ as implementation language instead of plain C and I
am pretty excited about the power of that language.
I finished my implementation work on Nitpicker as well as my paper
for the ACSAC'05 conference. Now, Nitpicker uses memory, donated by
its clients, for holding client-specific data. This makes Nitpicker
resistent against denial-of-service through resource exhaustion.
Each client has now a private namespace for the objects he is
working with and he cannot access or see objects of other clients.
The plain presence of other clients is not visible via Nitpicker.
I also added a lot of practical things such as a Kill mode, handling
of Desktop backgrounds, and an improved view stack management.
Alpha blending and Drop Shadows in DOpE
I started a couple of experiments about improving the look of DOpE.
First, I added alpha blending support to the graphics backend of
DOpE. This clears the way for antialiased text, icons and other
nice-looking things. As a first test, I implemented support for
Paper about Nitpicker accepted
The paper that I have written about Nitpicker is accepted for the
ACSAC 2005 conference that is held in December in Arizona. I am very
happy about this and look forward to my presentation at the conference.
Back in Dresden
I just returned to good old Germany and there are thousands of things
to do now. Lets see...
Working in Hillsboro, OR
During the next four months, I will work at an Intel research lab
in Hillsoro, Oregon. During that time, I will not be able to work
on the Atari Coldfire Project. Therefore, I sent the Coldfire
Evaluation Board to the wizard of GEM, Odd Skancke so that he
can try to get VDI and AES running ontop of the MiNT kernel.
Of course, when I will be back in Germany in August, I will
continue with developing Coldfire stuffs.
DOpE on Xilinx Microblaze
This weekend, I visited Charon in Kaiserslautern to make DOpE run
on Charon's custom FPGA board. At the beginning, Charon was
dead drunk from a party last night but still, things progressed
nicely. While I did the porting work of DOpE using the Microblaze
tool chain, and implemented the drivers for screen, keyboard and
mouse, Charon created the PS2 keyboard controller and debugged
his VGA controller. After some fiddling with the linker scripts,
and the libC provided by Xilinx, we successfully got DOpE running
on Charons board. After that, I created a special DOpE version
for embedded devices, which is just a library that can be
used in the same way as DOpElib on L4 or Linux. In fact, this
lib contains the complete DOpE windowing system and even the
event concept of DOpE is mapped to the control flow of only one
thread in the system. This makes it a childs play to port
existing DOpE applications to the embedded platform by just relinking
Overlay WM implementation for Nitpicker
I reimplemented the server interface of Overlay WM for Nitpicker to support
XFree86 directly by Nitpicker. The interface of Nitpicker is even
simpler than the original OverlayWM interface. Thanks to that fact, the
Nitpicker Overlay WM server consists of merely 250 lines of code.
Window event sniffer for the X Window System
I implemented a small sniffing program that captures all events that are
related to the window management of a running X-session. In the end, this
was easier than I thought. At first, I wanted to use a modified XNest to
plug between the real X server and the X session to sniff passing window
events. After some tests with xlib programming, I discovered a much easier
way. I can just start a simple X client when a session is running. The
X client scans all windows and registers itself as event handler for them.
It also registers for map and unmap requests at the root window. This way,
also newly appearing windows get captured. X11 does not feature any security
policy between client applications at all. Any X program can sniff and
manipulate any other running program.
Support for importing frame buffers into Proxygon
I enhanced Proxygon to support the console interface functions, which
enable a client application to import a virtual frame buffer into the console.
So far, this interface is only used by the l4fb driver of L4Linux-2.4/6 and
the upcoming L4-port of Qt embedded.
Update of the ACP website
Since a long time, it was relatively silent around the Atari Coldfire
Project. It does not mean that we were lazy. Now, we updated the project's
website with some information about the progress:
Design of the future changes of DOpE
In the near future, I will enhance DOpE by two important architectural
features, which will require structural changes of the whole DOpE
package (the server as well as the client lib and the client applications).
Those two features are a more flexible event concept and a concept
that I call MacroWidgets - a way to implement complex higher-level widgets
outside the DOpE window server within separate protection domains.
Both concepts are quite complex and thus, hard to design. Thanks to
Alex and Krishna, we had long and fruitful discussions, which cleared
up the whole mess of ideas. Now, I look forward to convert the rough
design into a beautiful piece of code.
C/C++ indentation tool
During the weekend, I started to work on a formatting and indentation tool for
C/C++ source codes. My aim is to provide much more fain-grained control over
the coding style than supported by Indent. For this, I used a similar approach
as for GOSH: the parser splits the text into a tree structure by using regular
expressions. This makes the parser to be very small. The inverse function for
generating code from the tree can now apply formatting for the different
elements. Similar to GOSH, the tool will support multiple backends to create
completely different styles.
User interface for L4GPG
During the last two days, I created the user interface for L4GPG.
It requires to feature a password entry field. As the DOpE Entry
widget did not provides this feature yet, I enhanced it by a blind
mode, which can be toggled via the '-blind' attribute of the Entry
widget. When being in blind mode, the Entry displays all letters
Updated the Falcon Port of DOpE
Being at the very cool Paracon Party, I used the time to update my
port of DOpE to the Atari Falcon to the current version including
all the most recent features such as translucent windows, keyboard
focus, scopes etc.
Beside that, I did not manage to code a lot Atari-specific stuff
at the convention - it was just far more interesting to talk with
all the great people there! Many thanks to the Paranoia people for
organizing this event.
Abandoning DOpE's Terminal widget
Now, I converted all programs that used the old Terminal widget of
DOpE - a custom implementation of a VT100 subset - to use the new
VTextScreen widget, which provides a memory mapped text buffer
rather than a streamed protocol. VTextScreen is much more powerful
because arbitrary terminal protocols can be implemented on the
client side as done for example by the vc_server. The last program
using the old Terminal widget was DOpEcmd. I rewrote it from scatch.
As a positive side effect, I improved the cursor support and the editing
facitilies. Additionally, I significantly improved the overall performance
of text output and editing.
Since the Terminal widget is not needed anymore, I removed it from
DOpE's code base and this way, further shrinked the source code complexity
New Blender image
A while ago, I played with the radiosity feature of Blender and created
a small test image. Now, I use a slightly enhanced version of this image
as default background of DOpE. I also added the image to my Blender gallery.
During the last days, I refined various aspects of Nitpicker. Now,
I can toggle its secure and normal mode using a magic key. This
feature makes it much more usable when dealing with legacy software,
only. Furthermore, I optimized the performance, which was quite slow.
Now, Nitpicker's speed with DOpE as a client application is nearly
the same as when using DOpE alone, which makes me really happy.
Also other things, such as destroying views etc. are now working
Background image for DOpE
For making my demos of DOpE more eye-candy, I implemented a DOpE
application, which displays a background image and enhanced DOpE
with some functions, needed (for example, a function for putting
a window to the background). I use libpng, ported to L4 by Jens
Syckor, and Jens' libpng_wrap to decode and convert the image to
RGB565, as used by DOpE's VScreen. Sadly, images with slight gradients
look really ugly when just cutting off the lowest color bits. Thus,
I enhanced libpng_wrap to perform ordered dithering for the lowest
bit of each color channel. The result looks quite good.
Improved keyboard support of DOpE
I enhanced DOpE to support a keyboard focus for every window.
Keyboard events are now always received by the currently
focused child widget of the active window. The focus can be
changed among the widgets of a window by using the tab key.
Buttons can also take the keyboard focus and can be selected
by using the space key.
I started a new section of this website presenting my results
in using Blender. Right now, there is only one picture available.
The gallery will grow as soon as I produce some decent results.
This weekend, I approached several issues with developing on
the Coldfire. Firstly, I implemented a bus transfer routine
for DOpE's pixel data in assembly. This leads to a significant
speed-up. Transfering large amounts of data through the Cypress
PCI bridge is quite awkward to implement because only a viewport of
8 KB of the PCI address space can be made visible to the host
address space at a time.
Secondly, I wanted to resolve a problem that went
on my nerves for far too long: Until now, switching on the
-O2 switch of gcc led to strange behaviour (erm... crashing
behaviour) of the compiled programs. After long debugging sessions
I identified the libc as troublemaker. I decided to throw
together a minimalistic libc based on Dietlibc with only the
functions I need. Sadly, the stability issues were not completely
resolved. Damn! Ok, so I decided to update the whole gcc toolchain
to the newest version and ended up with hacking linker scripts,
crt0 stuffs and writing a custom backend for newlibc. The work
was worth it - finally, I got everything to work with the current
gcc version with -O2 switched on! The speedup of DOpE on the
Coldfire is very nice.
DOpE testbench for Widget Layout
I created a small testbench to check the Widget layout of DOpE
after changes of the DOpE widget set against a desired layout.
The testbench starts a DOpE session, sends DOpE commands for
the creation of certain Widget configurations to DOpE and finally
makes DOpE to dump a screenshot into image file. This image is
then checked against a desired template image. When a layout
artifact occurs, I can fix the bug and add a test case for this
bug to the testbench. This way, we ensure that we do not introduce
the same bug again.
Cleanup of the DOpE package
I finished my work for the XFree input driver for XFree-4.3.
Sadly, the used mechanism (xf86eqEnqueue) of submitting keyboard events
to the X-Server is not available in XFree-4.2.1. For this reason, I had
to update our DROPS-X RAM-Disk to XFree-4.3. Argh.
Now, with working screen and input drivers for XFree-4.3 running under
a plain L4Linux kernel I can throw away some things from the DOpE
package, which never really belong to DOpE. Firstly, I removed all
pSLIM specific stuff such as the pSLIM widget and the pSLIM server
from the DOpE server. With Proxygon, there is now a nice alternative
to the DOpE-ports of various Console programs such as the l4lx_stub
and DOpErun. Thus, I removed these programs as well as libterm
(a reimplementation of the contxtlib for DOpE) from the DOpE/examples.
Another candidate to get rid off was DOpElog, which was merely
a hack. Krishna revived a great Debug Monitor called dmon
(an extra package), which is much more flexible. This enabled me to
throw away DOpElog as well.
XFree Input Driver for the Linux Event interface
During the last two days Krishna and me implemented an input device driver
for Xfree 4.3 that works with the /dev/input/event devices. This is
a generic input event interface, normally exported by the Linux kernel.
I want to use the new driver for a pseudo-device that is not
provided by the Linux kernel but a user-level Proxy process that
receives input events from OverlayWM / DOpE via L4 IPC and exports
them as Linux input events via a named pipe. This way, the input
and output of Xfree running on L4Linux does not rely on any Linux
kernel mechanism anymore and thus, I can dispose my patched l4lxstub.
During the last few days, I reimplemented the interface of the DROPS
console application (Con). Proxygon provides exactly the same interface
as Con but maps the functionality to DOpE's Vscreen widget. Every
virtual terminal is displayed in a separate window. It provides
the most graphical primitives of the pSLIM protocol such as drawing
of bitmaps, colored images, text and filled boxes. Now, original
Con client applications can be used under the DOpE environment without
any modifications. Examples for such applications are the original Run
(a text-based launching application), the Con demos as well as the
original L4Linux console stub.
Consequently, I can kick out a lot of old garbage (the DOpE-specific L4Linux
stub, DOpE-Run, libterm, the pSLIM widget) out of the DOpE package.
New GOSH release
I released a new version of my text parsing tool GOSH.
The LaTeX backend of this version enables the explicit usage
of floating tables by a command line argument. Per default,
tables are inserted at their point of definition now. This
change makes the DOpE documentation as PDF much better readable.
Nitpicker finds its way into the L4 CVS
My new experimental window manager called Nitpicker emerged
from the underground and showed up at the L4 CVS tree. It is a new
GUI for L4 based operating systems that is designed to be as
minimalistic as possible.
ACP Meeting with Martin Döring
This weekend, Martin Döring - the author of Emutos - visited me in
Dresden. Together with Jens Klietz we discussed operating system
related issues with a special focus on the first-stage bootstapping
procedure. We decided not to start with the porting work of
Emutos to the Coldfire yet because we want to keep the overall
complexitly of the non-exchangable bootstrapping code as small as
possible. Thus, Emutos will not be the first-stage OS loader.
Emutos gets a cold
After a long mail talk with Martin Döring - the author of Emutos -
we decided to merge my MiNT loader for the Coldfire with Emutos.
This makes a lot of sense because Emutos provides a full Atari TOS
compliant BIOS und XBIOS subsystem. Furthermore, it includes a
The first step of implementing Coldfire support into Emutos is a
Coldfire CPU detection routine. Thus, I implemented one. I also
started the actual porting work and Emutos even shows its first
lifesigns on the Coldfire.
New 'expose' feature for DOpE's Frame widget
I added a new function called 'expose' to the Frame widget of DOpE.
It causes the Frame to make a specified position within its content
visible to the user. I combined this with a nice movement transition.
New DOpE example application
I implemented a very simple text editor for DOpE using the VTextScreen
widget. It is meant as a part of demonstration scenarios of the NIZZA
secure system architecture.
As a side effect, I implemented text cursor support into DOpE's VTextScreen
The Scrollbar widget of DOpE is now available at the command interface such
that applications can now use it in their custom way.
I also slightly reworked the Grid layout widget to avoid artifacts that
appeared in some cases. Each row and column do now remember their
child widget that enforced the min/max constraints. If such a child
changes its properties, the Grid layout gets updated. This way is far
more robust than the previously implemented heuristics.
Scope support for DOpE's command interface
I implemented the support for Scopes (name spaces) into DOpE.
Every application has a root scope on startup that holds all
its variables - especially nested subscopes. This feature
is not really useful on its own because you could also use
name prefixes to stablish name spaces but it prepares a new
client interaction scheme, which I will implement soon.
New command interface for DOpE
The communication of applications with the DOpE window server is based
on a text-based protocol. The first version of the command interface
was only meant as prototype but worked out to be quite powerful. I
decided to recode this part of DOpE to make it more robust and
flexible. As a result, DOpE is now much more informative about
faulty commands. The changes implicate the following consequences
for DOpE applications:
- Commands are only executed if they are valid as a whole. A 'set'
command with multiple tag - value assignments will not be executed
at all if one assignment is faulty. Previously, DOpE ignored
faults of single attribute assignments and executed the other ones.
- Method invokations are only accepted with the presence of a
parameter block (left and right parenthesis), although the
parameter block may be emtpy. This follows the syntax of C/C++
- Optional method attributes, specified as tag - value pairs,
can now be arbitrary ordered.
Testbench and reworked HTML backend of GOSH
Inspired by the unit test framework by Michael Hohmuth, I created a test bench
for GOSH. Using this framework, the output of a new GOSH version can be easily
checked against the desired output, which was produced by a previous version.
This prevents old bugs from re-appearing and thus, provides a minium of quality
Furthermore, I reworked an generalized the HTML backend of GOSH. Per default,
the output is raw HTML with the appropriate HTML tags for the different textual
elements. The output can now be tuned by some command line arguments.
GOSH released as GPL
I released my text tool GOSH under the terms of GPL. You can download
it at the file section of this website. GOSH is a tool, which takes
an ASCII text as input and generates
or Man-pages. This way you can create a
PDF of your text document or create a
TU Dresden Operating Systems Research Day 2004
On the 17. of December, our research group will show off our past and
present research and discuss future fields of interests with our
partners from industry, research and goverment. The official website
of this event is now online. I created this website using my text
tool GOSH and some utility scripts. The graphics were made using
POV-Ray, OmniGraffle and ImageMagick.
MiNT kernel runs on the Coldfire!
Finally, I managed to port the MiNT-kernel to the Coldfire
MCF5407 Evaluation board! It boots up completely and starts its
internal shell. During the last night, I added keyboard
input support via the serial connection. So now, I can
interact with the shell and browse MiNT's directory tree!
My approach was, to let MiNT running inside an execution environment
that contains the cf68klib as well as the TOS services
needed by MiNT. The execution environment also contains the
input/output drivers for the console and keyboard and the
initialization of timers.
Right now, it consists of only 600 lines of C-code.
Using this technique, I managed it to run the MiNT kernel nearly
unmodified. In fact, I changed only two lines of the MiNT
Update of my article about the MCF5407 evaluation board
An updated version of my article "My life with the Coldfire Evaluation
Board" is available at the website of the Atari Coldfire Project:
I added sections about my work with porting the MiNT kernel to the
Coldfire and about how to download my Coldfire-related source codes.
Coldfire sources available under GPL
I made all my Coldfire related source codes publicly
available via a Subversion repository:
You can browse the repository with a normal web browser or checkout
the source tree via the command:
svn checkout http://os.inf.tu-dresden.de/~nf2/svn/trunk/acp
In the repository you also find the Falocn port of DOpE.
First MiNT boot messages on the Coldfire
This weekend I managed to get the first MiNT boot
messages on the Coldfire. For this, I implemented the
trap handler for GEMDOS and XBIOS in a more MC68k like
way by using the user-level traps, provided by the cf68klib.
MiNT on Coldfire sends first lifesigns
On saturday night, Jens and me had a small programming
session. While Jens worked on a Reset-generator, which is
somehow important - I did not understand really - I worked
on porting MiNT to the Coldfire. I completed the
code for setting up a valid basepage and traced the execution
of the called MiNT code by patching it with some traps.
In result, the MiNT startup code began to send lifesigns
in the form of TOS systemcalls (trap #1). I began to write
a trap-handler for GEMDOS. Originally, I wanted to implement
the dispatch routines of the different GEMDOS calls in C
functions that work on directly on the syscall frame of the
user application. Sadly the gcc alignes all parameters on
the stack to 4byte-even addresses. After some hours digging
in gcc documentation and finally asking Peter Barada
(maintainer of the Coldfire-gcc) for help, I decided to
generate assembler stubs for the different syscalls.
These stubs convert the syscall frame into a valid gcc
function call frame. This works quite well.
Right now, MiNT tries to find its configfile in various
places and gracefully fucks up after that. Cool - this
is exactly what I wanted!
New features for GOSH
I added some new features to GOSH, my text parsing tool,
to make it applicable for even a wider range of textual
Additionally, I improved the output of GOSH by removing all
trailing whitespaces of the output.
- Annotations are now supported by prepending the corrsponding
lines of text with a pipe-symbol followed by a space.
Such marked text will be printed in a small, italic typeface.
- Raw output, which can be used to pass the text passage
to the backend without touching it. This can be quite
useful for implementing large LaTex sections into a
GOSH text. Lines with raw output is marked by a leading
Radeon Test Program
After digging in the Radeon documentation and SDK
for while, I began the development of a small
demostration program that uses the 2D graphics
primitives of the Radeon, which are lines, solid
filled boxes, bitblitting and hardware clipping.
The program is a wobbling wireframe 3D object.
It will be the first test program to use our
Falcon coding weekend
I dedicated this weekend completely to my Falcon. My port
of DOpE to this computer is now in a usable state. I
implemented a client API based on a trap mechanism and
coded a falcon specific dopelib. Now, it is possible
to develop DOpE client applications on the Falcon by
using the same programming interface as on L4 or Linux.
After that, I implemented a Falcon specific graphics
backend for an 8(4) bit grayscale chunky buffer. To
speed things up, I implemented some graphics functions
such as solid boxes and scaled images in assembly.
So now I can run DOpE in an 8 bitplane screen mode,
which means higher resoltions can be used. Still, the
performance is quite slow on an origial falcon. On a
CT60 enhanced machine, DOpE runs quite smoothly.
Finally, I reimplemented the input driver in order to
support keyboard inputs. The previous driver hooked
into the Kbdv table of TOS. After some talk in #atariscne
I decided let TOS being alone and hook directly into
the MFP interrupt at 0x118.w. Thanks to Ray and
Mr.Pink for their help!
Update Falcon DOpE version to new version
I adapted the Falcon version of DOpE to the latest changes
of DOpE, such as the new input concept. For this, I had
to reimplement almost all of the input driver code. I also
began to implement a client session mechanism for the
development of DOpE applications on the Atari Falcon.
My aim is to provide the same client application API for
the Falcon version as for L4 or Linux. This is quite hard
because we only have one single thread for both - the
client application and DOpE.
Resource deallocation of DOpE client sessions
Now, as DOpE supports the killing of client sessions, the
memory deallocation of client sessions becomes more important.
Thus, I implemented destructors into a lot of widget types
and carefully checked all DOpE components for memory leaks.
Petze - my memory leak debugging tool for L4 - was a great
DOpE supports the DROPS Events concept
The L4 version of DOpE supports now the Events concept of
DROPS. It is used to broadcast events to resource managers
when client applications disappear. This way, client specific
resources can be freed after the death of a client application.
Locking of DOpE widgets
I implemented a locking mechanism to synchronize the usage and
modification of widget data structures within DOpE. This way, I
prevent some screen artifacts that appeared under heavy workload
of DOpE commands.
Diving into the Radeon specification
Krishna and me decided to push forward our ideas about the virtualization
of graphics hardware. Thus, I am currently studdying the specification
of ATI's Radeon graphics cards. The Radeon will be our experimentation
platform as this hardware is present in our notebooks.
Motorola (freescale) evening seminar in Berlin
Jens and me were invited to visit a seminar by the semiconductor
department of Motorola --- now called freescale. There, we had
the chance to meet developers of PowerPC and Coldfire-based
products and listened to very interesting talks by the Motorola
staff. To my very surprise, we even met Gerald Kupris who supported
the ACP Project a lot in the past. He presented a very interesting talk
about the 32 bit Microcontroller/Microprocessor families including
the new revisions of the Coldfire 4e.
Key repeat for DOpE
I implemented a global key repeat mechanism into the DOpE
server. It supports key repeat delays and rates at a accuracy
of 10 ms. Now, all widgets support the new
binding and thus, can react to key repeat events. I also
implemented support for this new feature into DOpElib, libterm
and the Entry widget.
VScreen gets more flexible
DOpE's new donation-based scheduling component enables VScreen
to support other frame rates than 25 fps. Right now, the real-time
extensions of Fiasco are not used yet. Thus, there is neither any
admission nor detection of overload situations, yet. The periodic
job are currently scheduled via l4_sleep() - this will be exchanged
by the appropriate periodic task model of Fiasco later.
Note that DOpE only supports these features when started on L4/Fiasco
with the command line option --donscheduler.
DOpE on Atari Falcon
This weekend, I ported DOpE to the Atari Falcon 030.
This was the first time, I developed Atari software without any
Atari (in fact, I was at my inlaws' place and only had my
Thinkpad with me). I used the cross-mint-gcc toolchain for
compiling and Aranym for testing the software.
Most of DOpE's sources compiled without any problems. I
only had to implement a Falcon specific input driver (it
only supports the mouse, yet) and a VIDEL screen driver.
Currently, I only support a 320x240 screen mode.
A first version is running happily but I did not implement a
programming API, yet. On a standard Falcon (16Mhz), DOpE runs
quite slow. This will improve as soon as I implement
some performance-critical functions in assembly. On a CT60
enhanced Falcon, everything runs very smooth.
New Scheduling for DOpE on Fiasco
I restructured all parts of DOpE that are somehow related to its scheduling
of real-time, non-real-time and user input jobs. In result, there exists
now a dedicated Scheduler component that can be easily exchanged by another
In order to use the new real-time scheduling extension of the Fiasco
kernel, I implemented a Scheduling component of DOpE that utilizes the
new scheduling model. Since DOpE must strictly serialize all redrawing jobs,
I could not apply the original model to my problem. Anyway, after a
discussion with Udo and Jean we found a usable solution that is based
on time-slice donation. Thus I call it DonScheduler.
Just for the thrill (and to follow the instructions of Alex :-), I used
DICE-IDL for task-local synchronisation. To my surprise (nearly) everything
works fine. Thanks to Ron for keeping me away from writing L4 IPC calls
FLIPS with Linux-2.4.26
The current version of FLIPS finally found the way to the OS-Group CVS.
Before that, we had to update the IP-Stack to the current version of
the Linux-Kernel and clean up the whole source tree.
Optimized Grid widget of DOpE
I changed the way of how the Grid widget stores information about its
children widgets. Now, the Grid stores a map of Grid cells - so that it
is able to draw a certain Grid region without iterating through all
children widgets. In result, the performance of Grids with a high
number of children increased notably.
FLIPS works with current L4Env
After some months of not touching the source code of FLIPS (Flexible IP Stack)
I continued to improve its IDL socket interface and its client lib. I added
support for FLIPS session management with multithreaded client applications.
Finally, I ported a socket test program by Silvio Vogt to L4 and ran it
successfully as a FLIPS client application.
Technical Report about Overlay Window Management
Christian and me released a technical report about Overlay
Window management - a way of integrating multiple legacy
window systems into one user environment while preserving
the isolation of the distinct domains.
Outline Party in Holland
Nils, Christin and me visited the great Outline convention organized
by FUN and LineOut. This was a damn great event with lots of nice
people, interesting talks, trippy weed sessions and cool competitions.
During the party, I coded only a little - I got a relocation routine
for TOS executables running and ported the current version of DOpE
(with all new features) to the Coldfire.
I was happily surprised by the positive feedback to the Atari Coldfire
Project. Although I could not make any promises of when something
usable will be available, a lot of people seem to appreciate our work.
New Entry widget for DOpE
Carsten just did not stop moaning about the lack of a line-edit widget
in DOpE. Thus, I implemented the Entry widget. Currently, it can be
used to edit one line of text. Cursor keys and backspace are supported.
I also began with the support of text selections. As a fancy feature,
the widget moves the text to display as much information as possible
while editing text or when setting a new cursor position.
Tick - a new DOpE component
I implemented a new DOpE component called Tick. It can be used to
implement timer callbacks which are called with a freely defined
frequency. The accuracy of the timer is ca. 10 miliseconds. Tick
is primary intended to implement blinking cursors or smooth movements
DOpE's Grid gets better
I implemented a more robost row/column balancing algorithm, which supports
rows and colum of fixed and weighted sizes and respects the min/max
constains of child widgets. After a conversation with Alex I decided to
revise the way of how the Grid stores layout information. This will (hopefully)
lead to performance improvements with very large Grids and will enable me
to implement a decent way of background-handling.
My first application for MacOS X
After some time with just playing with Mac OS X and the great applications
that are shipped together with the iBook, I began to discover the Xcode
development tools. Although I am not a fan of integrated development
environments I must admit that Apple did a fine job here. Within a very
short time, I managed to create my first project and ported one of my
old OpenGL-based demo effects to Mac OS X. I also appreciate Apple's great
sense for the default configuration of the Xcode editor :-)
Grid widget supports DOpE's new layout concept
I implemented support for DOpE's new layout concept into all
available widgets, including the Grid widget. Now child widgets provide
their min/max dimensions to their parents, which in turn use these
values to set the actual child positions and sizes. This way, client
applications do not need to specify any pixel values anymore - only
the widget-topology must be described via DOpE's command language.
Back from CeBIT'04 - ready for my new iBook
The stressy week at the CeBIT'04 fair is over now - a good reason to reward
myself with a new iBook. I wanted to play with such a toy for a long time.
Everyone who has something to do with GUI development should take a
close look at Mac OS X - I never had so much fun with using a computer
before. For me, the biggest reason to purchase a Mac is a program called
Omnigraffle. It is the successor of the brilliant Lighthouse Diagram
application running on Nextstep.
Mikro-SINA at CeBIT'04
Krishna and me present the Mikro-SINA project and the Dresden
Real-Time Operating System at the CeBIT'04 fair. We are at Hall 11,
stand D27. If you are at CeBIT, just pay us a visit (we
have coffee and jllybabies for free).
GOSH continues to improve
I added some nice new features to my text conversion tool GOSH:
- The HTML backend provides now a table of contents.
- References as hyperlinks are supported.
- The HTML backend supports different text colors for different
Article about my life with the Coldfire Evaluation board
I wrote an article (pdf,
about my past and current work on getting an
Atari compatible operating system to run on the Coldfire platform.
The text describes various experiments such as initializing
graphics cards and gives an outlook about my next steps on the
long path to run MiNT on this platform.
Rework of DOpE's layout concept
I implemented a more appropriate model for handling nested widgets
into DOpE. The old implementation was hard to face for the programmer
of a widget. With the new concept, the widget base class provides
a framework for handling the propagation of layout information in
a more generic way. An actual widget only implements functions for
specific behaviour of the widget (for example a function to rearrange
child widgets or a function to determine the min/max size).
Additionally, with the new design the Window Manager disappeared.
Its functionality resides now in the Screen widget, which is a
layout widget. This change makes the way free for the support
of virtual desktops on DOpE.
New DOpE widget: VTextScreen
I implemented a new DOpE widget called VTextScreen. It is the counterpart
of VScreen for textual output. Basically, it implements the same interface
as a VGA text mode. There is a shared buffer containing character
and attribute data between DOpE and a client. The attribute channel has
8 bits and supports 16 different background and foreground colors at 3
different brightness levels.
CeBIT'04 Demo for the Mikro-SINA project
At the CeBIT'04 fair, we will present a demonstration scenario of the
implementation of our VPN-box. The demonstration program will feature an
interactive diagram running as DOpE application. The diagram displays the
information flow between the components in real-time and allows the implemented
policies to be changed by the user. I am responsible for the visual part of the
demonstration. Thus I rendered all states and animations using POV-Ray combined
with a custom Tcl script.
Paper about Overlay Window System technique
During the last week, Krishna and me were busy with writing a paper
about the Overlay Window System technique. This mechanism enables
the integration of multiple legacy window systems into one trusted
host window system. I implemented the mechanism for the X Window System
and for Atari/GEM running on Hatari. A screenshot of this scenario is now
available at the screenshots section of this website.
Preparations for CeBIT'04
The Mikro-SINA project - I am working at - will be present at the
CeBIT'04 fair. This means there is a lot of public relations work
to do. We created a poster, a flyer and some other advertising
stuff. Once again, POV-Ray was of great help here. I added an
image of the poster to the POV-Ray section of this website.
Hatari on DOpE
Today I ported the great Atari ST emulator Hatari by Thomas Huth to
L4/Fiasco + DOpE. Thanks to the libSDL port by Thomas Friebel and
the good structured code of Hatari, no changes on the original code
were necessary. All I had to do was to write some fakes of the
used file functions (ca. 70 lines of code) and to write a BID-compatible
makefile. This was the most difficult job because of the funny way of
how the CPU emulation code is created. The makefile also automatically
creates dummy implementations of all unresolved symbols.
So now, I can read Atari Diskmags on DOpE!
MiniTop is functional
MiniTop displays now the right timing values when running on L4/Fiasco.
Quite interesting to see the programs eating CPU time.
New Screenshot of DOpE
I added a new screenshot to the DOpE-screenshots section of this website. It
shows the first (non-functional) version of a Top-application. There you can
also see the transparency feature of DOpE in action. Of course - this feature
should not be enabled by default when using DOpE for real-time (it constrains
the predictability of redraw operations) but it looks fancy.
New LoadDisplay widget for DOpE
Some weeks ago I got a feature request from the
Comquad-folks. They needed some kind of progress bar for their system.
With the new LoadDisplay widget one can implement load/progress/whatever-bar
displays. Each LoadDisplay can hold multiple bars with distinct colors.
The visible range of values can be freely configured and can contain
negative values. The widget supports horizontal and vertical orientation.
For a test you can try typing the following commands using DOpEcmd:
a = new Window()
b = new LoadDisplay()
b.set(-from -100 -to 100)
b.barconfig(load, -value 45)
b.barconfig(idle, -value -33.3)
Screenshot of Verner - a DivX recorder and player for DROPS
I added a screenshot of Verner - the most advanced DOpE client application so
far to the official DOpE website. Verner is a program to record and replay movies
and music based on the real-time capabilities of the underlying system
L4/Fiasco, DROPS. Thanks to the author of Verner - Carsten Rietzschel - for
Virtual mc68030 running on Coldfire
I got a virtual mc68030 running on the MCF5407 using the
great cf68klib by MicrpAPL. Both - the user mode as well
as the supervisor mode of the mc68030 are executed on
user level using a virtual machine. This makes the way free
for running TOS/MiNT just beside other processes in a similar
way as L4Linux does on L4. It also shows that the Coldfire
is an ideal platform for deploying VMM techniques because
all privileged instructions trap when executed in
Improvements of the CF build system
I improved the CF build system to be as easy to use as
the L4 build system. I choose a slightly different approach
for the handling of libraries. If fact - I do not actually
build libs but instead build libraries in place where they
are used. This has two big advantages:
I discovered a misbehaviour of newlib-1.11.0 when
- Inter-library dependencies are correctly resolved. Thus,
when changing one file of a lib a dependent target rebuilds
the affected object file using standard mechanisms provided
- Only the parts of the source tree must be built that are
of particular interest. For example, when I want to
build DOpE for L4 using the L4 build system I have to
successfully (!) build the whole L4 tree. When building
DOpE with the CF build system I only have to type 'make'
in its directory.
is called for printing hexadecimals. As a quick fix I took
vsnprintf function of DietlibC and use this
instead. This makes me think about completely replacing newlib
Building gcc-3.3.2 tool chain for Coldfire
I began to play around with the cf68klib - a library that provides
a way to run unmodified m68k binaries on Coldfire processors. For
this I need a compiler/assembler that fully supports the MCF5407.
I decided to check out and build xgcc including gcc-3.3.2,
binutils-2.14 and newlib-1.11.0. So now we have an up-to-date
toolchain for our experiments.
Ah... btw, happy new year!
New DOpE Window attributes
DOpE Window widgets do now have four new attributes for requesting
and manipulating the position and size of the window regarding its
actual work area. The attributes are named
These attributes allow the implementation of applications with
fullscreen or similar functions without any assumptions about the
border size of DOpE windows.
Graphics hardware acceleration with the Coldfire board
For boosting the graphical output performance of DOpE running
on the MCF5407 evaluation board I decided to explore the
hardware drawing capabilities of my Matrox graphics card a bit.
At the end of the day the Matrox card performed some drawing of
lines and filled rectangles.
Interrupt-based driver for Wacom Artpad
After studdying the exception and interrupt handling of the
Motorola Coldfire I implemented an interrupt-based driver
for my Wacom Artpad. Therefore, it is now possible to
interact with DOpE by using the Wacom tablet.
The m68k-elf-gcc compiler allows the implementation of
interrupt handlers completely in C - very cool!
Serial interface of the MCF5407 evaluation board
I implemented the initialisation and read/write routines
for the UART serial interfaces of the MCF5407 evaluation
board. The Coldfire talks happily with Minicom and even the
basic communication with my Wacom Artpad runs without
flaws now. The source codes of uClinux and Motorola's
Dbug tool are a big help.
I also began to create a simple make system for my coldfire
experiments - inspired by the L4env build system BID but
Photos of Cancun/Mexico
I put some photos of my trip to Cancun/Mexico online:
DOpE runs on the Coldfire Evaluation board
Tonight I ported DOpE to the Coldfire Evaluation board. It displays
a window on screen, already. The graphical output seems to be very slow
because of the weird PCI bridge used on the board. Anyhow, I did not
invest a lot of time for optimizing the time-critical path between DOpE and
the frame buffer, yet. There is also no input device available, yet.
I have to solder an adaptor for a mouse and code a mouse driver before
I can do anything useful with DOpE on this platform.
Matrox works on Coldfire Evaluation board
Today, I finished my port of the Matrox driver from Linux-2.4
and got my Matrox graphics card properly initialized - yeah!
The best of all: by using Krishna's idea of his Device Driver Environment
I managed it to port the driver without modifications of the original
driver code. This will ease the port of other drivers (hopefully) in
Back from Cancun/Mexico
Back in good (?) old Germany. During the last week I was in Cancun/Mexico
at the Real-Time Systems Symposium (RTSS) to present DOpE to the
real-time community. This was a great experience because of the chance
of having a big audience to present my work to and - because of the
great location just at the Caribbean See. My contribution to the RTSS
is available here:
Like every year I attended to the Paracon Atari convention and as always -
this was a lot of fun. This time I brought the Coldfire evaluation board
with me instead of a Falcon. During the convention I managed to port
the Matrox driver from Linux-2.4.20 to the Coldfire via a DDE-a-like
approach. At the end of the day (or night?) the driver code even started
to run and identified my graphics card but did not initialize the it
I like to thank the organizers for these great days and all other attendees
for coming. Special thanks to Pieter van der Meer for showing us his
new kick-ass effects on the Falcon!
New project website for DOpE
I created a new project website for the DOpE project with the
look and feel of the other OS Group websites. There is also
a small summary of the (more or less) available client
Demonstration scenario for RTSS
The demonstration scenario for the presentation of DOpE at the
RTSS'03 conference is ready, now. It features L4Linux running
on a RAM-disk image including the X-Window-System, the VScrTest
demos, the DOpE-Presenter and DOpE-Log as applications.
The slides for the presentation got revised after my test
presentation at the OS Group.
Unregistering DOpE client applications, Input-2.6
DOpE client applications can now unregister at DOpE. If they do so - DOpE
closes all associated windows, destroys the application's namespace and
destroys its widgets. Also, reassignments of variables cause the old
associated widget to decrement its reference counter.
Christian finished his work on the new input lib based on Linux-2.6
input drivers. The new drivers work flawlessly with DOpE. We hope that
quarrels with some strange hardware are gone now.
New Screen widget
I started the implementation of the new widget type "Screen". In the Future, it
will be the abstraction for virtual screens. Right now it offers no functionality
except a way to request the physical screen size by client applications. E.g.
application that want to provide fullscreen output. For every DOpE client session
a DOpE variable "screen" is added to its namespace per default. A client can
request the dimensions of the used screen by requesting the "w" and "h" attributes,
for example via:
dope_req(app_id, req_buf, 16, "screen.w");
scr_width = atoi(req_buf);
dope_req(app_id, req_buf, 16, "screen.h");
scr_height = atoi(req_buf);
Small changes in VScreen and Background widgets
Motion events of scaled VScreen widgets provide now values that correspond
with coordinates of the associated pixel buffer. This way, even a scaled
X11 window can be handled with the mouse as expected.
The Background widget is now accessable via the DOpE command interface.
Similarily to the Frame widget it can hold exactly one child widget. Thus,
it can be stacked between a child and a parent widget to fill the background
of the child. This is especially useful for windows with (for performance
reason) disabled background.
The Overlay screen window features now a button for resetting its size
to the native screen dimensions.
I created a new RAM-disk image for L4Linux which contains
the full setup for running the X-Window-System + WindowMaker
in ca. 30MByte of size. Within the OS network a working demo
of DOpE + L4Linux + X11 + VScrTest can be started via the
Grub config file at:
Back from New Zealand
Christin, Nils and me are just back from our journey to New Zealand.
I put some of my photos on a dedicated section of this website:
DOpE available at our remote CVS
I made the source code of DOpE available to the public via
our remote CVS under the terms of the GNU General Public
Licence. See the DOpE section of this website to learn how
to check out the sources. You will also need the Fiasco
kernel, the L4 Environment and the DICE IDL compiler to
build and run DOpE. All these things are available at our
remote CVS, too.
HTML backend for Gosh
Gosh - my text conversion tool - can now output HTML as well as
Latex. I implemented the HTML backend as an external style-file
which implements the needed backend functions. It can be used
Until now tables and images are not supported, yet - I will
implement these features as soon as I (or someone else) need them.
gosh --style html.gosh sometext.txt > sometext.html
Technical Report about DOpE
I published a technical report with the title "DOpE - a Window
Server for Real-Time and Embedded Systems". It is a nice introduction
into the overall architecture of DOpE and presents some mechanisms
used for handling real-time. You can find the technical report at
the file section of this website:
My SGI Indigo2 works again
I reanimated my old SGI Indigo2. Thanks to Christian Boehme for
supplying a SCSI harddisk to me :-) Playing with the SGI is much
fun. Sadly, I have too little spare time to pay as much attention
to this nice machine as it would deserve.
DOpElib is now thread-save
The interface of the DOpE client library had be be changed to
suit the needs of multithreaded applications:
I also changed the interface of the VScreen library. Now the
functions vscr_get_fb and vscr_get_server_id are pure
utility functions which take an application id and a VScreen
widget as arguments. So the actual handling of shared memory
is encapsulated within the library, now.
- dope_cmd does not return the result string as character pointer
anymore. Instead, only an integer error code is returned.
- the new function dope_req executes a DOpE command and requests
the result string. The function gets an additional destination
buffer and its length as parameter.
I adopted all packages which use DOpE and which are present at our
CVS to the new interface already.
Finished submission for RTSS conference
I finished my submission for the Real-Time Systems Symposium.
It is an extended abstract of the original paper with only 4 pages.
A lot of thanks to Michael Hohmuth and Markus Völp for their
In december, I will have the chance to present DOpE in action
at the conference.
Experimenting with Radeon7500 PCI on the Coldfire board
I just bought a PCI version of the Radeon7500 graphics card to
use it on the Coldfire Evaluation board. Sadly, the Radeon seem
to interpret the PCI 2.2 specification slightly different than the
Cypress co-mem lite PCI bridge which is used on the MCF5407
evaluation board. I cannot even access the PCI configuration space.
So I will stick to Matrox, again.
My IBM Thinkpad died
It seems that I stressed my beloved IBM Thinkpad a bit too much
during the past weeks. It decided to go out of function for some
vacation at IBM.
First version of the Overlay Window Manager works
Now, as I implemented all components of the overlay window manager
concept it was time to plug them together. They seem to get along
with each other quite nicely for the beginning. There are still
a lot of missing functions and some bugs in the IPC stuff. Adam
and me installed a small presentation scenario on a T30 notebook
which works good (at least a couple of minutes).
X11 window manager with Overlay support
I implemented the third component of the overlay window manager
concept: The X11 window manager. For each X-window it creates
a corresponding overlay window and keeps the properties
(size, position, stacking order) of both consistent.
Window events on overlay windows must be forwarded to X11
and the other way round.
L4Linux kernel stub forwards Overlay Input events
The L4Linux console stub has two tasks:
- It displays the boot output and login console on a pSLIM
- It forwards input events which refer to the pSLIM widget
to the Linux kernel. This is done by simulating an USB
keyboard and mouse.
Now, I added support for communicating input events from
the overlay server into the Linux kernel, too. This is not
meant as a final solution. Later there will be a dedicated
XFree input module.
First HTTP request from Mozilla to FLIPS!
Today I got FLIPS to threat a HTTP request from Mozilla
via a real network device driver!
XFree86 driver for Overlay Screen
I implemented a driver module for XFree86 that redirects the output
of the X-Window System to the Overlay Windowing Server. It is
functional but far from being perfect. Something with the invalidation
messages to the Overlay Server seem to go wrong. I decided to drive
the displaying DOpE window as a periodically updated real-time widget.
This is not nice but it works.
Framebuffer and input abstraction of Overlay Window Manager
During the past two nights I successfully implemented and tested the
framebuffer and input device abstraction of the Overlay Window Manager.
For easy client programming I implemented three libraries - one for
each possible role of a client:
I tested the screen and input libraries successfully under plain Linux (via
socket-idl), pure L4 and L4Linux.
- screen driver (opens overlay screen)
- input driver (receives input events regarding the overlay screen)
- window manager (pretends which area of the overlay screen is covered by windows)
Overlay windowing server
I started the implementation of a new L4 server which enables the
multiplexing of multiply windowing servers - such as the X-Window System -
within one environment - DOpE. With the overlay windowing server each
X-application that runs on L4Linux will reside in an own DOpE window. I
hope to achieve a more user friendly integration of these two worlds.
New tool: fig2pov
Watching TV in the evening was too boring... so I started to code a new
tool called fig2pov. It is a small script that reads a xfig vector graphic
file and converts it into a POV-Ray scene description file to render it
from a slightly rotated view angle. Until now, the tool supports boxes
with frames around them, all default xfig colors (which are kind of ugly)
and text (with support of left and centered alignment).
Mini-HTTP-server for FLIPS
For demonstration purpose I implemented a minimalistic HTTP-server for
FLIPS. It's start can be triggered by a new Flipsterm command "httpstart".
Additionally, I implemented a simple HTTP-client that performs a HTTP-request
to the HTTP-server and dumps the result.
IP Route for FLIPS
I began to port the IP Route package to FLIPS as a Flipsterm command. It
will replace the old ifconfig and route stuff. While porting IP Route I
discovered some issues with the IP Stack and fixed them. Some missing
socket function has to be added to the IDL Interface of FLIPS, too.
New Flipsterm command: mini-ifconfig
I included the small network interface configuration tool - written by
Krishna - into Flipsterm as command. Now it is possible to interactively
switch on network interfaces and assign IP addresses and netmasks to them.
Flipsterm as a separate user task
Flipsterm is our interactive command interface to the FLIPS IP-Stack.
Originally we linked it directly to the FLIPS server. Now as we have an
IDL interface it was time to move Flipsterm to the outside of the IP-Stack.
While doing this I discovered a lot of problems, such as some ioctls that
pass nested structures to the Linux kernel. This worked well when the
client resided in the same address space as FLIPS but now we have a
problem - for example with ifconfig which uses such nasty ioctls.
While restructuring Flipsterm I applied a lot of improvements to it such as
exit-call-safety and distinct namespaces for all commands via partial linking and
IDL interface for FLIPS
I have put a lot of work into the IDL interface of FLIPS - our
port of the Linux IP-Stack to L4. Again, there were a lot of bugs in
DICE (our IDL compiler) which delayed my work. I also suffered under
those damn socket ioctls - This interface is definitely for the ass!
After a hard fight I got a small network interface config tool -
written by Krishna - to work as a separate client and communicate
to FLIPS via the IDL interface.
There are also a small client and server application running
happily as separate tasks, now.
I implemented a small library for the mapping of standard Linux-a-like
socket functions to IDL calls and for implementing some DICE-bug-workarounds.
Tables for Gosh
I just implemented support for tables into Gosh. This feature was
requested by Christin and Christian. Now, Gosh is a quite powerful
tool for prototyping textual documents.
DOpE presenter using a file provider
Thanks to Jork, the DOpE presenter is now capable of loading
files via an L4 file provider, such as tftp and ext2.
New event binding for DOpE
I introduced some new event bindings into DOpE. The Button widget provides
If these bindings are used, DOpE manages the pressing and releasing
of the button automatically. For this I implemented a new "touch" state
into the UserState component of DOpE.
- "click" - which is delivered each time the user click on a button
- "clack" - which only triggers if the user clicks on a button and
releases the mouse button over the button. This binding
should be used for some critical cases where the user
needs still to have the chance to cancel an action, even
when he already pressed a button.
Following a request by Carsten Rietzschel, the Scale widget does now
provide the following new event bindings:
- "slide" - which is delivered each time the user moves the slider a bit.
- "slid" - which is delivered after the user releases the slider.
New memory leak debugging tool for L4
I implemented a simple memory leak debugging tool for L4 called "Petze".
Instrumented applications report all malloc() and free() calls to a separate
server - together with some statistical information such as the calling source
code file. The Petze server collects all these information and provides
statistical data to an analysing client. Until now, there exists only a
very primitive DOpE client for triggering a dump of the current statistics
and deleting all collected data.
The nice feature about Petze is the easy way to instrument L4 application by
only including an additional Makefile template.
Internal restructuring of DOpE
I restructured and cleaned up big parts of DOpE in order to prepare the
first release. There went a lot of work into a slightly better internal
representation of widgets. I also shrinked down the usage of libC
functionality due to severeal inconsistencies beteen the implementations
of libC (for example missing float support in Oskit's snprinf).
Quake on DOpE
There exists now a port of Quake for the DROPS platform. Thomas Friebel
ported libSDL to DROPS on the basis of the VScreen widget of DOpE. Quake runs
as non-realtime DOpE application at a frame rate of 48Fps on my Celeron test
system - quite playable.
Matrox Mystique on Coldfire board
After a session of over 20 hours I got a Matrox Mystique
graphics card initialized with the Coldfire evaluation
board. There were a lot of problems to solve, such as
how byte accesses via the PCI bus are performed by the
Cypress PCI bridge (the bridge performs some kind of
endian conversion for 32bit accesses with the effect of
trashing 8bit accesses). The Matrox documentation I have does
not specify how to set a video mode. Thus, I digged hours
in the Linux framebuffer code and take out the needed
initialisation stuff. Thanks to the great valgrind debugger,
I determined all variables that had to be initialized and
I got the code running on the Coldfire.
Now I have a video signal. The next step is to initialize
the framebuffer in order to display some fancy stuff.
IDL interface for FLIPS
I implemented an IDL interface for the FLIPS server. Up to
now the interface basically is a socket interface - which
sounds easier than it is in reality. Firstly, because DICE -
the IDL compiler - constrained my work due to a number of
bugs. Secondly, some interface functions such as accept and
receive have blocking behaviour. This leads to the multithreaded
server issue, again - a topic which does not really brighten
my day. I solved the issue by including some kind of session
call which creates a dedicated server thread for each client.
Finally, I implemented a small test server and client based
on the socket interface and they work nicely. (At least until
a memory leak in DICE generated stub code has eaten all memory)
VScreen grabs mouses
In order to support Thomas Friebel with his work with porting
libSDL to DROPS I introduced a mouse grabbing mode into the
VScreen widget. When this mode is selected the mouse cursor
is locked within the VScreen widget when the user clicks
onto the Widget. Additionally, the client can define the
mouse position within the widget manually while the mouse is
grabbed. The user can free the mouse using the [pause] key.
New tool: GOSH
Since a while I use an own (hacked-together) tool to convert plain
ASCII text to Latex and HTML. This way I can avoid typing of Latex
commands or tags when I write text. The tool detects a number of
textual elements such as nested headlines, items, enumerations,
references etc. and generates the corresponding Latex commands
automatically. Now I completely rewrote the tool in order to
enable multiple backends and a more flexible and extensible way
of text parsing using regular expressions. I called the new tool
gosh. It is capable of handling nested items and enumerations,
images, citations, references, descriptions, accentuations etc. -
all texual expressions I need to write text documents.
Stoned from the Underground
This weekend, Krishna, Christin, me and some friends attended to the
third Stoned from the Underground festival at the Nordstrand in Erfurt.
This time the majority of the bands were unknown to us and I personally
would consider the most of them to be Rock'n Roll bands rather than
Stonerrock bands. Anyway, the music, weather and the atmosphere were
Alignement of child-Widgets inside Grid-cells
I just implemented another feature request by Carsten - the alignment
of child-Widgets inside their corresponding Grid cells. The alignment
can be specified as additional parameter to the place-function - for
grid.place(button1,-column 1 -column 2 -align "nsew")
The letters stand for the alignment directions (north, south, east and west).
If complementary directions are specified - for example east and west - the
child widget is automatically stretched to meet both alignments.
New "change" binding for Scale-Widget
Scale widgets provide now a binding of "change"-events that enables client
applications to trigger function calls to the changes of a Scale value.
Linux Console Stub
Since L4env uses Dice as IDL compiler my Dual-Linux-Console-Stub,
that works with Dropscon as well as with DOpE refused to build anymore. I fixed
this now because Jens Syckor really needs the L4Linux console window in
conjunction with DOpE. The stub works with DOpE, again - I have not tested it
with Dropscon, yet.
My long-term-goal is to kick the stub into trashcan and use a special DOpE-getty
instead. This way, the L4Linux-kernel does not need to be changed in order to
provide a textual console for DOpE.
ObjectDive exports .dot
I just added a simple .dot export function to ObjectDive. This was a feature
request by Martin, who was so brave (or should I say insane, hehe) to try out
ObjectDive with 700 files!
Back from With Full Force
I just visited the glorious With Full Force 10 festival during the last weekend.
This time the lineup was incredibly cool - featuring bands such as Six Feed Under,
Smoke Blow, Slapshot, Napalm Death, Saint Vitus, Soulfly, Sepultura and a lot more.
Support for vertical Scale widgets
There exists now the new attribute "orient" of the Scale
widget that defines the orientation of the Scale. It can
either be "vertical" or "horizontal", which is the default value.
One-word strings for DOpE
I added one-word-string support to the command interpreter of DOpE.
That means, that strings can be specified without quotation as long
as they consist only of valid identifier characters (plain letters) and
CT60 on its way back to ith father
I just sent the CT60 + my Falcon motherboard back to Rodolphe
Czuba who will hopefully fix a strange booting error and
install the CT60 properly (with soldering).
Received my CT60
Today I received a CT60 accellerator for my beloved Falcon. So most
probably, I will dedicate the next weekend for playing with this new
toy. The hardware looks really professional. I am curious to see it
Scale widget for DOpE
The Scale widget for DOpE is working now. It understands the attributes "from",
"to", "value" and "variable" - Thus, it can be associated to a Variable widget
to synchronize values with other widgets.
Restructured the user state management: The Userstate component provides
now only one mechanism to implement different widget's behaviour into the
widget components. Now is nearly no policy left in the userstate component.
Float attribute support for DOpE widgets
DOpE's widgets can now use floats as attributes. For this, parts of the
command interpreter had to be changed.
First experiments with a Matrox Graphics card on Coldfire Evalutation board
I just began to explore a Matrox 1064 based graphics card using the Coldfire
Evaluation board by Motorola. Firstly, I wrote PCI initialisation code (assignment
of PCI address spaces, evaluation of the PCI config space). After that I tried
to initialize the card as described in the specification - until now it does not
work, yet. Most probably - there are big/little-endian issues with the access of the
PCI device's hardware registers.
I also studied the Linux frame buffer driver code for Matrox gfx cards - waahh, what
Variable widget for DOpE
I implemented a mechanism to allow multiple widgets to share a common
state or value. There exists now a special widget type "Variable". Widgets
can register at such a Variable and get notified for each change of the
value. I added the support of Variables to the Label widget.
Additionally, I began the implementation of a Scale widget which will also exploit
the Variable feature of DOpE.
I spent a whole day with trying to access a S3 Trio64 graphics card via the
Coldfire evaluation board. The card does not report any I/O PCI address space.
After hours of studying and extracting the appropriate init code of SVGAlib which
is completely based on I/O port access I am still in the dark how such I/O port
accesses can be performed with the strange PCI bridge (Cypress AN30420C) used on
the Coldfire board.
DOpE supports YUV now
I implemented support of the YUV color space format into the Gfx-layer
of DOpE and added this feature to the VScreen widget accordingly. I also
implemented a small demonstration program that illustrates how to use
the VScreen widget in YUV mode.
Label widget for DOpE
I restructured and simplified the widget structures of DOpE. The
functionality of Window and Frame is clearly separated. Additionally,
I implemented a new Label widget. Thanks to Carsten for his motivating
feature request .-)
XFree86 stub based on VScreen
After hours of fumbling, I managed to get the XFree-bitch to display something like a
X-desktop on a VScreen widget.
Talk at Unitag2003
I had a promotional talk at Unitag2003 where I explained some principles
about the DROPS project and presented a demonstration of DROPS + DOpE + L4Linux +
VScrTest (real-time demo) + Presenter. As it seems, some of the listeners were somehow
interested in our work. Thanks to Jork, Adam, Michael and Ron for your support :)
Paper for RTSS conference submitted
With this day my heavy stress with writing my paper for the RTSS conference
ends. The last two weeks I had to work ca. 15h per day to get the paper
finished. Despite the load of stress, it was a great experience to work closely together
with Hermann. Thanks to all test-readers and critics of my paper (Martin, Michael Peter,
Jean, Frank, Michael Hohmuth, Sebastian, Andreas).
Falcon-Demo "_" released
We (Charon and me) just released the new Falcon-Demo by our demo group Escape.
It won the Falcon Demo Competition at the Error In Line #3 convention.
The awesome music is - as everytime - by 505/Checkpoint. The designing and
packing work as well as the lighting fast 3D engine was done by Charon.
I contributed the first part of the demo (blur-tunnel, focus-blur-wireframe,
super-blurred-environment-mapped-star) and the particle-in-wireframe-cube effect
with changing blur focus, and - of course - the demo engine.
Error In Line #3 is over
The Error In Line #3 coding convention is over now. The big stress of organizing
the event was really worth it. Over 120 people from 12 different european
countries attended and released great productions for my beloved computer
platforms. We (Charon, Nils and me) even managed it to finish a Falcon Demo,
which won the Falcon Demo competition. Defjam released his long awaited ST-Demo
"Posh!" and won the ST Demo competition. Nils won the tracking and soundchip
Ifconfig for Flips
Today I ported ifconfig to Flips - linking a Linux userland application to
a part of the Linux kernel running on the L4 microkernel is quite a nightmare.
There is a horrible mess of nested includes from Linux, Linux-kernel, L4, local
includes and OSkit - argh! After struggling a whole day I managed it to
port ifconfig over to Flips with only some code modifications. The parts
of ifconfig which need glibc functions such as gethostbyname etc. do not work, yet -
because OSkit's libc does not feature these functions. I already inspected diet-libc
and will probably steal this functionality from there.
Command shell for Flips
Created a command shell for Flips - our Linux-IP-Stack running on the
L4 microkernel. The shell is based on my Terminal library and runs happily as
DOpE application. Thus, it supports command history and colored text output.
At the moment the shell is statically linked to the IP-stack. It is primary
intended as a tool to configure the Linux-IP-Stack interactively.
Gfx abstraction layer works
During the last two days I completed my work in the new Gfx
abstraction layer of DOpE. For this I restructured big
parts of DOpE - leading to a lot of simplifications. Finally
I added the support for 8bit indexed images into the Gfx 16bit screen
Due to the portable design of DOpE I was able to test the program
in my Linux environment. Gdb saved a lot of debugging time.
The interface is now ready to be used by Robert to build
the hardware accelleration infrastructure of DOpE.
Tonight Jens was at my place to hold a Coldfire-programming session.
After 12 hours of work we managed the weird PCI bridge of the
Coldfire evaluation board to access
the PCI bus in the way we wanted. Finally we even got an ATI Rage
Graphics card to show a pict... ehrm... flickering! Yeah! Sadly the
whole thing crashes completely as soon as we try to touch the PLL
of the graphics card. The documentation of the Rage card says no
word about how this beast is initialised - just because PCs do that
via built-in x86 init code.
Widgets use drawing primitives of Gfx module
Implemented the usage of the drawing primitives of the Gfx module into
Background, VScreen, Terminal and pSLIM widgets.
I enhanced the Gfx interface by adding functions for sharing data with other
tasks - this is needed for the VScreen widget.
I also implemented a new Gfx handler module for 16bit images.
Adaption of Windowmanager and Widget modules to new Gfx interface
The Windowmanager module uses now the new gfx interface to open a screen
and handle clipping. The used screen is now propagated to all widget drawing
functions. For this - all widgets had to be slightly modified.
Implementation of new Gfx layer of DOpE
Began the implementation of a new graphics abstraction layer for DOpE
which will make the way free for the support of multiple screens,
multiple color depths, hardware acceleration etc. This new interface
is needed by Robert to implement the hardware acceleration infrastructure
for DOpE. The new gfx component offers an interface to access all
graphics dependent things such as graphics containers (screen, images...),
mouse cursor, drawing primitives and clipping.
Support for multiple DOpE clients within one application
In order to support multiple DOpE clients within one application I changed
and restructured big parts of DOpElib. Now it is possible to implement
multiple DOpE client instances with dedicated action listener threads
in one task. This is good for e.g. using libterm together with a custom
DOpE application. The interface of DOpElib had to be slightly modified for
Hardware accelerated graphics for DOpE in sight
Robert Wetzel is currently working on a graphics hardware driver infrastructure
for DOpE. His first tests with Matrox and ATI Rage gfxcards were successful.
He even created a MGA accelerated version of DOpE as a test - it runs at a
marvelous speed! - thus the name of his project: DOpE on Speed.
Today we defined the interface for an abstraction layer of graphics operations
for DOpE. This interface will be the connecting point of Robert's and my work.
DOpErun utilises command line history
The DOpE version of the Run program makes now use of the command line history
functionality of libterm.
Command history support for libterm, DOpElog
Added command line history functionality to the terminal library.
The implementation stores strings of variable lengths one after each other in a
ring buffer. So basically all memory that is dedicated to the history buffer is
used for storing information. There is also no need to specify any maximum
line length during the initialisation. This is good because the average line
length is mostly far lower than the maximum line length.
Thomas Friebel created a DOpE version of the logserver. This is the first official
contribution to DOpE from another person than me :-)
Telephone conference with Intel
Hermann Härtig is visiting Intel at the moment. He had a talk about the DROPS
operation system and DOpE. The people at Intel invited me to join the meeting
via telephone conference to answer questions. Although the connection to the
USA was very noisy it was an interesting experience for me.
Got a notebook
After a long time of waiting my notebook finally arrived - yippie! Working on
this computer is much more fun than on my old PC gurke. Also the screen is
razorblade-sharp - when looking on my old crt screen after working some hours
on the notebook it is like looking through a layer of milk. After some fiddling,
installing and configuring I got DOpE compiled and run on the notebook. I had
to make some small changes in the linux version of dopelib - strangely the
code to find a free port did not work anymore when placed in the same file
as the other init stuff - probably some header file conflicts.
Working on paper for RTSS
I continue my work on a paper for the RTSS conference. The paper will
be about my real-time windowing system approach. The draft of the content
is ready - now it is time for the arrangement. I already revised all the
graphics in order to make them smaller in size. I managed it to reduce the
size of the graphics from 22MByte to only 1.8MByte by exchanging raster
graphics elements by PostScript vector graphics.
Falcon DSP coding
The last two days I had holidays which I used for coding on the Atari
Falcon again. The result is a pretty nice smoothing routine for the
DSP56001. This routine makes the way free for a couple of new effect ideas.
uCLinux on Coldfire4
We managed it to get uCLinux compiled and let it run on the Coldfire4 Board.
The GCC developer tools seem to work very well. We also started to program
the PCI bridge chip, which is pretty exotic. After some hours of digging
in lots of hardware registers we got the beast to tell us the vendor and
device id of our PCI card - yeah!
My SGI died
Damn! The harddisk of my SGI Indigo2 just crashed! Maybe that is the revenge
for not turning on this baby for so long... sniff.
Charon arrives - Coldfire board works
Today is a great day because of two things: Firstly, Metty aka Charon arrived
today. He will stay one week at my place to code and have fun. Secondly, we
managed it to successfully communicate to the Coldfire4 evaluation board via
a serial connection - what a great toy to play with!
Got Run to run
Thanks to the new DOpE term library I was able to port Frank's great 'Run'
program to DOpE. To port the program I did not had to change the original
source code of the program. I just emulated the needed function of libcontxt
by using functionality provided by the new libterm.
The program is not fully functional, yet - the port is intended as a test
of libterm. Obviously, the Terminal widget has still some weak points such
as the lack of a history buffer, intelligent sliders etc. These things will
be improved soon.
DOpE term library
Started to implement a library for the implementation of text based
applications for DOpE. Until now text based applications (such as Run)
use the ConTxt lib for this task. The new DOpE term library will feature
a similar functionality. Until now two functions are implemented and do
A text based application has to call term_init at first, which opens a DOpE
window containing a Terminal widget. When exiting the application, the function
term_exit can be called to close the window and to unregister the DOpE
application. The term lib is functional with the Linux and L4 version of
DOpE (in fact, it is built completely in top of DOpElib).
- term_printf with the same semantics as printf
- term_getchar with the same semantics as getchar
Coldfire4 evaluation board
Today I received a package from Motorola containing a
Motorola MCF5407 evaluation board
. Gerald Kupris from Motorola borrows us (the Atari
Coldfire Project team) this wonderful piece of hardware without any charge
to enable us to explore the Coldfire4 CPU. Thanks a lot Gerald for this
Format strings as DOpE commands
Extended the functionality of DOpElib:
- new function dope_cmdf, which allows to specify a format string as
command argument. This makes the code of DOpE-clients much better
readable - no sprintf stuff is needed anymore.
- implemented semaphore functionality in DOpElib. This functionality
is needed for DOpElib internal synchronisation (command execution
buffers, listener server startup) but can also be utilised by other
libs, which make use of DOpElib. It is not intended to provide this
functionality to client applications because this functionality is in
no way related to DOpE's functionality.
Linux-stub, DOpElib improvements
In order to create a user interface for Flips I can go on with the development
of DOpE a bit. The user interface will be command line based. So this is a
good chance to create a contxt-a-like library for DOpE. Before doing that
I had to made a bunch of smaller fixes:
I also made some tests with writing DOpE-applications directly under L4Linux
and got DOpEcmd successfully to run. L4Linux is a good platform for
developing DOpE applications because I can just restart a L4Linux program
instead of rebooting the test computer. These tests will also allow me to
go on with my overlay windowing system ideas later.
- updating the Linux-stub of DOpE, because Jacob asked for DOpE and he needs
- restructuring DOpElib to simplify the platform dependent parts of the lib
Flips boots up
After Krishna kicked out the last couple of unresolved symbols and fixed a
small bug we managed it to boot up Flips. Now we can make some real-life
tests. This enabled me to debug my proc and sysctl interface emulation.
The result is an almost working pseudo proc-fs. All proc entries are
generated during the startup of the IP-stack by native Linux code.
At the current stage it is possible to read proc entries and list
directories. Writing to proc entries could be implemented in a similar way.
So it seems that it is sufficient to provide /proc as the only configuration
interface (although sysctl is indirectly being used).
Sysctl and /proc interfaces of Flips
Flips is the name of our (Krishna's and my) port of the Linux2.4.20
IP-Stack to L4. The past days I digged in the depths of the Linux
source tree and added the configuration interface to Flips.
In Linux there exist two nice interfaces to configure kernel parameters:
sysctl and proc, whereas sysctl is the older of those. I firstly added
sysctl functionality to Flips. It provides the infrastructure for holding
all parameters of the IP-Stack. Secondly I added a proc-fs emulation
to supply a proc-a-like configuration interface to Flips. In fact - the
proc-entries at /proc/sys/net are generated automatically out of the sysctl
structures - so both interfaces are needed.
Created a logo for the Mikrosina project based on the shape of our
Cebit scene. The idea of this logo is by Krishna. He wants to make
the logo look like a badge with a round surface. I think the result
is quite ok:
New picture in POV-ray section
I added a new picture to the POV-ray section
of this website. The scene is an illustration of address space separation
as done by the Fiasco microkernel. It was taken as basis for the presentation
of the Mikrosina project at the Cebit'03 fair.
Coding session with Krishna
It is time again to explore the inner depths of the Linux kernel and
Chosneck intro released
Last summer I coded an intro for the polish Atari Diskmag 'Chosneck'.
Finally, the diskmag is released now - and again it is a masterpiece!
Thanks to the Chosneck-team for their great work.
Enhancements for VScreen
Added some nice features to the VScreen widget:
The Presenter uses now the VScreen widget instead of pSLIM - leading to
better performance and a smaller code size. Additionally, the presented
images are now always centered on the screen.
- new attribute 'framerate' - the default value of this attribute is zero.
That means that no cyclic update is performed by the widget. Until now
the only supported value except zero is 25 fps. In this case the widget
gets registered at the real-time manager of DOpE to force a cyclic
- new method 'refreh' - this method forces the widget to refresh a
specified area or the whole widget. This method is useful in combination
with a framerate of zero. In this case no communication to the widget-
server is needed to use the VScreen widget with non-real-time applications.
VScreen for Linux
Thanks to the recent changes of DOpE there is now an implementation
of the VScreen widget available for the Linux version of DOpE. That
means that the VScrTest demo runs now also under Linux!
There exists also a Linux version of libVscreen now.
Shared memory abstraction for DOpE
I implemented a new abstraction to handle shared memory in order to
enable a platform independent implementation of the VScreen widget.
The VScreen code is now splitted into two parts:
- the platform independent VScreen widget
- the communication interface dependent VScreen Server
The VScreen server is now only needed to synchronise the client with
the screen update. The mapping of shared memory blocks is now done
by the widget itself using the Shared Memory module.
The socket layer of our IP-port is ready. It replaces the original
socket layer of the Linux kernel and is simplified a lot (all
fs-stuff and the support of multiple address families is left out here).
It will primary be used for testing the IP-stack later.
We also managed to reduce the number of unresolved symbols of the
IP-stack down to 37.
Coding session with Krishna
This weekend we (Krishna and me) will begin our practical work on
porting of the IP-stack of Linux 2.4.20 to L4. The first step
will be to isolate the IP-stack from the rest of the Linux kernel
by implementing the needed Linux-environment. DDE will hopefully be a
Exploring the inner structure of a large project on the base
of its sourcecode or nm-output can be quite difficult. This was
the reason to create a small tool to interactivly visualise the
relationships between object files. Each object file is displayed
as a node. For each observed object node the defined and external
symbols are detected and their relationships are displayed as
arrows between nodes. The user can freely arrange the nodes
on the screen, request interface-functions by clicking on the
associated arrow. It is also possible to remote-control vim to
display the positions in the source code where a symbol is
used or implemented.
L4Linux text output is running again!
I successfully ported the L4Linux-stub to the new DICE
interface. It is working at least with DOpE - console to follow after
the official merge of both stubs. The next hop will be the porting
of the XFree4 stub to the new DICE interface.
Also a lot of other problems with DICE were solved. Thanks a lot
to Ron for his valuable support!
Transition to DICE
I am still busy with porting DOpE to the new IDL compiler DICE.
Major parts seem to work now but there is still a long list
of open issues to solve.
Beside that I began the work on a paper about my real-time windowing
Added 'About' and 'DOpE' section
Thanks to Mr.Allhoff-Cramer for giving me the motivation to
complement this website a bit. The 'DOpE/Documentation' section
is still missing. I recommend to take a look at the 'Files'
section to access the available documents about DOpE:
Back from Boston
During the last week the OS-group was in Boston/Massachusetts to visit
the OSDI ("Operating Systems Design and Implementation") conference.
It gave an interesting insight into the today's research topics in
the field of operating systems and networking.
Changing DOpE's IDL stubs to DICE
Began to replace the flick and ORBit related code with a DICE
compliant implementation. DICE is an IDL compiler - developed
by Ronald Aigner. It is capable of creating stub code for L4
and Linux and features very similar programming interfaces
for the two architectures. This fact should simplify a lot of
DOpE's inter-process-communication code.
DOpE and DOpElib for Linux
Ported the Linux version of DOpE and DOpElib to the L4
Makefile system. The Linux version is primary intended for
test purpose and the easy development of platform independent
widgets. It does not provide the whole set of features as the
L4 version. There is now also a Linux version of the DOpEcmd
client example available now.
Windowmanager for L4Linux
Began to implement a window manager for L4Linux which
will utilise DOpE for window management. The aim is to
integrate X11 windows into the DOpE window environment.
L4DOpE ported to the new L4-Makefile system
L4DOpE now supports the new L4 Makefile system. I had to
restructure the source code a bit but now everything is a
lot more clearly arranged. Since now is a good time to let
other people at the OS Group take a look at my work I added
the current version of DOpE into the CVS tree of the OS
The Paracon4 convention is over now. Although there were only
a few visitors it was still a nice event. I personally was not
very productive during the weekend but Charon showed some new
and impressive 3D routines. Greetings to all participants,
especially to the organisers.
Linux version of DOpE up to date
Implemented missing functionality of the Linux version of DOpE.
Now, DOpE for Linux also supports event-bindings. I also started
to port the VScreen-widget to the Linux version. For platform
transparent client programming I started the implementation of a
library for the usage of VScreen widgets.
Cleaned up the whole source code of DOpE, added short file descriptions
The first week of my work at the university is over now. ... a lot
of new impressions and experiences for me.
The final presentation of my diploma is over and everything went
just fine. Thanks to all people, who supported me during my diploma.
Special thanks have to go to Christian and Frank for their immense
help during the past half year.
At monday I will begin to work at the university. There I will be
able to continue my work on DOpE.
Preparing of the final presentation of my diploma
Everything I wanted to implement into DOpE for my final presentation
is done. We (Frank, Christian and me) tested everything on the laptop
that will be used for the presentation and it seem to run flawlessly
(hopefully, everything will go right during the presentation, too .-)
Fixed the flickering of the mouse cursor. During redraw operations the
mouse cursor must be hidden to not interfer with the drawing operation.
This caused a flickering when the mouse was over user interface elements,
that were currently updated. Thanks to double buffering I was able to
prevent the flickering completly, now. This fact makes DOpE far more
professional looking. I am astonished how such a small mouse cursor
affects the overall experience of a user interface. Hum.
The structure of my presentation and the half of the presentation slides
Real-time demonstration program
The real-time demonstration program to show DOpE's fascility to handle
real-time demands is nearly finished now. It shows four different
graphical effects that are computated in real-time (uhh... mixing
up the meanings of the term 'real-time' here). It proves that a
parallel running L4Linux does not influence the fluently output of
the real-time application. As a kiddy that I am I added some ways
to influence the graphical effects interactively by using the mouse.
Everyone, who wants to see this demo in action is invited to visit the final
presentation of my work (see news entry from 2002-10-26).
Improvements of DOpE
I improved several aspects of DOpE:
Additionally, I began to write a small demonstation program for the
real-time fascilities of DOpE.
- added synchronisation function to 'VScreen'-widget serverd. Using
this 'waitsync' function the computations of a client can be
easiely synced to the widgets update frequency.
- improved redraw duration prediction, which is now a part of
the Redraw Manager.
- changed the redraw-dropping algorithm. The new algorithm is a
bit simpler and requires only linear computations instead of
exponential ones. Its only drawback is that it does not avoid
overlapping redraw requests completely. But this fact is outruled
be the good limiting of the redraw queue length.
In contrast to the old algorithm the new strategy behaves
not only good in 'normal' (lots of free CPU time) situations but is
still stable during hard situations (with very low CPU time).
- implemented semaphores into the 'Thread'-module of DOpE.
Real-time functionality of DOpE
Implemented a slot-based real-time manager for DOpE. This real-time
manager is used by the 'VScreen'-widget to display its content
continously at a frame rate of 25Hz. This version of the real-time
manager is quite a bit limited. It is mainly intended to be used
for demonstration purposes for my final presentation of my diploma.
BTW.: The final presentation will be on the 8th of november at 2:50pm.
For further information take a look at the "EchtZeit AG" website:
First working version of VScreen widget
Who had thought that: the first version of the 'VScreen'-widget works.
It utilizes dm_phys to share the memory between the client and the 'VScreen'
widget. The mapping of the memory works well. The next steps will be
the implementation of its real-time fascilities, synchronisation and -
of course - some demos :-)
The written part of my diploma is online now. You can find it at the
files/DOpE/documentation section of this website:
You may also find it at the official section "Abgeschlossene Beleg- und
Diplomarbeiten" of the OS-department's website:
Thanks to Frank Mehnert for his help with improving the fonts for the pdf
version of the document.
Virtual screen widget
Began the implementation of a 'VScreen'-widget. This widget is meant
to be a real-time widget, which updates at a constant frame rate.
The virtual screen should be provided to a DOpE client via shared
memory. Currenty, I am exploring how to work with shared memory under
Article "Behind the scenes of the Atari Coldfire Project"
Just released an article about the past time of the Atari Coldfire
Project from my point of view. It features insights in our work and
a discussion of the 'Wilhelm' board, that was mentioned some time
ago at the acp website. Read the article at the ACP website or by
following this link:
Website for the Error In Line #3 convention
I created and launched the website for the Error In Line #3 convention,
which will be held at the easter weekend 2003 in Dresden.
The Error In Line #3 is a coding convention that is focused at
alternative computer systems and operating systems.
Maybe you will recognise some similarities between the EIL#3 website
and this one... :-) I just like my scripts too much.
Atari session with Nils
We (Nils and me) dedicated the last two days to our biggest hobby -
Firstly, I had to exchange my original Falcon by a new one, because
its scsi-bus does not work properly anymore. After some time of
installation and configuration my Falcon system works better than
ever. The coding of some new graphics routines for forthcoming
Atari productions was really recreating.
Additionally, we made some preparations for the Error In Line #3
coding convention, which will be held at the easter of 2003 in
ACP meeting in Rimbach
During the past weekend the Atari Coldfire Project team met at
Oliver Kotschi's place in Rimbach (in the near of Frankfurt/Main)
to dicuss the next steps of our Atari-clone project.
Sadly, Jörg Wilhelm - the chief of Wilhelm Electronics - did not manage
to attend to our meeting. Thus, he could not present his hardware solution.
Even so, we held long discussions via telephone about the details of his
hardware. Some important issues are still left. They will be debated
during the next days.
Another big topic at the meeting was the future of the operating system.
Finishing the textual part of my Diploma
My diploma document is finished. At usual the last days of writing the
text were a bit stressful. The final presentation of my work will be
Implemented a new 'Timer'-module, which provides an interface to
request the current system-on time in microsecond-resolution.
It is used to implement the periodical working realtime concept into DOpE.
For linux the SDL function 'SDL_GetTicks()' is used. It offers only a very
bad resolution (ms) but that does not matter because DOpE need not to be
realtime capable under Linux. .-)
Merged the 'eventloop'-modules of the Linux and L4 versions into
one sourcecode. Since now the 'Timer'-module is used there is no
platform dependence left in the eventloop module.
Switched to the new version of the 'Input'-library. Now a wider
variety of input devices should be usable under DOpE.
The biggest part of my diploma text is ready now. The final version will
probably contain some more figures and slight additions.
There are good news about the ACP project. We found a company, that will
help us with developing and producing a new Motorola Coldfire based
The 'Window'-widget is now splitted to two separate modules:
Windows now support a free definable set of window elements. So even
windows with no elements except their content are possible. Such a window
can be used as menubar etc.
- The 'WinLayout' module creates and maintaines window elements like
title, closer, border etc. Also the actions that are associated with
the window elements are defined here.
- The 'Window'-widget module itself takes care about window management
and utilised the 'WinLayout' module whenever a window is created or
Added the management of an 'active' window. This window is drawn in a
different style than the others. In the future the active window will
obtain the keyboard focus. Furthermore, menus could be displayed
dependent on the currently active window.
Added a pseudo-menubar. It displays the name of the application, that
owns the currently active window. - so it is no menu at all at the moment .-)
Implemented 'stay-on-top' functionality of DOpE-windows. Windows can be
forced to stay on top of the window stack by setting a 'staytop' flag.
Even multiple windows can be set up to stay on top. Their stacking
order is determined by the chronological order of their 'staytop' flag
setups. The 'stay-on-top' functionality is essential for realising
menus, taskbars or for showing sensitive security information. The
corresponding window has to stay always in front of the others to
ensure the integrity of the presented information.
The presentation program is ready. It can show multiple BMP-images.
The user can navigate through the images by using the left and
right arrow keys. There is also a shorcut for switching between
fullscreen and windowed mode easily.
Image viewer for DOpE
Today I started the work on a simple image viewer for DOpE.
This program will allow to use DOpE for presentations. For this, all
slides have to be converted to images. Currently, the viewer supports
only 24bit bmp images. The image data is provided
to the viewer via the 'grub' boot loader structures.
Holiday is over - back to work
After two weeks of vacation I am back to continue the
work on DOpE and my diploma. At the upcoming weekend,
the Atari-Convention "Unconventional" will take place.
Of course I will be there to celebrate my favorite
computer platform and code some effects.
The first version of my diploma text is now checked by a
native english speaking person. Big thanks to Leon O'Reilly
for his great support!
Letting the Falcon fly
The major work on the written part of my diploma is done.
After writing such a big text I need to do something different
for my recovery - time for a dose of mc68k and dsp56k assembly!
I have the feeling that my Falcon also enjoys these coding
It seems that the first real application (beside L4Linux) for
DOpE will be a video capturing program for USB-cameras. Gerd
Griessbach - the developer of the Drops USB drivers - showed his
interest in using DOpE for such an application.
L4Linux-stub sucessfully tested
The new L4Linux stub is now compatible with 'Dropscon'
and 'DOpE'. When switching between those programs no recompilation
of the Linux-kernel is needed anymore. Thanks to Adam for the
suggestion of this idea.
Enhanced my text parser I utilize to write my diploma. This Tcl-script
parses plain ascii-text and generates html or lyx (latex) files.
Different subscriptions (underline with '#', '=', '~', '-') of a
section title mark its level. Paragraphs with a beginning '*' are
interpreted as prompts. A line that beginns with a '#' indicates
sourcecode. Images are supported via a simple command syntax.
Depending on the destination format (html or lyx) gif-files are
converted to ps and vice versa. Now the parser also supports chapter
references. An example of the usage of the parser is the proposal you
can find in the 'files' section (DOpE/documents/) of this website.
Writing the text of my diploma
...just for everyone wondering about the few news updates:
I am currently busy with writing the diploma document, that covers
my past (and current) work on DOpE.
The practial work on the project will be continued when the
textual majority of that document is ready.
Preparing a weekend in Roitzschjora
After two years of abstinence I will attend to the famous
With Full Force
festival, again. After a weekend with "Motörhead", "Dead
Kennedys", "Slapshot", "Smoke Blow", "The Exploited" and
many other great bands, I will continue my work on my diploma
"with full force"... :-)
Merging the Dropscon- and DOpE-Linux-stubs
Adam told me that it would be nice to have one L4Linux
stub for handling both - the traditional L4Dropsconsole
and DOpE. So I merged both stubs and increased the
beauty of the code a bit (at least for my viewpoint).
The new stub is not tested with Dropscon, yet.
New DOpE screenshots
I added two new pictures to the 'Screenshots'-section. They
show how L4Linux runs inside a DOpE-window. Thanks to Frank
for his help with the screenshots!
Argument type checking of command interpreter
Until now, all command arguments were converted into
their possible representations (string->char*,
number->long, identifier->void*, etc.) without taking
care of the declared argument types. This leaded to
problems when specifying a number as string (for example).
Today I added an argument typechecking routine into
the 'Script'-module. So faulty commands can not harm
Porting DOpE back to Linux
After a long time of DOpE-development under L4 only, I
updated the Linux version of DOpE to the current state.
A lot of interfaces changed and had to be updated for
the Linux-version. As expected, the IDL stuff caused
problems again. Both used IDL compilers make strange
things (flick for L4 / Orbit for Linux) - sadly not the
same strage things :-/
After all - the current version works now under Linux
and L4 again.
New POV-Ray section
Just added a small POV-Ray section to this website.
It shows some some experiments I made, while I explored
this wonderful program.
XFree86 input driver module
I created a slightly modified version of the mousedriver
of XFree86. The original mouse driver module used the ps2
protocol data, provided by the kernel via /dev/input/mice.
The problem is that the kernel (that has the information
about the absolute mouse position) only provides relative
positioning information as ps2 protocol data. The Xserver
uses this relative motion information to determine an
absolute position (adding mouse accelleration etc). So the
mouse position of the X11-mouse was not the same as DOpEs
The modified version of the mouse module reads the real (DOpE)
mouseposition from the /proc/dropscon device and posts it
as absolute position into the XFree86 core.
X-Windows inside a DOpE window
Today I got the XFree86 X-Server to run inside a DOpE
The first step was the implementation of
a pseudo mouse device driver kernel module for
L4Linux. So the first aim was to get 'gpm' to
The second step was the adaption of the existing
pslim XFree86 driver module to work with DOpEs
The speed of the X-Server can be called 'pretty
usable'. Thanks to the redraw-dropping concept of
DOpE, not every temporary state of the X-Server
is made visible. When a lot of drawing operations
happen (for example, when typing 'ls -la /usr/bin'
inside a xterm), a lot of redraws are skipped to
present the final state as fast as possible.
Until now the adaption of the XFree86 driver module
is not perfect - it just works.
I hope to present you some screenshots next week.
Linux runs inside a DOpE window!
Finally, it happened! I got L4Linux to run under DOpE.
As far as now, only the text terminal is useable.
Linux behaves just like a normal DOpE client.
When booting Linux it gets registered at the DOpE-server
as client and creates a window and a pSLIM-widget.
All Linux output is done by sending pSLIM protocol
commands to this dedicated widget. Since 'press'-,
'release'- and 'motion'-events are bound to the pSLIM
widget, they are transmitted to an action-listener inside
Linux and are passed to the rest of the kernel, like any
normal input device driver does it.
Implemented a new
'puts_attr' function inside
the 'pLSIM'-module, which should be faster than the old one.
Thanks to Christian and Frank for their big help while
Trouble with Flick again
While implementing the console-Linux-kernelmodule I
discovered that flick-functions featuring refstrings
as parameters are not called properly.
Hopefully Christian or Frank know why...
Since Christian discovered the way to pass return strings
to an ipc-calling client by providing a receive buffer,
I built in this way of result-passing into the DOpE-server
and the DOpElib. This way of result-passing is also
essential for the console-linux-kernel-module, since
I can not rely on the priorities of my action listeners,
that were used for result-passing until now.
Made some changes on the directory structure of DOpE. The
IDL folder contains now subfolders for each interface
specification. The client- and server-stubs are now
generated inside the specific IDL-subfolder. There occured
very annoying problems with the standard Makeconf files,
provided in the L4 source tree, leading to unusable stub code.
Finally I decided to write the Makefile for the stub generation
an compilation by myself - this works good now.
Continued my work on L4Linux running under DOpE. Sadly my
work was discontinued by the IDL-compiler problems (see above).
Event handling, Terminal enhancements
Implemented the event handling at least to a level at which
it can descently used. At the moment there exist only a very
few events (motion, press, release, enter, leave). They can be
bound to any widget. If an event occures, the action listener
of the widget-owner is called. When binding an event to a widget,
a bindarg-string can be specified, which will be submitted to the
client everytime, when such an event occures. The current
implementation of the DOpElib uses the bindarg-string for storing
a callback adress and a callback argument for each binding.
Enhanced the functionality of the 'Terminal'-widget. The biggest
improvement are the back- and forground color capabilities. The
colors can be defined using standard escape-sequences. Additionally
I added the handling of backspace.
Implemented a 'Keymap'-module. This module holds the information
which key on the keyboard belongs to which character. It also
takes care about shift, control and alt-keys. So DOpE can
support different keyboard layouts, just by exchanging one module.
Introduced a key-state-table into the 'Input'-module. For each
key, the current state is stored and can easiely be requested. I added
corresponding functions to the DOpE server, too. So client applications
can request keystates and its ASCII-interpretations (using the
Updated the l4libtest-example to make use of the new features.
Now there exists a simple terminal application for interactive
communication with the DOpE-server under L4.
Discovering of L4linux
Began my work on the L4linux stubs to run Linux inside a DOpE
window. Sadly there were some strange problems when running
DOpE and Linux together. After struggeling around with PSLIM
for a while, I tried out to send the bootlog messages to a
'Terminal'-widget, which worked good.
Another strange thing was the behaviour of the mouse, when
L4linux was running. In the meanwhile I found out that both -
Linux and DOpE wanted to drive the mouse at the same time...
I will continue my work on the Linux-stub after the weekend.
Improvements of the PSLIM widget
Improved the 'PSLIM'-widget a bit:
Added a new function 'draw_widgetarea' to the 'RedrawManager'.
This function is able to draw only a inner part of a widget. (as used by the
- Wrote a new puts routine, which should be faster than the old one.
The original routine called the pslim_bmap routine for each character -
this means that the clipping and adress calculations were made for
each character separately. I implemented the new routine for 16bit
colordepth only - should be a childs play to create similar routines
for other colordepths later.
- After PSLIM operations, the changed area is now redrawed automatically.
This also works with scaled 'PSLIM'-widgets. I introduced a new
attribute for the 'PSLIM'-widgets, which defines its update mode.
Until now, only the EVERYTIME-update mode is supported, which means
that the widget calls a redraw after each PSLIM-operation.
Implemented some test routines in dopelib to make experiments
with the event handling. Slowly but surely - the event thingy evolves
to a nice concept. - however - I still need some time to clear up the
weirness in my head :-)
Began the work on the event handling routines. Firstly I changed
the 'Mouse'-module to a more general 'Input'-module. It should now
handle any kind of input sources.
Made some changes on the DOpE-internal event data structures.
There are now no special MOUSE_DOWN and MOUSE_UP events anymore. These
are now special cases of PRESS or RELEASE events. The keycodes for
the PRESS and RELEASE events are the same as used by the
linux-input-device definitions now.
The 'Messenger'-module can now send events to clients. The event
messages are not strings but event-unions which are very similar
to the event-unions used by libsdl. I thought long about using
strings for the communication to the action-listeners, but there
is no real advantage of using them. The event-protocol just need not
to be as flexible as the dope-command-protocol. So it would be
just an overhead to 'parse' event message strings. Additional information
can be passed to the client as a string. This can be used to
implement many kinds of client-side event handling concepts inside
dopelib (or maybe alternative libs). Such a string can contain a
callback function pointer, callback arguments or any other information.
The usage depends on the client lib.
Thanks to Koenraad Princen for his inspiration!
Finished the main work on the 'PSLIM'-widget. It features now
also the extensions for the 'puts' and 'puts_attr' functions
of the L4-console. The only thing left is the redraw functionality
Made some other experiments with returning strings with flick-based
IPC. The idea with the 'out parameter' does not seem to work - even
if it is used already in parts of L4. Sadly I couldnt find any
example, where these functions are used. So at the moment, result
strings are transfered by calling a dedicated function of the
clients action listener. However - this mechanism is hidden inside
the dopelib and can easiely exchanged later.
Client library for L4
Implemented the client-library, the 'Messenger'-module and the
action-listeners for L4. The communication problems with the
action-listeners under Linux do not occure under L4. Here
everything works fine :-)
Created a new 'Messenger'-Module. This module will be responsible
for the communication from the DOpE-server to the action-listeners
of the DOpE-clients. At the moment only a function 'send_result'
is available, that can be used to transfer 'exec_cmd'-result strings
to the client. Later, functions for error- and event-delivery will
be added. Sadly the communication to the action listeners doesnt
work 100% under linux (weird problems with orbit).
Began the implementation of a dopelib. The aim of this lib is to
make the client-programming a childs play. The system-specific
parts (mainly the communication flick/orbit) is hidden inside
the lib - so that clients should be very portable. At the moment
the library is only implemented for linux - and there are still
big problems with the action-listener communication.
Began my work on the PSLIM widget. PSLIM is a small set of graphics
routines that is used as a drawing protocol. I created a
'PSLIM'-protocol-widget which features the PSLIM core commands.
At the moment only 16bit color depth is supported. For every PSLIM-
widget a PSLIM-server is started, that handles the communication from
clients to the widget. The implementation of the 'PSLIMServer'-Module
for L4 is ready. Sadly the implementation for Linux leads to problems,
since the idl-description of the PSLIM-commands features a data type
(stringref), which is not known by Orbit.
While I coded the PSLIM-server I discovered that a server under L4
is not able to pass strings as return values. This works perfectly
with Orbit but crashes under L4 :-/ I need this for the function
'exec_cmd', which returns a string as result. So I have to think
about a work-around here.
This is the reason why I could not test the PSLIM widget so far.
I can create a PSLIM-widget and the PSLIM-server is started, but
there is no way to tell the client about the server-thread at the
Update of l4 'Thread' module
Implemented the mutex handling routines in the l4 specific
Changes in 'WindowManager', 'Script' and 'Server'
The 'WindowManager' uses now the 'RedrawManager' for its drawing
operations. This was the last place where direct drawing operations
were executed - which can cause problems with multiple threads.
Added semaphore functionality into the linux 'Thread'-module.
The 'RedrawManager' makes use of this functions to protect the
redraw queue. This is important because the 'RedrawManager' is
used by all threads who want to execute redraws.
The 'Server'-function 'exec_cmd' has now a string as return
value. This enables the client to get informed about command
errors or to receive return values from called DOpE-functions.
The 'Script'-module features now some error messages and
return values. Additionally, widget attributes can now be
easiely requested. A small example could be:
DOpE>b = new Button()
Improvements in 'Button'-module
The button text is now displayed centered. Additionally there exists now
a 'style' attribute for buttons. At the moment there are only two
different styles: window-element-style and normal-button-style. They look
not much different until now - there are just different text colors used.
The 'FontManager'-module features now two new functions for
calculating the width and height of a string with a given font-id.
Cleaned up the linux/eventloop code. Since the command interface exists now,
the built-in examples are pretty useless.
Began the work on the 'Terminal' widget. For this reason I introduced
string arguments, which can now also be used to set the text of a
button. The 'Terminal'-widget is very primitive and does only understand
plain ascii text, yet. The widget is able to support colored text and
background - but at the moment there is no way to use these features
via control sequences - I will build in these things next.
The 'Window' and 'Frame' modules have some new attributes:
'background' switches on the drawing of the background. Normally
this attribute does not need to be changed. Any window has a background
by default. Frames dont draw a background by default. This attribute
is useful, when a whole window is covered by another widget - in
this case the background is just overpainted by the other widget. So
we can switch its drawing off to save cpu time.
'fity': these flags specify if the
content of a window or frame should always fill the frame or window. The
content is rearranged everytime when the window/frame changes its size.
'yview': these attibutes represent the
scroll position of a windows or frames content.
Some redraw optimisations
Made some small optimisations of the redraw of several widgets.
DOpE 'Server'-module for L4
Implemented the DOpE client-server communication for L4. Now both
versions (L4 and Linux) have equal functionality.
For the testing of the L4 'Server'-module I implemented a small
test client. The first tests (register application and execute
Since I use different IDL-compilers for L4 (flick) and Linux (orbit)
the clients are platform dependent. This will change when a library
is available. It will provide a common interface to access the
Porting of the current DOpE version to L4
The current version of DOpE including the new redraw concept
runs now also under L4. There occured some annoying bugs, because
L4 doesnt seem to clear newly allocated memory areas. So I can
not assume that uninitialised variables are set to zero. The
client-server communication is not ported yet.
Installation of L4 development environment
Installed a L4 development environment including a DHCP-server and
TFTP-server on the development computer. The test computer uses the
grub bootloader to boot from the network - just as the test computers
at the institute do. This enables me to do also the L4 related work
at home :)
DOpE is running happily on the test system. The next step will be
the porting of the DOpE client-server communication to L4.
Optimisations inside the 'RedrawManager' and other modules
The DOpE command interpreter allows a very intensive testing of the
whole program. So I improved different parts of DOpE:
I made some changes on the script interpreter with the aim to make
the DOpE-command-code smaller. The example code from the 29th of april could
now look like this:
- layout management: I implemented the direction child->parent of
the Layout concept for the Frame widget, which is now able to react
on changes of its childs properties. If the content of a Frame
changes its size, the scrollbars of the Frame are updated correctly.
- widget base class: shrinked the number of needed redraws caused by
the mouse focus. It is now the widgets responsibility to take care
about what to do when the focus changes.
- redraw manager: redraw dropping is now done widget specific. This
optimisation can increase the performance in critical situations a lot.
- The testclient shell can now execute 'scripts' - just to make testing
a bit easier for me.
w = new Window()
g = new Grid()
b = new Button()
g.place(b,-column 1 -row 1)
w.set(-x 50 -y 30 -w 300 -h 200 -content g)
Additionally the 'Window' has the same '-scrollx' and
'-scrolly' attributes as the 'Frame'. So the simple instruction:
would add full scrollbar functionality to the window.
w.set(-scrollx yes -scrolly yes)
Cleaned up some code and Makefiles for Linux. The DOpE-server internal
include-folder is now placed in the dope-src directory because
it is not intended to use these headerfiles outside of the dope server.
The outer include directory will contain the headerfiles for the dope service
Improved the command interpreter to be more tolerant when commands
contain syntax errors.
DOpE command language (again)
Continued the work on the command interpreter. All methods for
the dynamic generation of the command language are ready. Widgets
can register methods with a variable number and different types of
arguments. Even optional paramers are possible.
Multiply widget attributes can be set with only one command.
an example for the script usage could be:
w = new Window()
f = w.get_frame()
g = new Grid()
b = new Button()
g.place(b,-column 1 -row 1)
w.set(-x 50 -y 30 -width 300 -height 200)
For easy testing I implemented a small interactive shell as client, where
I can type in the DOpE commands directly. Also multiple clients are no
problem. Each client has an independent variable-name space.
DOpE command language
Started the implementation of the DOpE command langage. The central
component for this functionality is the 'Script'-module. Widgets
can register methods and attributes dynamically. The command language
is very simple. It consists only of two primitives:
The first tests were successful. A client is now able to create and open a window -
but nothing more at the moment. Method calls have no parameters, yet.
- assignments: widgets can be created and assigned to a variable symbol
a = new Window()
- method calls - to call methods of widgets
Implementation of DOpE server module under Linux
Clients can now talk to a DOpE server under linux. I implemented a new
'Server'-module based on Orbit generated stubs. The server
runs as dedicated thread that is started right before DOpE
enters the main event loop.
At the moment the server only knows three commands:
long init_app(char *appname): registration of a new client application, a
client application id is returned.
void deinit_app(long appid): unregisters client application with the
specified application id
long exec_cmd(long appid,char *cmd): executes a DOpE command (the command
interpreter has to come next)
IDL-problem under Linux solved
The IDL-compiler problem under Linux is solved now. I will not use
'Flick' as IDL-compiler under Linux but 'Orbit'. This has two advantages in
comparison with flick under Linux:
A lot of thanks to Robert Wetzel (aka Spex) for his help!
- it doesnt produces a main() method - so it fits perfectly in the modular
concept of DOpE. (The communicating server is just started as a normal
- it works without problems - I still have no clue how to get the corba
example of flick running.
The best thing about it is that I can use the same interface description
file for L4 and Linux.
'Application Manager', 'Script', 'Thread' and 'Tokenizer'-modules
I created several new DOpE-modules. They are:
- 'ApplicationManager': this is a central component, which handles
the internal DOpE ressources for multiple applications. Each
application has its own widget and variable set. So widget- or
or variable names may not cause conflicts between applications.
- 'Thread': this is an abstraction of thread creation and handling.
Until now, this module is implemented for Linux only. At the moment
it features only a method to create threads.
- 'Script': Component for interpreting script commands coming from
applications. The command language will be built dynamically by the
other modules (mostly widget-modules). There exists functions to register
new widget-types, widget-attributes and widget-methods - but they are
not fully functional, yet.
- 'Tokenizer': This module will be used by the 'Script' module for parsing
commands, method-descriptions and attribute-descriptions. It features
basically one function, which creates a list of tokens out of a given
Escape Coding Week Gallery
The pictures of the Escape coding week are available now.
Check out the new 'Mixed/Easter2002' section of this website.
Exploring IDL and Flick
...a lot of new things to learn. I have to use Corba-IDL syntax
for the interface description of DOpE under L4. The IDL compiler 'Flick',
which is used for L4, can handle multiple input formats, protocols
and languages. I wanted to generate suntcp client- and server-stubs
based on a Corba-like IDL description for the development under
Linux. Until now I dont have found out how to do it. So I will skip
it and use rpcgen under Linux instead.
Hash-table and more
Created new module 'HashTable'. This is needed for the script
module later. The size of the hash-table and the maximum amount of
hash-characters can be specified freely when the hash-table
Debugged the 'RedrawManager'. The redraw-split was not perfectly
be done before. Firstly I implemented a debugging screen where
each updated area is visible as a additive shade. So I could
easily see if there are redundant redraws. Additionally I fixed
a small bug in the 'Container'-module - this was not really a bug,
but sometimes just a bigger area than really needed was redrawn.
Added a function 'get_noque' function to the 'Redraw-Manager'
to request the number of current redraw-queue elements. This
information is now used by the 'UserState'-module to decide
if mouse movements should be delayed. This adaptivity improves
the apperiance of moving windows with a very low pixel-update-rate
First implementation of the 'redraw-dropping'-idea
Today I implemented the 'redraw-dropping'-algorithm into the
'Redraw-Manager' of DoPE. The aim of this algorithm is to
minimize the number of drawed pixels when redraws of an area are
requested before the previous redraw of the same area is finished.
This makes the life with the non-realtime-widgets much easier.
The most important thing about the non-realtime-widgets is that
their appeariance on screen is up-to-date - there is no framerate
or other constraints we have to take care about. The design of
the 'Redraw-Manager' makes it possible to minimize the amount of
pixels to draw and makes sure that the area is up-to-date.
The routine has still some redrawing errors. Beside that it runs
good - even under very complicate constraints such as:
In this situation the moving the window doesnt looks smooth
(that is logical because the window is 9 times bigger than
the area that can be updated in one period) but the final result
(when stopping the mouse movement) represents the current
state of the user interface.
- a object of 50x50 pixel is moving all the time and produces
- it is only allowed to draw 100x100 pixels per period
- user activity, such as moving a 300x300-window
The 'Escape' coding week is over now. So what did we do?
All in all it was a productive and funny week. Temporary guests
were Jens Klietz, Defjam, 505, Shenja and Spion. We hope that we can
arrange something like that again.
- Spex made his first steps in DSP programming. He made a weird
sine plasma - which looks a bit like green soup in one bitplane.
At the moment it runs not at the desired framerate, but that
will hopefully change soon (Spex promised it).
- Charon converted parts of his 3D-engine to the DSP. So the DSP
makes all 3D calculations, projection and polygon sorting. The
drawing itself is still done by the CPU. At the moment the engine
features gouroud-z-shaded polygons at a descent framerate.
- I made two effects. The first one is a whirling plasma particle
effect with zoomed blobs - to say it in one word: "fireflysubbe".
The other one is a 2-plane 3D-engine featuring clipping. The whole
screen is stored at the DSP-memory and the DSP can work independently.
So even big polygons can be displayed at a high framerate.
Added some of my drawings at this website. Take a look at the new
Escape coding week
The Escape-demogroup meeting at my place just started today.
We (Charon, Spex and me) will try to torment the DSPs of our
Falcons a bit.
The work on DoPE will be continued in one week.
german version of 'Atari Coldfire Project' website
Today I created the german version of the 'Atari Coldfire Project'
I added a guestbook to this website. So if you want to leave me a
message but writing a mail is too much work for you - take a look into
The 'Redraw Manager' is a central point of the realtime concept of
DoPE. It is the key of solving the problem of user interactivity.
Until now widgets could force redraws immediately when they were
needed. The problem is that these redraws are highly dependent on
the users actions. When the user moves a big window a time consuming
redraw is needed to make the movement visible. A redraw operation
must be finished before any other redraw can be done (for example
the redraw of a playing animation or another realtime widget).
Now the widgets have to call a function of the 'Redraw Manager'
when they want to redraw itselfs - not the 'Window Manager' directly.
From the side of the widgets there is nothing to care about. The only
difference is that the 'Redraw Manager' dont executes the redraws
immediately but puts the 'redraw actions' into a queue.
When all realtime activity is done, the queued 'redraw actions' can
be executed in the left time of the current period. The execution time
of the redraws can be controlled by specifying the maximum
amount of pixels to be drawn. If a 'redraw action' is too big (that
means that the redraw area size is bigger than the specified maximum
amount of pixels) it is subdivided into smaller 'redraw actions'.
So the left part of the 'redraw action' can be executed in the
Of course all modules that called redraws via the 'Window Manager'
had to be changed to make use of the 'Redraw Manager'.
It is now 6am and I got the 'Grid'-widget to work. The handling of
the row, column and cell lists works now - even with the column/row-span
The whole 'Grid'-widget is far from being complete - but it works
already. I have a lot of ideas to optimize is - especially for cases
with a lot of child-widgets.
Optimized the redraw-concept: Until now each widget had a function called
'update' which enabled the widget to update its properties when its
attributes changed. Depending of the kind of attribute-change a redraw
of the widget is needed. Often this function is called from parent
widgets 'update'-functions, which could also force a redraw of itself
including their children. The result was that the children were redrawed
more times then needed - at least in some cases.
To solve this problem I introduced a new parameter of the 'update'-
function, a flag that explicitely can forbid redraws. So a parent
can update all its children and force them not to make their
changes visible. After all children are updated the parent draws
itself one time - including the children.
Thanks to Napalm Death for their album "Enemy of the music business" and
the repeat-function of my CD-player which kept me awake while I did this
boring stuff. ... need some coffee now...
You can take a look in the screenshots section to get an idea how
it all looks like.
Extracted the scrollbar functionality from the 'Container'-widget
and put it into a new 'Frame'-widget. The 'Container' is now a
pure layout-widget. As a consequence, the workarea widget of a
'Window' is now always a 'Frame'. A 'Frame' can only have one widget as
content - so normally this widget will be layout widget - such as
a 'Container' or 'Grid'.
official start of the 'Atari Coldfire Project' website
The website I made last weekend is now officially available.
It will cover everything about the 'Atari Coldfire Project'
- a project with the aim to create a new Atari-clone.
You will notice a little similarity to this site - I couldnt
resist to use some of my scripts again, hehe... :-)
BTW: all graphical elements of the new website are made using
Escape Paint - a graphics program I programmed for the Atari Falcon.
Began the work on a 'Grid'-layout widget. It seems that
this is the most complex widget so far. Using this widget
other widgets can be organized in rows and columns. A
child widget can also occupy more than one rows/columns.
This will make the 'Grid'-widget a very powerful tool,
to create dialogs. There exist two different modes for
A widget can be aligned inside a grid cell (or even more than
one) using the attribute 'sticky' (as seen in Tcl/Tk :-).
This is a string containing the letters 'n' (north), 's' (south),
'e' (east), 'w'(west), 'c'(center). For example: if the string
is "ew" the childwidget will occupy the whole cellspace horizontally.
- FIXED: A concrete pixel value can be specified to define
a rows/columns size directly
- WEIGHTED: A floating point number 'weight' can be
specified. This number defines the layout of the not-FIXED
rows/columns and allows grid-size independent row/column
Additionally vertical and horizontal 'padding'-values can
be specified per cell. These values define the minimum distance
from the child widget to the cell border.
Until now the 'grid'-widget is not working... need some time
to finish it.
Double-buffering under L4 and a lot more
The L4-screen module of the L4-part of DOpE features now
double buffering functionality. Also small changes in
'Basegfx' and 'Image16Data' were needed to make use of
Made 'Scrollbar'-widget fully functional. There are three
ways to use it:
Introduced two new 'userstates':
- clicking on the up/down or top/bottom arrows scrolls the
- clicking on the slider background let jump the slider
one 'page' for/backward
- clicking on the slider for direct manipulation of the
Enhanced the 'Container'-widget to make use of scrollbars.
- SCROLLDRAG: this is the state while the user drags a
- SCROLLSTEP: this is the state while the user presses a
Began the work on the 'Scrollbar'-module, which itself is
needed to implement the full layout concept of DoPE. Until
now only the basic creating and drawing-functions are done.
Enhanced the data structures of the 'widget base class' to
implement the layout concept. There is a new general widget
function called 'do_layout'. The layout concept is based
on two rules:
The 'do_layout' function represents the second rule. Layout
changes are always propagated from the children to its
- Parents take care about their children (parents know the
properties of its children (min/max size, position) and
use this information to place them inside the parent widget.
- Children propagate their wished to their parent (if the
properties of a child changes in a way that makes a new
layout nessesary the child can tell their parent to reorder
New website for the Atari Coldfire project made
The new website for the Atari Coldfire Project is ready. The
url will be officially published when all involved people give
Just added a new 'Links'-section. It contains some interesting
links about Atari, programming and alternative platforms.
Enhancements of the 'Image' modules
Last weekend there was a meeting of the "Atari Coldfire Project"
in Dresden. Since I was very busy with organizing the meeting and
slept only a few hours during the weekend I was just too tired to
do anything useful the recent days. Now I seem to be recovered and
the work on DOpE can continue :-)
The modules for handling 8bit and 16bit images have a new
function 'paint_scaled', that paints an image with a
specified size. The functions work well with clipping. They
are fast enough to be used as button backgrounds as seen
in the new screenshot.
'Cache' and 'Image' modules
Began to write new modules to handle 8bit indexed and
16bit hicolor images. For fast redraws of images that doesnt
have the same pixel format as the screen, converted versions
of the images must be cached. This is the reason, why I
implemented the cache module. To summarize the new modules:
Christian found the bug in his input device library. Now the
mouse seems to work well under l4!
- 'Cache'-module...can be used to handle any kind of cached
data. This module could be used to implement image- or font-
caches in a very easy way. The maximum cache size can be
configured. The cache itself works like a ring-buffer with
a configurable size. When the cache grows too big, the
oldest element gets lost.
- 'Image8iData'-module: This module should make the usage of
8bit indexed images a childs play. There a functions to create,
destroy and draw (cached!) this kind of images. Until now
only 16bit screen color depth is supported.
- 'Image16Data'-module: When this module will be ready, it
could be used in a similar way as the 'Image8iData' module, but
for 16bit hicolor images. At the moment only the very basic
functions 'create' and 'destroy' are implemented because they
are needed by 'Image8iData'.
Mouse under L4
Modified the 'mouse'-module to support Christians new input device library.
The result is that windows can be moved and resized using the mouse...
at least for a couple of seconds (there is still a bug in the lib,
which causes DOpE to crash after some mouse movements).
At the moment I am busy with thinking about the design of
the layout- and realtime-concept of DOpE.
L4 gets DOpEd
Today is the first day of DOpE's life on L4. Thanks to Christian
for his great help! At the moment only the graphical output is
working. The mouse is not usable, yet - this will follow next
Fixed the clipping problem of the string drawing routine.
Font loading and drawing routines
DOpE can now make use of 'FNT' bitmap fonts. These fonts are
a lot smaller than 'PCF's. I included three fix fonts into the
program, which should be used to build widgets with. These fonts
are 'mono' (a monospaced font for terminals or text editors),
'default' (for normal text on dialogs) and 'title' (for window
titles etc.). Of course more fonts could be included easily, but
I want to limit the freedom of the widgets a bit.
The font loader is easy expandable by new formats. (Maybe using
freetype2 later?) The new modules are:
The first version of the string drawing routine is ready, too.
It takes care of the clipping area but has still some weird
problems with it. The string drawing routine is now a part of
the 'BaseGFX' module.
- 'FontManager' - this is the module to use if another module
wants to use fonts. At the moment the only service function
of this module is to provide font data by an id.
- 'ConvertFNT' - this module converts 'FNT' font data into a
'standard'-format. It is only used by the 'Fontmanager' at
Window-widgets are now resizeable by dragging the surrounding border.
Events can be propagated from widgets to other widgets (mostly its
parent). This makes it possible to move a window by clicking on any
widget inside a window which dont have own event handlers. (The window
is just the parent of every widget inside it and receives all events
that are not handled by its children.)
Added a software mousecursor to the screen module. It is important
to take care about hiding and showing the software cursor when drawing
widgets. When drawing, the current work area must be told to the
screen module. If the mouse is inside this work area it gets hidden.
This technique shrinks the annoying flickering of the mousecursor to
Implemented event-handling routines. Until now only mouse
events are handled. The 'handle_event' methods of the widgets
can receive events of the types 'MOUSE_MOTION', 'MOUSE_ENTER',
'MOUSE_LEAVE', 'MOUSE_UP' and 'MOUSE_DOWN' and react
individually. Button- and background-widgets have now a new attribute 'click',
which is a pointer to a click routine. This routine is executed
when such a widget receives a 'MOUSE_DOWN'-event.
Added new module:
Implemented full window-move and -top functionality.
- 'UserState' - This module handles the event delivering
for the different GUI-states which are 'IDLE' (user does nothing),
'WINMOVE' (user is moving a window), 'DELAY' (user clicked
a widget but the widget waits until the button is released). This concept
makes it possible that the GUI is not blocked, even if the user
is moving windows etc.
Wanna see, how it looks like? - check out the 'Screenshots' section :-)
Widget move functions
Implemented a function to move widgets (at the moment this
is only important for windows). This general function is
now part of the window manager because this is the only
place with the information about the window configuration.
Currenty, the move function causes just a redraw of the
'dirty' area. It should be exchanged by a more intelligent
move function later (based on copying).
The window widget has now own access functions for its
position attributes. This allows the buffering of the old
values. When the update function is called, the window
checks if its position changed and calls the move function
of the window manager.
Added 'handle_event'-method to widget base class. By default
events are propagated to the parent. Details about the
event structure are not decided, yet.
Reference-counters and much more
Introduced reference counters to the widget 'base'-class. There
are two methods 'inc_ref' and 'dec_ref' to handle them. If
a reference counter gets zero, the widget is destroyed.
Implemented object-find functionality - which makes it possible
to find a widget at given screen coordinates (this sounds easier
than it is :-)
I enhanced the widget base-class a lot. It has now the following
- destroy - destroys a widget (since we have reference counters,
this function should be useless - so I will remove it later)
- force_redraw - calculates the area, where a widget is
visible on the screen and causes a redraw of this area
- draw - draws an object
- find - finds a child-widget at a giveb relative position
- update - checks, if the widget was 'touched', recalculate and redraw
- inc_ref and dec_ref - to handle reference counters
The container widget can now hold more than one widgets.
The order of putting them into a container defines the order of drawing
- the last added widget will appear in front. In the future I will (maybe)
add functions to reorganize widgets in a container. In general you can
already build dialog boxes using this widget.
- relative position to its parent
- current size
- maximal size (not used yet)
- minimal size (not used yet)
- state (selected or not)
- focus (mouse over widget or not)
- parent in widget hierarchy
- context (associated data - can be defined by the 'user')
- next and previous (to build connected lists out of widgets)
- update-bitmask (to determine what kind of update is
needed when the update-method is called
Creating windows and let them draw itself is fine but has
limited sense - so its time to organize them a bit using a...
Found a problem of a 'basegfx' routine which didnt took the
clipping area too serious - fixed this.
- 'WindowManager'-module. This
module handles a connected list of its windows. 'Window'-widgets
can be added or removed from this list. The order of the list
elements defines the order they appear on the screen (first
list element is the top-window). The 'WindowManager' handles the
correct drawing of the widgets by taking care about the intersections
between them. The 'WindowManager' is the only one, who know how
the single windows relate to each other. So if anyone wants to
redraw things on the screen the 'WindowManager' must be asked to
Extended the attributes of the widget-'class'. Every widget has
now a 'next' and 'prev' value, that can be used to build
connected lists with them. This is interesting for widgets
which handle multiple children-widgets (layout widgets etc).
Also the 'WindowManager' makes use of this new feature.
'Container', 'Background' and 'Window' widgets
Started the code for some basic widgets - mainly for testing
the handling of widget structures. The widgets can already draw
itselfs using the 'basegfx' module. For correct drawing the
clipping functions of the 'screen' module were extracted and I
put them into a separate 'clipping' module. Additionally I
implemented a clipping-stack for the new module. So what are
those new modules?
- 'Clipping'-module (handles a clipping-stack - that means that
the clipping area can be shrinked by pushing new areas on a
stack. The resulting clipping area is the intersection of
the current and new area. This technique allows easily to
implement 'widgets in widgets' etc.)
- 'Background'-widget (represents a background of a window or
desktop - which is a special kind of window)
- 'Container'-widget (a widget, that can contain any other widget
- also widgets that are bigger then itself. You can specify
a scroll offset for its content)
- 'Window'-widget (contains all nessesary window elements such
as resize-border, closer, title und fuller. All those elements
are plain buttons. In the middle of the window (its content) a
container is placed, that can hold any other widget type)
First graphics routines for DOpE
Some basic graphic routines for drawing buttons and frames
are ready. Until now they are restricted to 16bit color depths
but the structure of the program is open for other ones.
Additionally some infrastructure for widget handling is done.
The new components are:
- 'Basegfx'-module (some basic graphical primitives like frames
and boxes that take care about the clipping area) The modules offers
low level graphics routines but not a low level interface. The
programmer cannot specify direct color values but the information
about the 'kind of' box (background, activator, selector) or frame
(raised, sunken, groove, ridge).
- 'WidgetManager'-module (provides default functions and values
for widgets - contains something like a base-class of all widget types)
- 'Button'-widget (just for test purpose until now)
This website will cover everything about my work. At the
moment only the sections 'news', 'contact' and 'files' are
ready. Stay patient :-)
Basic structure of DOpE written
Today the first work for DOpE was done. The first goal
is a minimalistic windowing system for Linux. Every
system specific stuff is encapsulated in separate modules.
I use SDL for handling the access to the screen and
input devices. These modules must be replaced later by
L4 specific ones. So what do we have now?
- a small main program featuring a component handler 'pool' (
modules can register services, that can be used by
others), initialisation code and a minimalistic
- 'Memory'-module (maps allocation and deallocation
functions to stdlib calls - so its system dependend)
- 'Screen'-module (represents a screen including double
buffering and handles the drawing of the mouse cursor.
This modules uses SDL - so it is system dependend.)
- 'Mouse'-module (handles the state of the mouse. At
the moment it uses SDL - should be replaced by a L4-