Ich habe mich entschlossen, den Kommentarbereich zu entfernen und alle Kommentare zu löschen. Der Grund dafür ist die DSGVO, die ab dem 25. Mai 2018 wirksam wird.

Die Shredzone verwendet keine Cookies und kein Tracking, zeigt keine Werbung und lädt keine Bilder oder Scripte von fremden Servern nach. Ich habe kein Interesse daran, meinen Lesern hinterherzuschnüffeln, und habe deshalb alles so datensparsam wie möglich gestaltet.

Das einzige Problem war der Kommentarbereich. Dort sammelt man naturgemäß personenbezogene Daten, was wiederum einen Berg an Anforderungen und Pflichten nach sich zieht. Für einen Hobby-Blog, an dem ich keinen Cent verdiene, ist mir der Aufwand einfach zu groß.

Über eure Kommentare habe ich mich immer sehr gefreut. Schickt mir eure Anmerkungen, Lob und Kritik gerne weiter per E-Mail oder als Tweet.

Das Projekt luftdaten.info bietet eine Bauanleitung für einen Feinstaubsensor an. Er ist günstig und auch mit wenig Elektronikkenntnissen leicht zusammenzubauen. Die Bauteile gibt es in verschiedenen Elektronikläden und mittlerweile sogar bei Amazon.

Der originale Bausatz benutzt zwei Kunststoffrohre als Gehäuse. Die sind preiswert und in jedem Baumarkt leicht zu bekommen, sehen allerdings nicht besonders ansprechend aus. Ich wählte stattdessen eine handelsübliche UV- und wetterfeste Außen-Abzweigdose als Gehäuse. Ein selbst konstruierter Rahmen aus dem 3D-Drucker wird dort hineingesetzt und die Elektronik darauf montiert.

Der Rahmen bringt bereits einen Windkanal für die angesaugte Luft mit, so dass im Gegensatz zur Originalanleitung kein Schlauch notwendig ist. Gitter vor den Luftöffnungen verhindern, dass Insekten in das Gehäuse kriechen können. Im Gegensatz zu manch anderer gedruckter Lösung ist der Feinstaubsensor außerdem wie vom Hersteller vorgeschrieben ausgerichtet und die Einsaugöffnung vor Licht geschützt.

Im Gegensatz zur Originalanleitung kommt man hier allerdings nicht darum herum, den Lötkolben in die Hand zu nehmen.

1/8 2/8 3/8 4/8 5/8

Bonn ― In einer Sondersitzung der SPD AG haben die Aktionäre heute den Weg für eine Fusion mit dem ehemaligen Konkurrenten, der CDU AG, frei gemacht.

"Das war nur konsequent." sprach der CEO der SPD AG, Martin Schulz, vor der Presse. "Die Angebotspalette beider Konzerne zeigte schon lange große Überschneidungspunkte und hat sich seitdem weiter angenähert. Wir produzieren außerdem schon seit mehreren Jahren in gemeinsamen Fabriken."

Auch der CEO der CDU AG, Angela Merkel, zeigte sich erfreut. "Hier wächst zusammen, was zusammen gehört. Schon seit Jahren nutzen wir das Know-How der CDU AG, die Marketingfähigkeiten unserer Tochter CSU GmbH und die Arbeitskraft der SPD AG. Und das zu meiner vollen Zufriedenheit! Dieser Schritt war überfällig."

Der neue Konzern soll den Namen CDU-PD AG tragen. "Das 'S' wurde entfernt, da wir entsprechende Produkte schon länger nicht mehr anbieten." erklärte Schulz. Frau Merkel wird dem neuen Konzern vorstehen. Herr Schulz wird sich ganz um den Abbau der Arbeitsplätze kümmern, die durch Synergieeffekte wegfallen werden. Allerdings seien keine Entlassungen geplant. Schulz: "Die natürliche Fluktuation in unserem Konzern wird voraussichtlich völlig ausreichen."

Mit einem Einspruch der Kartellbehörden rechnen Schulz und Merkel nicht.

Die Fusion ist innerhalb der SPD AG nicht unumstritten. Insbesondere viele so genannte Zwergaktionäre stemmten sich bis zuletzt dagegen. Sie befürchten, dass nach einer Fusion die traditionellen Produkte der SPD AG völlig verschwinden werden. "Dabei sehen wir immer noch eine hohe Nachfrage, die die Konkurrenten nicht bedienen können.", so ein Aktionär auf der Sondersitzung. "Hier wird ein lukrativer Markt einfach liegen gelassen."

Auch die Börse sieht der Fusion nicht so positiv entgegen. Die Aktienkurse beider Konzerne lagen bereits in der Vergangenheit im deutlichen Minus. Viele Experten glauben, dass die Fusion nicht den erhofften Trendwechsel bringen wird.

Es gibt schon viele Artikel, wie man SSD-Festplatten richtig in Linux einbindet. Aber entweder sind sie unvollständig oder recht lange. Also, hier eine tl;dr-Fassung – SSD mit Fedora, kurz und schmerzlos.

Trimming

Wenn die SSD trimming kann (was mittlerweile bei ziemlich allen SSDs auf dem Markt der Fall ist), sollte es natürlich auch verwendet werden. Dadurch ermöglicht man wear levelling, gibt also der SSD die Möglichkeit, den Verschleiß der Speicherzellen zu verteilen.

In der /etc/fstab wird bei jedem Mountpoint, der auf eine SSD-Partition verweist, die Parameter discard angehängt. Eine gute Idee ist es außerdem, noatime hinzuzufügen, um die Schreibzugriffe auf die Platte zu reduzieren. Das sieht dann zum Beispiel so aus:

UUID=939446e3-9bb9-40a6-bf03-2d87bb8f5837 /                       ext4    discard,noatime        1 1
UUID=4f75261d-2e40-4e39-bf63-2a9c517fc73d /home                   ext4    discard,noatime        1 2
UUID=05db751b-5c2b-47da-8577-89ee30d90e56 swap                    swap    defaults        0 0

Das funktioniert mit reinen ext4- und btrfs-Partitionen sowie mit RAID-Partitionen. Wird LVM verwendet, muss in der /etc/lvm/lvm.conf zuerst bei der Option issue_discards eine 1 eingetragen und die initramfs mit sudo dracut -f neu gebaut werden. Bei LUKS-Partitionen ist ein Kniff notwendig, den ich weiter unten beschreiben werde. Swap-Partitionen trimmen immer, ein discard-Parameter ist nicht erforderlich.

Nach einem Neustart sollte man einmalig alle SSD-Partitionen von Hand trimmen:

sudo fstrim -v /
sudo fstrim -v /home

Man kann man das Trimmen außerdem automatisch wöchentlich vornehmen lassen:

sudo systemctl enable fstrim.timer

Eventuell kann man sich dann auch das discard in der /etc/fstab sparen, da es Löschoperationen verlagsamt.

LUKS-Partitionen

Verschlüsselte LUKS-Partitionen reichen von sich aus die Trimming-Kommandos nicht an die SSD weiter. Das hat auch einen guten Grund: Das Trimming erlaubt Rückschlüsse darauf, welche Teile der verschlüsselten Partition Daten enthalten und welche nicht. Das erleichtert einen gezielten Angriff auf die verschlüsselten Daten, zumindest theoretisch.

Um bei LUKS das Trimming einzuschalten, wird in der /etc/default/grub in der Zeile GRUB_CMDLINE_LINUX die Kernel-Option rd.luks.options=discard angehängt und mit

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

die GRUB-Konfiguration neu gebaut.

Wenn es sich um ein Upgrade einer älteren Fedora-Installation handelt und nicht um eine Neuinstallation, muss eventuell auch in der /etc/crypttab an allen Einträgen außer der Swap-Partition die Option discard angehängt werden. Danach wird mit sudo dracut -f die initramfs neu gebaut. Da man bei einem Fehler schnell ein nicht mehr bootendes System hat, empfehle ich diesen Schritt nur erfahrenen Linux-Anwendern.

Ab dem nächsten Reboot steht Trimming dann auch auf LUKS-verschlüsselten Partitionen zur Verfügung.

I/O-Scheduler

Was bei mechanischen Festplatten wirklich Zeit kostet, ist das Positionieren des Schreib-Lesekopfes, weshalb Linux versucht, die Daten möglichst zu sammeln und zu gruppieren. Bei SSDs spielt es dagegen keine Rolle, wie fragmentiert die Daten sind. Aus dem Grund kann man das Gruppieren wegfallen lassen und sich über die gewonnene Performance freuen.

Dazu wird eine Datei /etc/udev/rules.d/40-ssd.rules mit folgendem Inhalt angelegt:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

Beim nächsten Neustart verwenden SSD-Platten den noop-Scheduler, mechanische Festplatten weiterhin den für sie optimalen cfq.

Swappiness

SSDs können beliebig oft und schnell gelesen werden, verschleißen aber bei Schreibzugriffen. Swapping auf eine SSD-Partition ist zwar möglich, aber der Lebensdauer nicht sehr zuträglich. Folgende Zeilen in der /etc/sysctl.conf reduzieren das Auslagern auf die Swap-Partition auf ein Minimum.

vm.swappiness=1
vm.vfs_cache_pressure=50

Bei den heutigen Preisen selbst für üppige RAM-Ausstattung wäre es zumindest bei Desktop-Rechnern eine Überlegung wert, ob eine Swap-Partition überhaupt notwendig ist. Nachträglich kann eine Swap-Partition durch Auskommentieren der entsprechenden Zeile in der /etc/fstab deaktiviert werden.

Firefox-Cache

Firefox lagert seinen Cache in das Home-Verzeichnis aus, was eine zusätzliche Belastung für die SSD darstellt. Wer einen Rechner sein Eigen nennt, der mit üppig viel RAM gesegnet ist, kann auf das /tmp-Verzeichnis ausweichen, welches bei Fedora im Arbeitsspeicher statt auf der Festplatte liegt. Das geht leider nur über einen Eingriff in die Eingeweide des Browsers über die URL about:config.

Nach einer Bestätigung, dass man sich benehmen wird, wird mit der rechten Maustaste über Neu - String ein neuer String-Eintrag angelegt. Der Eigenschaftsname lautet browser.cache.disk.parent_directory, der String-Wert /tmp.

Danach muss der Firefox noch neu gestartet werden.

The ZX Spectrum was a comparable cheap home computer, and thus the tape loading and saving mechanisms have not been very sophisticated. The tape recording is just a stream of short waves (0 bit) and long waves (1 bit). The stream starts with a leader signal (a series of even longer waves) and a single sync pulse. So, in the theory, reading a tape recording means measuring single wave lengths, by taking the time between two zero-crossings, and converting them into a sequence of bytes.

But then again, we are dealing with 1980's analog technique. In practice, we will find signals like this. A click produced an additional zero-crossing that is to be ignored. Also, the amplitudes and DC offsets change all the time.

And pooof... There went another week of nightly hacking Python code, having very close looks at audio waves, and searching for clues about why tzxwav won't behave like I expect it to behave. But I think the result is worth looking at now! tzxwav now reads almost all of my tape samples without those dreaded CRC errors. If there are CRC errors, the sample was usually so damaged that it would need manual restauration.

And as a bonus, it is now almost twice as slow as before. But speed was never a goal anyway, as people are likely to convert their old tapes only once.

The author, on Christmas Eve 1985

Since I am in the mood of heavy ZX Spectrum retro action, I dug out all my old computer tapes in an attept to digitize and convert them. It turned out to be more difficult than I thought...

The first trouble was to find a tape player. I had disposed my last tape recorder a couple of years ago. The new ones I found at Amazon looked nice on the first sight. They could be connected to the USB port or even digitize the tapes straight to an USB stick. The customer reviews were scaring off: cheap plastic, poor sound, digitizing to USB stick was only possible on battery power... I had more luck on eBay, where I found a genuine 1990’s Aiwa Walkman (it’s even a recorder, with auto reverse and Dolby NR) in good condition for about the same price.

I connected the Walkman to my computer’s microphone input using a cable with 3.5mm stereo jacks, selected the correct tape type (Normal or CrO₂), and turned off Dolby NR. Then I digitized right away, using Audacity for recording and post processing. I used 16 bits per channel, and a 44100 Hz sampling rate. The ZX Spectrum provided a mono signal, so I chose the left or right channel (depending on the quality) and discarded the other one. Mixing down the stereo signal turned out to be problematic, as well as using a lossy file format like ogg.

The WAV files can be loaded into the Fuse Emulator, but it’s better to convert them to TZX files, as they are much smaller. There are a few tools for that, for example audio2tape that comes with Fuse. I wasn’t satisified with the result though, as the generated TZX files contained many CRC errors. MakeTZX is also worth a try, as it supports digital filters, but I was unable to make it run on Linux. Some other converter tools are for Windows only, and thus not very interesting.

So I found myself writing a set of TZX tools in Python. It contains tzxwav, that’s yet another tool for converting WAV files to TZX files, but is robust against poor audio quality. It took me three weeks of work, and about 30 hours of tape material, until it was able to successfully read almost all of my tape recordings.

An advantage of TZX files is that they contain the raw ZX Spectrum binaries, so they are very easy to extract. tzxcat allows to retrieve single binaries from TZX files, which can then be converted into PNG files, BASIC sources or whatever, provided there are converters for it.

What I have now are TZX files of all my old ZX Spectrum tapes. It was very interesting to rediscover my old files, screens, programs and source codes. In 1987 and 1988, I wrote a lot of more or less useful tools, designed several fonts and completed two demos.

On a slow processor like the Z80, it is essential to think about execution time. Often a clean approach is too slow, and you need to optimize the code to make it a lot faster.

The ZX Spectrum screen bitmap is not linear. The 192 pixel rows are divided into three sections of 64 pixel rows. In each of these sections, all the 8 first pixel rows come first, followed by the second pixel rows, and so on. The advantage is that when writing characters to the bitmap, you only need to increment the H register to reach the next bitmap row. The disadvantage is that a pixel precise address calculation is hell.

This is how the coordinates of a pixel are mapped to the address:

X2, X1 and X0 represent the bit number at the address. It can be used as a counter for right shift operations.

My first attempt was a straightforward code that shifted, masked and moved the bit groups into the correct places. It took 117 cycles. This is nice, but we can do better.

We need a lot of rotation operations to shift the bits to the right position. Rotation is a rather expensive operation on a Z80, because there are no instructions that rotate by more than one bit at a time. My idea was to divide the X coordinate by 8 (by rotating it three times to the right) and simultaneously shift Y3 to Y5 into the L register. With a similar trick, I could set bit 14 while rotating, which saved me another or operation with a constant.

This is the final optimized code. It takes the X coordinate in the C register, and the Y coordinate in the B register. The screen address is returned in the HL register pair. BC and DE are unchanged, so there is no need for expensive push and pop operations.

pixelAddress::  ld      a, b
                and     %00000111
                ld      h, a    ; h contains Y2-Y0
                ld      a, b
                rra
                scf             ; set bit 14
                rra
                rra
                ld      l, a    ; l contains Y5-Y3
                and     %01011000
                or      h
                ld      h, a    ; h is complete now
                ld      a, c    ; divide X by 8
                rr      l       ; and rotate Y5-Y3 in
                rra
                rr      l
                rra
                rr      l
                rra
                ld      l, a    ; l is complete now
                ret

It only takes 108 cycles, ret inclusive. Optimizing saved me 9 cycles (or about 8%). This doesn’t sound like much, but if the code is invoked in a loop, those 9 cycles are multiplied by the number of loop iterations.

I claim this is the fastest solution without resorting to a lookup table. Try to beat me!

If you are a child of the 1980’s, you maybe remember the Sinclair ZX Spectrum. It was an affordable home computer that could be connected to a color TV set, and used compact cassettes as mass storage.

My first computer was a Sinclair ZX-81. I learned BASIC and also Z80 assembler on it. Soon the ZX-81 was replaced by a ZX Spectrum. I programmed a lot, wrote all kind of tools and a few demos. I always wanted to write a game together with my friends, but as teenagers we lacked the necessary persistence to bring such a project to the end. Then, on the day I got my Amiga 500, I quickly lost any interest in my good old Spectrum.

But it’s never too late... I just started a tiny little game project called Coredump, written in Z80 assembler for the good old ZX Spectrum. Why? Just because I can. Because I always wanted to. And because retro programming also means a lot of fun!

This first article is about the tool chain I am using. I will add more articles as the game grows and is (hopefully) completed some day.

Back in the 80’s, programming assembler on the ZX Spectrum was a very tedious task. I had to deal with cassette tapes (and their very slow access), an assembler that already consumed some of the scarce RAM, and I had no tools that simplified the development process. When I did a mistake and crashed the Spectrum, I needed to reload the assembler, the source code and the resources from tape. Often I also lost some of my work because when dealing with tapes, saving a source code is much more work than just pressing Ctrl-S, so I rather risked having to retype the changes after a crash.

Today it’s much easier to write retro software. I can develop it on my Linux machine, which is very fast and has a lot of storage space. I use a modern text editor and a lot of powerful tools. For testing, I just need to assemble a snapshot file and run it on an emulator, which takes less than a second. If the emulator crashes, no work is lost.

These are the tools I use for programming. All of them are available for Linux and MacOS, some also for Windows.

• Fuse is an excellent ZX Spectrum emulator, with a very precise timing.
• A decent editor. I started with Atom, but now I am using Eclipse because it fits better to my workflow. Just use your favorite editor.
• zasm is a nice Z80 cross assembler that is also able to generate SNA files that run on the emulator.
• Multipaint is an open source drawing tool that handles the limitations of the ZX Spectrum graphics (and believe me, there are limitations). It turned out not to be so useful for sprite and tile generation, because it does not offer a precise control of the paper and ink color that is used in the generated screen file.
• So I also use Gimp for pixeling sprites and tiles. Maybe I will also use Inkscape later.
• Tiled is an excellent map editor. I use it to design the world of my game.
• Some self made helper tools convert the graphics and the world into the binary format that is used in the game. I use Java for these tools, just because I am most proficient with Java. There is no technical reason for that, just use the language you feel most comfortable with.
• Finally, I use ant to stitch all the parts together and run the snapshot file.

The ZX Spectrum hardware is very simple and easy to understand (which also means that you have to do a lot of things without hardware aid). The Z80 processor has a simple instruction set. So retro programming is not just for the old-agers, but also for the young generation who is interested in a first approach to the hardware level of computers. It is also fun to get the most out of a limited and slow hardware.

There is a lot of documentation available in the net:

• World of Spectrum has a lot of hardware documentation in the references section.
• A quick overview of all Z80 instructions and their timings.
• A commented ROM disassembly gives a first look at the Z80 assembler, and also offers some useful functions (like multiplication, the Z80 itself does not offer any multiply or divide instructions).

When I started looking for resources to the ZX Spectrum, I was surprised about how active the retro scene is. There are a lot of blogs offering tutorials that explain hardware tricks, and there is even a demo scene showing you things you’d never thought to be possible on that machine. After all, the Speccy is almost 35 years old now, and wasn’t famous for a powerful hardware even back at its time.