Blog overview

Latest entries:

2019-10-20: Terminal alternatives on Linux

I have used xterm for quite some time now since I want a simple terminal program that starts fast and keeps out of my way for most of the time. However, I miss some features from more advanced terminal programs so from time to time I take a look at alternatives.

I basically have the following requirements:

  • Fast startup: I start the terminal from within my file manager quite often when starting external programs or directly working on command line tools so fast startup is important to me.
  • Unicode/Ansi-Color support: The terminal must support unicode (utf-8 to be precise) encodings and must interpret ansi color codes.
  • Searchable scrollback buffer: I want to be able to search in the output of previous commands which makes it much easier to work with command line tools.


Since I use XFCE as my desktop environment it was clear to at least try xfce4-terminal.


  • nice color schemes out of the box
  • searchable unlimited scrollback buffer (Ctrl-Shift-f)
  • tab support
  • it is reasonable fast when using dbus to start a new window from an already running process, but the window does not always open in foreground with focus. From time to time the new terminal is in the background and I have to switch windows to access it.
  • there is an option to not use existing process but then it is quite slow: Executing
       time xfce4-terminal --disable-server -x ls
    takes 0.25s on my i5-3120M with 8 GB of RAM

rxvt-unicode (urxvt)

  • fast:
       time urxvt -e ls
    takes 0.07s
  • supports scrollback search (M-s)
  • configuration is done with x11 attributes (.Xdefaults)
urxvt is my current choice as it is fast and supports search. Some fancy features like tab support is only available via perl extensions and configuration is little bit hard since a graphical configuration is missing. But once configuration is done, it just keeps out of the way and does its job.

Here are my x11 settings for .Xdefaults:

URxvt.foreground: #d3d7cf
URxvt.background: #2e3436
URxvt.saveLines: 1000000
urxvt supports Xft font rendering. You can select a Xft font as follows:
urxvt.font: xft:Misc Fixed:style=SemiCondensed:pixelsize=13


  • reasonable fast
       time lxterminal -e ls
    takes 0.15s
  • graphical configuration and optional menu
  • tab support
  • no searchable scrollback buffer


  • graphical configuration and optional menu
  • tab support
  • slow
       time gnome-terminal -e ls
    takes 0.3s

Other terminals

Here's a quick list of other terminals I checked:
  • mate-terminal: did not run without other mate components
  • sakura: simple terminal
  • terminology: fancy implementation but still only basic terminal support
  • terminus: another simple terminal
  • tilix: slow, but interesting multi-session, tiling concept. If you use screen or tmux but want a more graphical implementation, you may want to check this out.

2019-06-04: Running Doom Sigil on Linux

Sigil is a new free episode for original Doom. It has been released 25 (or actually 26) years after the initial Doom release. As it is a wad file playable in original Doom, you can also play it in various Doom ports since the engine itself is GPL licensed. You still need the original Doom wad files. The actual episode can be downloaded for free at the Sigil website but you can also support the development by buying the file plus a soundtrack.

To run the episode, you basically put the original wad file and the sigil megawad into the same directory and start your doom variant with the following options:

$ doom -iwad DOOM.wad -file SIGIL_COMPAT.wad

The file SIGIL_COMPAT.wad is for better compatibility with vanilla ports of Doom.

Since I'm a Linux person, I tried the wad file for Doom engines running in Linux. I first tried Chocolate Doom, which is nice port focusing on original game play and graphics (including software rendering). While it basically runs in Chocolate Doom, there are also some issues. Since Chocolate Doom tries to be as close to original Doom as possible, it also contains some limitations of the original software. I noticed so-called visplane overflow crashes so I tried different ports of Doom.

Then I tried GZDoom which is one of the recommended ports. Unfortunately, on my linux installation (OpenSuse 15.1) it crashed on startup with a memory corruption:

Error in `./gzdoom': malloc(): memory corruption

So I looked further and checked one of the first advanced ports to linux, Doom Legacy. This port is more than 20 years old but there are still new releases. And to my surprise it actually runs Sigil very fine. Just start it with

$ doomlegacy -iwad DOOM.wad -file SIGIL_COMPAT.wad

and enjoy the new episode!

tags: doom1

2019-03-27: Debugging Amiga video signal problems

I experienced color problems on my Amiga 600 resulting in a yellowish picture. At first, it only happened for a few minutes after switching the Amiga on and magically fixed itself after that. But later on it always occurred. Using a paint program and cycling through the color palette I found that the highest blue bit seems to not working correctly any longer. The color values 0-7 increased the blue intensity but it goes back to black with value 8 and increased again up to value 15. So it seems that at some point the blue channel info is wrong. The symptoms were very similar to the problem shown in this video and the guy in that video needed to replace the graphic chip of the Amiga 1200. I hoped it was not the same for my machine.

Documentation is a must

Fortunately it is possible to get full motherboard schematics. I used the web site which offers an online view of the PCB including interactive selection of traces, very helpful to follow connections between chips. For a high-level schematics of the chips and their connections, I used for my specific Amiga model (A600 rev2).


I used a logic analyzer and started following the color line traces on the motherboard. First I checked the graphics chip "Denise" (8373). On the running Amiga I started PPaint to modify the background color and I changed each color channel individually from 0 to 15.

I started with the red channel. It's pin 22 to 25. On bit 0 (pin 22), I got a high TTL level on the logic analyzer for every odd value and a low for every even value, as you would expect. The bit 1 (pin 23) toggles every 2 values, bit 2 (pint 24) every 4 values and bit 3 (pin 25) every 8 values. Same result for green (pin 30-33) and blue (pin 26-29). So good news was that Denise seems to be ok.


Then I continued to the HCT244 line driver chips which basically just convert the input signal to a clean TTL signal. There are two chips for that purpose (U31 and U32) each having two 4-bit buffers so 3 of those buffers are used for the 12 bits of color lines. I checked the output pins just like before. For example, the highest blue bit goes into U32 at pin 2 and the corresponding output pin is 18. The result was that those chips seem to be alright too.

Back to analog

Next step is the resistor mesh for merging the color pins into a single analog signal and the transistors to boost the signal (as I assume). For the blue channel there is resistor group R126 and transistor Q213. This was the first time I saw the invalid blue channel value. Since I no longer have TTL signals but analog color values, I started using a simple digital multimeter to measure the (averaged) voltage. I saw that for red and green the voltage linearly increases up to ~2.5V. For blue on the hand the value jumps back to a smaller value when increasing the channel value from 7 to 8. Also, the voltage itself was higher than usual, up to 3V.

So there seemed to be something wrong with either the resistors (unlikely, they usually don't break unless you put to much current through them) or the transistor. Since the digital multimeter only averages the measured values, the voltages are not really helpful for detailed analysis and for resistor measurement, you also have to take into account that you measure not only the resistor but also the other way around the motherboard.

So I decided to get an oscilloscope and look into the actual signals to see which component actually causes the problem. Using the oscilloscope I was able to confirm that Denise and the driver chips are working fine. The signal looks identical for each color channel. But the transistor output is different on the blue channel in contrast to red and green.


The last component for the color generation is the RGB encoder, a standard Sony CXA1145P chip which mixes the three analog color values into a composite video signal. I measured a different voltage for blue than for red and green (for the same color value) but since the value at the transistor was already off, this chip does not seems to be the problem.

Game over?

At this point I thought that's it since I don't have the tools for SMD chip removal and replacement and repair was impossible for my limited tools and SMD skills. I thought that it is very unlikely that simple components like resistors and a transistor breaks while the more complicated ICs seem to be perfectly fine. And I was right. At a second thought I realized I was too much focused on the chips itself so I turned to the actual connections between the chips.


First I found the GND connection for resistor R216F (330 Ohm) is not actually grounded but I measured some voltage. I tested pulling the pin down to ground to see if that makes any difference but it didn't changed much. Then I checked the other resistors. First with the logic analyzer all 4 color resistors (1k, 2k, 4k, 8k) looked fine but using the oscilloscope I saw that the signal on the 1k resistor (R216B) was not actually that clean as on the output of the driver chip.

So it turned out that the motherboard trace between the output pin and the 1k resistor is partially broken. The same goes for the GND connection for the 330 Ohm resistor which should be connected to pin 19 of U32. I took some small wires and soldered them onto the board to bridge the connections. I connected the 330 Ohm resistor to the next easily available GND and I connected the 1k resistor directly to the driver pin 18.


That fixed the color issues all together. In hindsight the behavior of apparently self-healing after some minutes of using can be explained by broken traces as increasing temperature can temporarily "fix" or at least improve connection again. I hope the trace issues don't get worse over time but at the moment the picture is fine again.

So what are the findings:

  1. Start from the beginning to the end and check the signal values. You don't need expensive equipment if your measure carefully. A multimeter can be enough, a cheap logic analyzer helps a lot, and an expensive ocsilloscope is really helpful but not necessary.
  2. Have full control about the signals. For graphic output, modify each color channel individually. Use the background color as it also covers the border. Use as little other pixels as possible since they will alter the signal. Best case is a single color value for every pixel on the screen including the border.
  3. Check the input and output pins of all involved component.
  4. Check the actual traces between components. Don't assume that any connection, even GND, is actually what it is supposed to be.

Broken traces are pretty much impossible to fix on the motherboard itself, but luckily most of the time you can just bridge the connection using a wire. That does not look nice but usually it works fine, especially for digital signals on low distance.

tags: amiga6

All blog entries: all