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.

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 October.

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 FX Announcement:

http://www.genode-labs.com/news/genode-fpga-graphics-project-launched

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:

Subscribe to the Genode Labs newsletter:

http://www.genode-labs.com/newsletter

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.

Genode.org download section:

http://genode.org/download/latest-release

More detailed release notes and the source code are available from the download section of genode.org.

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.

Genode.org website:

http://genode.org

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 stay...

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.

Docutils website:

http://docutils.sourceforge.net/

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.

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.

Genode Labs website:

http://www.genode-labs.com

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.

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.

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.

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!

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 again.

I just took one week off my regular job at the university to spend my time with Matthias Alles and do some FPGA development.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Paper on dynamic RPC marshalling:

http://os.inf.tu-dresden.de/papers_ps/feske07-dynrpc.pdf

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!

I ported Bastei to the ARM Integrator Platform. The porting work went pretty smoothly. The few tricky things had been:

• 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 support.
• 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 is signaled. 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 the SRAM.

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.

2007-03-11 04:20

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.

2007-03-12 01:50

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 lines.

2007-03-13 06:21

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.

2007-03-13 19:48

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!

2007-03-14 22:02

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.

2007-03-15 07:46

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.

2007-03-16 09:05

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 fixed quicky.

2007-03-17

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 understatement!

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.

GOSH release page:

files/GOSH

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:

Publications website of the TU Dresden OS group:

http://os.inf.tu-dresden.de/drops/doc.html#bastei_design

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 the system.

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)

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.

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.

Projects overview:

projects/projects.html

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.

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.

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.

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.

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.

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.

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.

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.

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.

Today, I released the TUD:OS Live-Demo CD.

Demo-CD Website:

http://demo.tudos.org

As requested by several friends, I picked some photos of my son Kevin and put them at a dedicated page:

Photos of Kevin:

kevin/kevin.html

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 stressful time.

Today, Christin gave birth to our son Kevin. We curiously look forward to our life as a family.

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!

Charon's FPGA Project:

http://www-user.rhrk.uni-kl.de/~alles/fpga/

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.

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.

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.

A Nitpicker's Guide to a minimal-complexity secure GUI:

http://os.inf.tu-dresden.de/papers_ps/feske-nitpicker.pdf

I finished my work on the first functional version of my tutorial browser and ported it to Nitpicker, DOpE, and the L4 Console.

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.

Charon's FPGA Project:

http://www-user.rhrk.uni-kl.de/~alles/fpga/

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.

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 drop shadows.

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.

I just returned to good old Germany and there are thousands of things to do now. Lets see...

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.

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 the program.

Charon's FPGA board:

http://www-user.rhrk.uni-kl.de/~alles/fpga/

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.

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.

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.

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:

Atari Coldfire Project:

http://acp.atari.org

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.

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.

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 as asterisks.

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.

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 of DOpE.

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.

Blender Gallery:

blender/blender.html

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 flawlessly.

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.

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.

Blender Gallery:

blender/blender.html

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.

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.

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.

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.

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.

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.

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.

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 VDI/AES implementation.

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.

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.

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 widget.

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.

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.

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++ function invokations.
• Optional method attributes, specified as tag - value pairs, can now be arbitrary ordered.

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 assurance.

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.

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 Latex-code, HTML or Man-pages. This way you can create a PDF of your text document or create a fancy Website.

Download GOSH:

files/GOSH/

Documentation of GOSH:

gosh/gosh.html

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.

TUD:OS 2004:

http://os.inf.tu-dresden.de/tudos/

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 kernel code.

An updated version of my article "My life with the Coldfire Evaluation Board" is available at the website of the Atari Coldfire Project:

Atari Coldfire Project:

http://acp.atari.org

I added sections about my work with porting the MiNT kernel to the Coldfire and about how to download my Coldfire-related source codes.

I made all my Coldfire related source codes publicly available via a Subversion repository:

My Subversion Repository:

http://os.inf.tu-dresden.de/~nf2/svn

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.

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.

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!

I added some new features to GOSH, my text parsing tool, to make it applicable for even a wider range of textual documents:

• 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 colon.

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 virtualisation interface.

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!

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.

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 help here.

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.

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.

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.

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.

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 keyrepeat binding and thus, can react to key repeat events. I also implemented support for this new feature into DOpElib, libterm and the Entry widget.

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.

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.

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 implementation.

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 by hand!

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.

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.

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.

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.

Overlay Window Management (pdf):

files/DOpE/documents/TUD-FI04-02-april2004.pdf

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.

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.

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 of Widgets.

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.

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 :-)

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.

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.

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).

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 section-depth levels.

I wrote an article (pdf, html) 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.

Website of the Atari Coldfire Project:

http://acp.atari.org

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.

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.

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.

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.

Screenshots of DOpE:

dopescreens.html

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.

POV-Ray section:

povray/povray.html

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!

Hatari Website:

http://hatari.sourceforge.net

MiniTop displays now the right timing values when running on L4/Fiasco. Quite interesting to see the programs eating CPU time.

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.

DOpE screenshots:

dopescreens.html

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() a.set(-content b) a.open() b.set(-from -100 -to 100) b.barconfig(load, -value 45) b.barconfig(idle, -value -33.3)

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 supporting DOpE!

DOpE client applications:

http://os.inf.tu-dresden.de/dope/clients.xml#verner

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 user mode.

MicroAPL website:

http://www.microapl.co.uk

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:

• 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 by 'make'.
• 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.

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!

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 workx, worky, workw and workh. These attributes allow the implementation of applications with fullscreen or similar functions without any assumptions about the border size of DOpE windows.

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.

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!

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 much simpler.

I put some photos of my trip to Cancun/Mexico online:

Photos of Cancun/Mexico:

mexico2003/mexico2003.html

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.

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 the future.

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:

Demonstration of DOpE (ext. abstract):

files/DOpE/documents/DOpE-RTSS03.pdf

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 completely, yet.

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!

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 applications.

Website of the DOpE project:

http://os.inf.tu-dresden.de/dope

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.

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.

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:

char req_buf[16]; 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);

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:

configfile (nd)/tftpboot/nf2/demo.lst

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:

Photos of New Zealand:

nz/index.html

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.

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 as follows:

gosh --style html.gosh sometext.txt > sometext.html

Until now tables and images are not supported, yet - I will implement these features as soon as I (or someone else) need them.

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:

Documents about DOpE:

files/DOpE/documents

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.

The interface of the DOpE client library had be be changed to suit the needs of multithreaded applications:

• 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.

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 valuable help! In december, I will have the chance to present DOpE in action at the conference.

RTSS 2003 website:

http://rtss2003.ece.cmu.edu/

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.

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.

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).

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.

The L4Linux console stub has two tasks:

• It displays the boot output and login console on a pSLIM widget
• 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.

Today I got FLIPS to threat a HTTP request from Mozilla via a real network device driver!

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.

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:

• 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)

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.

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).

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.

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.

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 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 objcopy.

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.

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.

Thanks to Jork, the DOpE presenter is now capable of loading files via an L4 file provider, such as tftp and ext2.

I introduced some new event bindings into DOpE. The Button widget provides now:

• "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.

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.

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).

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.

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.

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)

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.

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.

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 excellent!

Stoned from the Underground website:

http://www.caligula666.de

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 example:

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.

Scale widgets provide now a binding of "change"-events that enables client applications to trigger function calls to the changes of a Scale value.

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.

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!

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.

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.

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 digits.

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).

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 in action.

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.

DOpE's widgets can now use floats as attributes. For this, parts of the command interpreter had to be changed.

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 a colossus!

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.

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.

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 .-)

After hours of fumbling, I managed to get the XFree-bitch to display something like a X-desktop on a VScreen widget.

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 :)

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).

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.

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 competitions :-)

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.

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.

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 handler.

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.

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.

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.

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.

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 this.

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.

The DOpE version of the Run program makes now use of the command line history functionality of libterm.

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 :-)

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.

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.

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.

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.

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!

Damn! The harddisk of my SGI Indigo2 just crashed! Maybe that is the revenge for not turning on this baby for so long... sniff.

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!

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.

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 work:

• term_printf with the same semantics as printf
• term_getchar with the same semantics as getchar

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 unique support!

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.

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:

• updating the Linux-stub of DOpE, because Jacob asked for DOpE and he needs the Linux-stub
• restructuring DOpElib to simplify the platform dependent parts of the lib

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).

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:

Mikrosina website:

http://os.inf.tu-dresden.de/mikrosina/

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.

It is time again to explore the inner depths of the Linux kernel and its IP-stack.

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.

download Chosneck #3:

http://files.dhs.nu/files_magazines/chos_3rd.zip

Added some nice features to the VScreen widget:

• 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 update.
• 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.

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.

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.

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 big help.

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.

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!

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 interface approach.

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:

DOpE documentation in the Files section:

files/DOpE/documents/index.html

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.

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.

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.

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 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 Group.

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.

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 and information.

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.

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 are ready.

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).

I improved several aspects 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.

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:

EchtZeit AG:

http://os.inf.tu-dresden.de/EZAG/

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:

file section of this website:

files/DOpE/documents/index.html

You may also find it at the official section "Abgeschlossene Beleg- und Diplomarbeiten" of the OS-department's website:

Abgeschlossene Beleg- und Diplomarbeiten:

http://os.inf.tu-dresden.de/project/finished/finished.xml

Thanks to Frank Mehnert for his help with improving the fonts for the pdf version of the document.

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 DROPS.

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:

Behind the scenes of the Atari Coldfire Project:

http://acp.atari.org/articles/bts/bts_acp.html

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.

Error In Line #3 website:

http://eil.atari.org

We (Nils and me) dedicated the last two days to our biggest hobby - atari-demos.

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 Dresden.

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.

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 in november.

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 motherboard.

Atari Coldfire Project:

http://acp.atari.org

The 'Window'-widget is now splitted to two separate modules:

• 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 resized.

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.

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.

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.

Unconventional website:

http://unconventional.atari.org

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!

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 sessions...

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.

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.

...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.

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"... :-)

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.

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!

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 DOpE anymore.

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.

Just added a small POV-Ray section to this website. It shows some some experiments I made, while I explored this wonderful program.

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 mouse position.

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.

Today I got the XFree86 X-Server to run inside a DOpE window.

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 work.

The second step was the adaption of the existing pslim XFree86 driver module to work with DOpEs pSLIM interface.

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.

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 hunting bugs.

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).

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 'Keymap'-module).

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.

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.

Improved the 'PSLIM'-widget a bit:

• 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.

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 moment.

Implemented the mutex handling routines in the l4 specific 'Thread'-module.

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() ok DOpE>b.set(-text "Hallo") ok DOpE>b.text Hallo

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.
• 'fitx' and '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.
• 'xview' and 'yview': these attibutes represent the scroll position of a windows or frames content.

Made some small optimisations of the redraw of several widgets.

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 DOpE-commands) succeeded.

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 DOpE-server later.

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.

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.

The DOpE command interpreter allows a very intensive testing of the whole program. So I improved different parts of DOpE:

• 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) w.open()

Additionally the 'Window' has the same '-scrollx' and '-scrolly' attributes as the 'Frame'. So the simple instruction:

w.set(-scrollx yes -scrolly yes)

would add full scrollbar functionality to the window.

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 library later.

Improved the command interpreter to be more tolerant when commands contain syntax errors.

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() f.set(-content g) b = new Button() g.add(b) g.place(b,-column 1 -row 1) w.open() 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.

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:

• assignments: widgets can be created and assigned to a variable symbol
  example: a = new Window()
• method calls - to call methods of widgets
  example: a.open()

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)

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:

• 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 DOpE-module)
• 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.

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 string.

The pictures of the Escape coding week are available now. Check out the new 'Mixed/Easter2002' section of this website.

...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.

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 is created.

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 greatly.

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:

• a object of 50x50 pixel is moving all the time and produces redraw requests
• 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?

• 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 'Drawings'-section.

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.

Today I created the german version of the 'Atari Coldfire Project' website.

Atari Coldfire Project (german):

http://acp.atari.org/index_de.html

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 'Bulletin'-section.

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 next period.

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 feature.

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'.

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.

Atari Coldfire Project:

http://acp.atari.org

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 row/columns:

• 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 layouts

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.

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 that.

Made 'Scrollbar'-widget fully functional. There are three ways to use it:

• clicking on the up/down or top/bottom arrows scrolls the slider softly
• clicking on the slider background let jump the slider one 'page' for/backward
• clicking on the slider for direct manipulation of the scroll position.

• SCROLLDRAG: this is the state while the user drags a scrollbar-slider
• SCROLLSTEP: this is the state while the user presses a scrollbar-arrow

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:

• 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 its children)

The new website for the Atari Coldfire Project is ready. The url will be officially published when all involved people give their permission.

Just added a new 'Links'-section. It contains some interesting links about Atari, programming and alternative platforms.

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.

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:

• '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'.

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.

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 week.

Fixed the clipping problem of the string drawing routine.

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:

• '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 the startup.

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 a minimum.

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:

• '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 :-)

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.

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 methods:

• 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 when needed
• inc_ref and dec_ref - to handle reference counters

• 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)
• reference-counter
• 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...

• '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 handle that.

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.

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)

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 :-)

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 eventloop.
• '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- mousedriver later)