Das offizielle Blog der h8u.de Gemeinde

Count on me, I'm gonna win the race.

-- Yello, "The Race"

Dieser Artikel ist entstanden im Rahmen meines Vorhabens entstanden, mir ein Entwicklungssystem für das Atari 2600 zu bauen. Genauer genommen, ist es bei dem Versuch entstanden, mein erstes eigenes Demo auf dem Atari 2600 in Stella zu programmieren. Der Titel ist deshalb englisch, weil eine deutsche Übersetzung entweder zu lang ist, sich doof anhört, der Kern nicht trifft oder alles zusammen.

Programmieren auf dem Atari 2600 unterscheidet sich vom Programmieren für andere Konsolen. Normalerweise ist es üblich das Spielgeschehen Bild für Bild in den Bildschirmspeicher zu schreiben. Man verändert dabei den Bildschirmspeicher zu einem Zeitpunkt an dem er nicht gerade dargestellt wird, und bereitet so das nächste Bild vor. Beim Atari 2600 gibt es keinen Bildschirmspeicher, der Seitenweise aufgebaut ist, sondern nur zeilenweise. Man befindet sich also in einem Wettrennen mit dem Rasterstrahl, "Racing The Beam".

Dabei gibt hilft einem der Video-Chip, TIA genannt, keinen Fehlstart hinzulegen. Dafür stellt er einem Methoden zur Verfügung, den Prozessor so lange anzuhalten, bis entweder der Bildschirmanfang oder der Anfang einer neuen Zeile erreicht ist. Ohne diese wäre es quasi unmöglich auf dem Atari 2600 ein Bild darzustellen.

Most people, I think, don't even know what a rootkit is, so why should they care about it?

-- Thomas Hesse, President of Sony BMG's global digital business division

Neulich habe ich etwas gebraucht, was ich im Nachhinein "poor man's rootkit" getauft habe. Wir wollten auf einem Linux System feststellen, welches Prozess an Sachen rumfingert, an die er eigentlich gar nicht ran sollte. Als Beispiel nehme ich mal an, dass es sich dabei um eine Konfigurationsdatei handelt.

Ich habe dabei ein paar Sachen kombiniert, die ich schon Monaten, das Meiste davon sogar schon seit Jahren kenne. Interessant ist dabei die Mächtigkeit, die aus den Kombination der Einzelteile entsteht. Der Trick besteht im Wesentlichen daraus, dass man dem Linker beim Starten eines Programms anweisen kann, neben den angeforderten Bibliotheken noch weitere "Shared Objects" hinzu zu laden, die dann eine höhere Priorität aufweisen. Das wollen wir uns zu nutze machen, um den Aufruf der Funktion open() aus der C-Bibliothek "abzufangen".

Erst wenn der letzte Programmierer eingesperrt und die letzte Idee patentiert ist, werdet ihr merken, daß Anwälte nicht programmieren können

-- leichenwagen, german-bash.org #330138

Beim Chaos Camp hatte ich es mir gegönnt, statt zu zelten in einem Hotel in der Nähe zu übernachten, nicht zuletzt auch wegen des Frühstücks. Bei eben diesen habe ich keine Gelegenheit ausgelassen, neue Leute kennenzulernen. Einer von ihnen, der sonst ebenso wie ich alleine gefrühstückt hätte, stellte sich mir als Holgi vor. Es ist Radiomoderator und hat unter anderen bis 2007 das Chaosradio gemacht. Das Frühstück war sehr kurzweilig, ebenso wie der spontan angesetzte Besuch beim örtlichen Real Markt.

Am letzten Tag saßen wir noch einmal beim Frühstück zusammen, und er ließ den Satz fallen "eigentlich wollte ich auch mal immer programmieren lernen..." meine Antwort war: "Lass es, es ist eine Zeitsenke." Je länger ich darüber nachdenke, desto mehr fällt mir auf, dass diese Antwort doch zu kurz gegriffen ist. Deshalb nutze ich doch einmal mein eigenes Blog, mich etwas detaillierter darüber auszulassen.

Mittlerweile würde ich die Fragestellung, ob man einfach mal so Programmieren lernen sollte, mir eine Gegenfrage beantworten: "Es lohnt sich nur, wenn Du weißt, was Du programmieren willst. Meinst Du, es lohnt sich die Technik des Malens zu lernen, wenn man nicht weiß, was man malen soll. Ein Musikinstrument, wenn Du keine Lieder spielen willst? Oder eine Fremdsprache, wenn man nicht vor hat, Literatur in dieser Sprache zu lesen, Filme zu sehen, und auch nicht sich mit Leuten unterhalten möchte?"

I am a programmer.

-- Kenneth Thompson

Seit längerem habe ich vor, kniffelige Sachverhalte in meinen Qt Programmen statt in Variablen und komplizierten Abfragen lieber in sogenannten Finite State Machines (in Deutsch auch Endlicher Automat genannt) abzubilden. Diese Woche habe ich mich dazu aufgerafft, diese Vorbaben bei einer von mir programmierte Abfrage der FreeDB Datenbank via des CDDB-Protokolls umzusetzen.

Irgendwie gab es immer einen Fall, in dem die Abfrage, die außerdem noch eine Schnittstelle zum Auslesen der CD-Daten via CD-Text verwendet, nicht so funktioniert hatte, wie ich es meinte. Habe ich mal schnell eben das eine Problem gelöst, habe ich meistens damit ein bis zwei andere Probleme geschaffen. Unterm Strich blieb immer mindestens ein Problem über. Also habe ich mir Gedanken gemacht, wie die Beschreibung der Funktion in einem Zustandsautomaten aussehen sollte. Nachdem ich dies graphisch beschrieben habe, habe ich es dann "von Hand" runter programmiert. Dabei sind mir noch Unzulänglichkeiten aufgefallen, die ich aber überraschend einfach in den Griff bekommen habe, durch das Hinzufügen eines neuen Zustandes und ein paar übersehener Übergänge. Das vorläufige Endergebnis habe ich hier noch einmal aufgezeichnet.


Wenn ich mir das Bild noch einmal anschaue, verstehe ich auch, warum viele Beispiele von State Machines Ampeln nachbilden: die Dinge neigen dazu, schnell an Komplexität zuzunehmen.

Rock it!
Rock it!
Rock it!
Rock it!

-- Intro of "You Spin Me Round (Like A Record)" by Dead Or Alive

Eines der Highlights auf dem Chaos Camp 2011 war zweifellos die "r0ket". Die Idee dahinter ist ein "hackable" Namensschild. Dort vereint ist ein LPC1343 Microcontroller mit Cortex-M3 Kern, ein OpenBeacon Funkchip, ein Nokia 1200 Dot-Matrix Display mit einer Auflösung von 96 x 68 Pixeln und einige Erweiterungsmöglichkeiten.

Es ist ein wahres Hackerspielzeug. Für Hacker. Von Hackern.

Genauer hätte man den Punkt kaum treffen können. Die Hardware ist so ausgeklügelt, dass man sie sich nicht "kaputt flashen" kann. In Fachkreisen nennt man das auch "bricken" von "Brick" dem englischen Wort für "Stein", weil in einem solchen Fall ein solches Gerät eben nur noch als ein solcher taugt. Das bedeutet also, dass man nach Herzenslust an der Software des Gerätes rumspielen kann, was ich auch schon ab Tag 1 des Camps gemacht habe.

Der Ausspruch "Wissen ist Macht" ist nicht einmal die halbe Wahrheit. Die wahre Macht rührt nicht aus dem eigenen Wissen, sondern der Unwissenheit des Anderen.

-- SvOlli

"Nimm doch einfach einen falschen Namen." Das ist die Antwort die ich höre, wenn ich sage, dass ich mich definitiv bei keinem sozialem Netzwerk anmelden werde. Selten war eine Antwort so kurzsichtig. Hier ist mal ein Blick auf die Zukunft: Telepolis hat einen sehr interessanten Beitrag mit dem Titel "Die Rückkehr der Zombie-Cookies". Dort wird ein Dienstleister namens KISSmetrics beschrieben. Der hat eine neue Web-Technik entwickelt: einen nach dem augenblicklichem Stand "unlöschbaren Cookie". Damit kann KISSmetrics einen Surfer beim Besuch verschiedener Webseiten identifizieren, und zwar eindeutig. Ist das nun wirklich so schlimm?

I’m your future, child. Don’t cry.

-- A very short story by Stephen Baxter

Es geht weiter bei meinen 8-Bit Projekten: für den Atari ROM Simulator haben wir uns mittlerweile für einen Microcontroller entschieden. Es wird ein Design auf der Basis eines Cortex-M3 Prozessors. Dies ist ein ARM-Prozessor, der nur über den Thumb2 aber nicht den ARMv7 Befehlssatz verfügt. Das Gerät an sich liest sich so interessant, dass ich mittlerweile mir noch ein allgemeines Testsystem geordert hatte. Ein bisschen habe ich damit auch schon rumgespielt, habe aber ein kleines Problem damit, dass es relativ eng mit dem SDK auf Eclipse-Basis verwoben ist, und mir für Grundlagenforschung ein wenig der Nerv fehlt. Außerdem hoffe ich auf dem Chaos Camp noch einiges an Wissen mitnehmen zu können.

Heute soll es nochmal um das Chameleon gehen, die FPGA-Implementierung eines Commodore C64. Nach etwas Überredungsarbeit habe ich dafür eine Netzwerkkarte bekommen, einen von acht Prototypen. Selten hatte ich so viel Spaß beim Programmieren gegen widrige Umstände. Ich habe da gerade eine Beta Version und einen Prototypen in der Mache, klar dass da noch nicht alles reibungslos funktioniert. Aber ist es jetzt wirklich ein Hardware-Fehler, oder habe ich doch noch irgendwo was falsch programmiert? Solche Fragen galt es zu klären. Inzwischen kann ich TCP Daten empfangen, für das erste Ziel, was ich im Auge habe, fehlt noch das Verschicken der Antwortpakete, und das sinnvolle Bearbeiten der empfangenen Daten.

Linux is inevitable. Either you support Linux on your hardware, or it will be hacked so it'll run sooner or later.

-- Michael Steil, "27c3 Console Hacking"

Es wäre übertrieben zu behaupten, ich würde Windows meiden, wie der Teufel das Weihwasser. Es ist wohl eher so etwas, wie wenn man einen alten Bekannten auf einer Party trifft, und feststellt, dass es nicht schade drum ist, dass man sich so lange nicht gesehen hat. Ja, diese Beschreibung trifft es wohl besser. "Mein" Windows ist immer noch ein Windows XP. Für das bisschen, was ich noch mit Windows mache, reicht das auch noch mindestens so lange wie es Sicherheits-Updates dafür geben wird, so gesehen reihe ich mich noch in die Mehrheit ein, wie ich bei Kris feststellen konnte. Alternativ verwende ich auch gerne CrossOver, die kommerzielle Version von Wine.

Und dennoch bin ich voller Vorfreude auf die nächste Version des "Betriebssystemersatzstoffes aus Redmond", wie ich Windows auch gerne nenne. Der Arbeitstitel "Windows 8" wird sicherlich noch einmal geändert, schießlich wäre es das erste Mal seit über 10 Jahren, dass Microsoft bei der Benennung mal konsistenz zeigen würde, von dem neuen System verspreche ich mir mehr, als von jedem anderen Windows, das ich bisher miterlebt habe, wenn auch eher indirekt.