Computern kann man nicht vertrauen

In einem vorherigen Beitrag sprach ich mich dagegen aus, die Verschlüsselung von Emails zu empfehlen. Eins meiner Argumente ist dabei die fehlende allgemeine Vertrauenswürdigkeit von Computern, auf die ich in diesem Post etwas detailierter eingehen möchte.

Ziel von Verschlüsselung ist es, Vertraulichkeit herzustellen. Die Nachricht soll nur dem Absender und dem Empfänger bekannt sein, das genau ist, was durch die Verschlüsselung erreicht werden soll. Um dieses Ziel wirksam zu erreichen, ist es jedoch erforderlich, dass die Systeme, auf denen die Nachricht verarbeitet wird, vertrauenswürdig sind. Diese Vertrauenswürdigkeit soll in Deutschland sogar durch ein Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme von staatlicher Seite zugesichert und eingeräumt werden. Insofern ist Verschlüsselung die technische Umsetzung dieses Grundrechts.

"Integrität" ist in diesem Zusammenhang wie folgt zu interpretieren: Das System soll genau das und nur das machen, was die Benutzerin oder der Benutzer von ihm erwartet. Erweitert auf die Vertraulichkeit von Kommunikation heisst das: Wenn Alice eine Email an Bob schreibt, dann sollen alle beteiligten Systeme sicher stellen, dass niemand ausser Alice oder Bob den Inhalt der Email sieht.

"Seit Snowden" wissen alle, dass insbesondere US-Amerikanische Firmen nicht um unsere Grundrechte kümmern. Die Integrität von Facebook, Google, Amazon usw. ist also nicht gewährleistet. Hier kommt die Ende-zu-Ende-Verschlüsselung ins Spiel, die von Experten empfohlen wird, um die trotz kompromittierten Transportsystemen die Integrität der Kommunikation gewährleisten zu können.

Es bleiben die Endgeräte, im Idealfall die beiden Computer von Alice und Bob. Wenn die Verschlüsselung wirksam sein soll, um Vertraulichkeit und Integrität zu Gewährleisten, dann müssen zumindest die verbleibenden beiden Computer vertrauenswürdig und integer sein. Das sind sie jedoch nicht.

Die fehlende Vertrauenswürdigkeit beginnt dabei bei der Hardware: Weder die verbauten Chips, noch die in die Rechner werkseitig eingebetette Firmware ist integer im Sinne der Wünsche der Anwenderin. Als Kunde weiss man nicht, ob die Hardware nur dass kann, was man glaubt, dass sie kann. Es ist auch nicht sicher gestellt, dass die eingebettete Systemsoftware fehlerfrei im Sinne der Anwenderwünsche ist. Als Betreiber eines Computers kann man an die Integrität seines neuen Computers glauben, sicher kann man sich jedoch nicht sein.

Schwerwiegender jedoch ist die fehlende Vertrauenswürdigkeit der Software, die auf den Endgeräten zum Einsatz kommt. Die Erkenntnis, dass Software nicht "fehlerfrei" sein kann, ist heutzutage ein Allgemeinplatz. Eine Konsequenz daraus ist, dass das automatische Einspielen von Software-Korrekturen zur Fehlerbehebung eine Notwendigkeit ist, mit der sich Anwender davor schützen, dass Softwarefehler von Kriminellen zur Kompromittierung ihrer Systeme ausgenutzt werden. Durch diese automatischen Updates jedoch wird die Integrität der Endgeräte ständig kompromittiert, da jedes Update an das Potenzial hat, weitere Fehler und Sicherheitslücken nach sich zu ziehen. Es spielt dabei keine Rolle, ob man kommerzielle oder Open Source-Software verwendet: Wer Code aus dem Internet auf seinem Computer laufen lässt, kann nicht sicher sein, dass nicht auch unerwünschte Software zur Ausführung kommt.

Um zu meinem ursprünglichen Szenario zurückzukehren, in dem Alice eine Email an Bob schreibt und in dem alle zwischengelagerten Systeme durch Ende-zu-Ende-Verschlüsselung nicht mehr für die Sicherheitsanalyse in Betracht gezogen werden müssen. Angenommen, Alice hat auf wundersamen Wegen einen vertrauenswürdigen Computer kaufen können betreibt ihn ausschließlich mit selbst durchgelesener und für fehlerfrei befundener Software. Welche Annahmen kann sie denn über Bobs Computer machen?

Frei programmierbare Systeme, die schon werkseitig ohne eine Abgrenzung ihrer Funktionalität und ohne Überprüfungsmöglichkeit für den Benutzer sind, eignen sich nicht im mal Ansatz dazu, als Basis für die vertrauenswürdige Datenverarbeitung zu fungieren. Die Postulation von "Grundrechten" ist kein geeignetes Mittel, um diesen tatsächlichen Zustand zu ändern. Schlimmer noch: Wer behauptet, dass Sicherheit nur eine Frage der Installation der "richtigen" Software ist, nährt nur die Illusion von Sicherheit, die dann in der Zukunft weitere Enttäuschungen erfahren wird.

Vermutlich muss man den ganzen Komplex als Kampagne der heimischen IT-Industrie sehen. Angeblich schlechte Systeme, die von bösartigen ausländischen Mächten absichtlich unsicher gemacht werden, stehen gute Systeme von unserer heimischen Industrie gegenüber, die diese ganzen Nachteile nicht haben. Aber das ist Quatsch, und diese Versprechen werden nicht gehalten werden.

Was wäre denn die Alternative? Angenommen, die Integrität von IT-Systemen würde von staatlicher Seite als zu gewährleistendes Grundrecht interpretiert. Es müsste von staatlicher Seite sicher gestellt werden, dass zumindest bestimmte Datenverarbeitung in einem sicheren Rahmen stattfindet, auf den sich dann auch die Jurisdiktion verbindlich berufen kann. Da das Internet inklusive aller an ihn angeschlossenen Systeme insgesamt nur als kompromittiert angesehen werden kann, wurde im öffentlichen Diskurs die Forderung nach einem "Clean Slate"-Ansatz laut. Dieser Ansatz würde erfordern, dass eine komplett neue Systemwelt aufgebaut wird, in der jede Komponente für sich verifizierbar einem bestimmten Anwendungszweck genügt, und in der sich eine dritte Instanz (neben Alice und Bob) für die Systemintegrität verbürgt. Es muss für den Netzteilnehmer möglich sein, die Integrität der Endgeräte zu überprüfen, damit er oder sie wirksam davon ausgehen kann, dass die Kommunikation im Rahmen der von Dienst gewährleisteten Integritätsgarantien stattfinden kann.

Wer einen "Clean Slate"-Ansatz befürwortet, verabschiedet sich von dem offenen Internet, dass wir als Innovationsraum und als Erweiterung unseres Bewusstseins derzeit zu nutzen lernen. Mich erinnert das an die Zeiten vor der Liberalisierung des Telekommunikationsmarktes: Die Bundespost war damals die Instanz, die mit dem Telefonnetz das Kommunikationssystem betrieb. Die Integrität des Netzes wurde von staatlicher Stelle garantiert, und war - zumindest so lange das Netz analog war - auch faktisch gewährleistet. Die Liberalisierung des TK-Marktes und die Digitalisierung haben dazu geführt, dass die Annahmen über die Integrität der Kommunikationsnetze nicht mehr in der gleichen Form gemacht werden können - Einerseits, weil die staatlichen Garantien dank der Liberalisierung weggefallen sind, anderseits weil die Digitaltechnologie Integrität nicht von Hause mitbringt und es erheblichen Aufwand erfordert, die gleiche faktische Integrität in digitalen Systemen zu implementieren.

In den kommenden Jahren werden wir zunehmend Geräte kaufen können, die nur einem bestimmten Zweck dienen: Telefone, mit denen man nur (sicher) telefonieren kann. Tablets, mit denen man nur (sicher) Bankgeschäfte erledigen kann, Kommunikatoren, mit denen man nur (sicher) Emails senden und empfangen kann, Shopping-Konsolen, mit denen man (sicher) Produkte ansehen und einkaufen kann, Fernseher, mit denen man (sicher) fernsehen kann, das Staatsterminal, mit dem man (sicher) wählen und seine Behördengänge erledigen kann. Alle diese Systeme wird auszeichnen, dass sie komplett geschlossen sind. Es wird nicht möglich sein, auf ihnen eigene Programme laufen zu lassen, und ihre Funktionen werden vollständig von den Firmen und Institutionen bestimmt werden, die die entsprechenden Systeme betreiben.

In dieser Welt wird das Internet, wie wir es heute kennen, zunehmend an den Rand gedrängt werden. Wir werden etwas dafür tun müssen, wenn wir Freiräume er- und behalten wollen. Freiräume und Sicherheit stehen in grundsätzlichem Widerspruch, und es sollte nicht so getan werden, als liesse sich das eine durch das andere erreichen.

Warum ich meine Emails nicht verschlüssele

Das Verschlüsseln von Email ist ja derzeit wieder in Mode - Es wird als Beitrag zum Kampf gegen staatliche und nichtstaatliche Überwachung empfohlen, und es gibt Leute, die sich nur noch mit verschlüsselten Emails austauschen wollen.  Ich mache das nicht, und habe dafür meine Gründe.
Zunächst:  In jeder Sicherheitsdiskussion muss abgewogen werden, gegen welches Risiko man sich schützen möchte.  Es gibt - insbesondere in technischen Systemen - keine allumfassende Sicherheit gegen alle Risiken.  Wirksame  Sicherheitsmassnahmen erfordern stets die Identifikation des Risikos, und sie lassen sich in ihrer Wirksamkeit auch überprüfen.
Ein Beispiel für eine spezifische Sicherheitsmaßnahme ist der Sicherheitsgurt im Auto:  Er kann verhindern, dass man bei einer Frontalkollision mit dem Auto durch die Windschutzscheibe fliegt.  Bei einem Seitenaufprall jedoch kann man dennoch schwer verletzt werden, und der Gurt kann schlimmstenfalls sogar verhindern, dass man sich selbst befreien kann.  Die Wirksamkeit von Sicherheitsgurten lässt sich durch Statistik be- oder widerlegen.  Entweder, die Schwere der Verletzungen bei Frontalkollisionen ist seit der Einführung der Gurtpflicht zurückgegangen, oder eben nicht.
Allgemeine Sicherheitsmassnahmen hingegen sind Sicherheitstheater.  Sie dienen nicht dazu, einen bestimmten Schadenfall zu verhindern, sondern sie dienen der Beruhigung von Menschen, die Angst haben.  Das typische Beispiel für Sicherheitstheater ist das seit einigen Jahren erforderliche Ausziehen der Schuhe bei der Sicherheitskontrolle in Flughäfen.  Abgesehen davon, dass die Anzahl der Terrorschläge auf Flugzeuge gemessen an der Anzahl der Flugbewegungen extrem gering ist, ist auch die Möglichkeit, Sprengstoff in Schuhen zu verstecken, nur durch einen erfolglosen Versuch verbürgt.
Das private Verschlüsseln von Emails, wie es derzeit propagiert wird, fällt für mich in den Bereich von Sicherheitstheater.

Hier ein paar Argumente:

• Die Rechner, auf denen wir im Internet arbeiten und auf denen wir verschlüsseln, sind frei programmierbar.  Virenschutzsoftware und Open-Source-Programme bieten keinerlei Gewährleistung für Fehlerfreiheit.  Gezielte Angriffe auf jeden Computer sind jederzeit möglich, und sie werden auch durchgeführt.  Nach einem erfolgreichen Angriff muss im Prinzip das gesamte System als kompromittiert gelten, und wirksame Verifikationsmöglichkeiten existieren nicht.
• Der Glaube, durch Verschlüsselung könne man "den Geheimdiensten" "ihre Arbeit" "erschweren", ist irrig.  Verschlüsselung ist ein esoterisches Thema.  Zu glauben, dass das globale Internet-Email-System sich vollständig oder auch nur zu nennenswerten Teilen auf Ende-zu-Ende-Verschlüsselung mit bewussten Anwendern umstellen liesse, ist komplett unrealistisch.  Mit privater Verschlüsselung begibt sich der Einzelne einfach in die Gruppe derjenigen, die Verschlüsseln.  Das allein macht vielleicht noch nicht verdächtig, und im Zweifelsfall werden die Dienste bei einem Verdacht dann eben andere Massnahmen zur Aufklärung aufbringen.
• Private Verschlüsselung wiegt diejenigen, die es tun, in falscher Sicherheit.  Vertrauenswürdige Computer gibt es nicht, und was man ein mal in einen Computer, der mit einem öffentlichen Netz verbunden hat, eingegeben hat, ist potenziell öffentlich und sollte im Zweifelsfall auch öffentlich sein können.  Das gilt für private Kommunikation, und das gilt erst recht in konspirativen Strukturen, in denen sehr sorgfältige und individuelle Planung der Nutzung öffentlicher Netze notwendig ist.
• Auch, wenn Krypto-Befürworter stets die Wirksamkeit Ihrer Verschlüsselungstheorien behaupten, und auf die Endgültigkeit der Mathematik verweisen, so bleibe ich skeptisch.  Zum Einen, weil ich nicht überprüfen kann, ob das Verschlüsselungsprogramm wirklich das tut, was ich von der Mathematik verstanden habe (was ohnehin begrenzt ist), zum Anderen, weil immer wieder kryptographische Verfahren gebrochen werden.  Dabei ist für mich die fehlende praktische Verfikationsmöglichkeit ausschlaggebend.

Meine Konsequenz ist, dass ich keinen gesonderten Aufwand treibe, um mich gegen einen Feind zu schützen, den ich nicht kenne.  Wer mit mir kommunizieren will, kann mir eine Klartext-Email schreiben, mich anrufen. mir einen Brief schreiben oder mich treffen.  Mir ist wichtig, dass ich erreichbar bin und dass ich Leute erreichen kann.

TL;DR
Das Internet ist öffentlich und somit nicht der richtige Ort für Konspiration.

Das Internet ist die Erweiterung Deines Computers, aber dadurch ist Dein Computer Teil des Internets.

No ECLM in 2014

As many of you may know, there was the plan to have the European Common Lisp Meeting happen in Berlin in October 2014. I was part of the organizing team, and we've tried our best to find high-quality speakers to make the event be at least as good as the previous ECLMs.
Unfortunately, and you've determined that already from the title and the previous wording, we've failed. We simply did not find enough interesting commercial projects that have not been presented on one of the previous ECLMs. As we do not want to compromise on the content, we thus have decided that there will be no ECLM this year. We hope to learn about new and exciting developments in the course of this year so that we can have an ECLM in 2015.

Ein paar Sätze zum Thema "Alle sollen verschlüsseln"

Das Hauptproblem bei der Empfehlung des Einsatzes von Verschlüsselung ist die fehlende Möglichkeit für den Einzelnen, die Vorgänge in den digitalen Systemen zu überprüfen.  Ein erfolgreicher Angriff sowohl auf die Endgeräte als auch auf die beteiligten Software-Systeme ist jederzeit möglich, ohne verwertbare Spuren zu hinterlassen.  Es kommt dabei nur auf den Aufwand an, den der Angreifer treibt.  Hinzu kommt, das keinerlei Systemtechnik zur Verfügung steht, die das Etikett "vertrauenswürdig" auch nur im Ansatz verdient, und dabei ist es noch nicht einmal notwendig, auf die bösen Chinesen zu verweisen, die ja alle unsere Chips herstellen und beliebiges Zeug in die schwarzen Plastikdinger einbauen können, ohne dass wir es je merken würden.

Ich finde es daher unklug, den Einsatz von Verschlüsselungstechnik als so grundlegend sinnvoll zu bezeichnen, wie das bei weiten Teilen der Diskursteilnehmer derzeit gemacht wird.  Allenfalls handelt es sich um Sicherheits-Theater, mit dem der oder die Einzelne ausdrücken kann, dass ihm oder ihr die Entwicklung "nicht gefällt".  Tatsache ist jedoch, dass digitale Systeme aufgrund der mangelnden Verifikationsmöglichkeit inhärent unsicher sind.  Wer das verschweigt und Verschlüsselung empfiehlt, sorgt dafür, dass die nächste Empörungswelle nur noch größer, und was schlimmer ist, nur noch machtloser werden lässt.

Vermutlich sind noch ein paar GAUs notwendig, bis es in der Öffentlichkeit ankommt, dass die Digitalisierung nicht nur ein netter Layer von Information ist, sondern die Abhängigkeit von Ihr die Gesellschaft insgesamt erheblichen Risiken aussetzt.  Zu befürchten ist jedoch, dass die Reaktion dann gleich die positiven Seiten, die die Informationsgesellschaft für den Einzelnen zweifelsohne mit sich bringt, auch gleich einstampft.  Erste Schritte in diese Richtung sind ja derzeit schon zu sehen, siehe "Schlandnet" und ähnlicher Unsinn.

Aus politischer Perspektive muss man sich natürlich fragen, inwiefern die positiven Aspekte der Informationsgesellschaft insgesamt relevant genug sind, um für Ihre Bewahrung zu kämpfen.  Wenn man das jedoch dann tun möchte, sollten die inhärenten Risiken nicht in der Art und Weise ausgeblendet werden, wie das derzeit von vermeintlich progressiver Seite aus geschieht.  Der Einsatz nicht vertrauenswürdiger Verschlüsselungssoftware auf nicht vertrauenswürdigen Systemen jedenfalls wird das Problem nicht nur nicht lösen, sondern aufgrund der zu erwartenden Enttäuschungen eher noch verschlimmern.

"Drosselkom" - All your IP networks are belong to us

Seid Wochen entrüstet sich die Internet-Szene über die Pläne der Telekom, zukünftig Flatrates mit einer Volumenbegrenzung anzubieten. Nachdem es zunächst als Ungerechtigkeit dargestellt wurde, dass man für einen schnellen Anschluß bezahlt, den dann aber nicht voll auslasten können soll, und die Telekom erklärt hat, dass es für Vielnutzer eine kostenpflichtige Upgrade-Möglichkeit geben wird, konzentriert sich der Protest nun auf die durch die Telekom bedrohte "Netzneutralität". Stein des Anstosses ist, dass die Netzbetreiber durch technische Massnahmen Daten mit unterschiedlicher Priorität behandeln können und wollen. Das sei, so wird erklärt, eine Verletzung der "Netzneutralität", die von den Protestiernden quasi als gegebenes Recht angenommen wird.

Unabhängig davon, dass die Proteste nun eigentlich mit der ursprünglichen Geschichte nicht mehr so besonders viel zu tun haben, lohnt es sich doch, die Angelegenheit mal sachlich zu durchleuchten:

Warum will die Telekom ein gemanagtes Netz?

Für die "Netzgemeinde" ist das Internet ihr eigener, unregulierter Raum: Eine Sphäre, in der man beliebige Datenpakete zwischen Servern austauschen kann. Das kann auch mal nicht so gut funktionieren, dann dauert das Laden einer Webseite eben lange oder es ruckelt im Video oder der Ping ist schlecht, so dass man im Spiel ständig abgeschlachtet wird, aber so ist das Internet eben. Funktioniert meistens, und wenn es nicht funktioniert, dann ärgert man sich eben ein bisschen und guckt ein bisschen fern oder spielt lokal.

Für die Carrier ist die Infrastruktur, auf der auch dieses Internet läuft, in der Zukunft aber wesentlich mehr: Traditionell haben die Netzbetreiber über dem Internet, für uns Benutzer unsichtbar, das eigentliche Carrier-Netz betrieben. Dieses Netz basiert nicht auf der IP-Protokollwelt, sondern auf den ITU-Standards, die aus dem Telefonnetz hervorgegangen sind. Die Carrier-Netze waren die Basis für die Telefon- und sonstigen Datendienste, die man neben dem Internet "früher" verwendet hat. Nun ist es aber zunehmend so, dass es kaum noch Dienste gibt, die nicht auf der IP-Protokollfamilie basieren, und die Infrastruktur für IP-Protokollwelt aufgrund der massenhaften Verbeitung des Internet wesentlich preiswerter als klassische Carrier-Netztechnologie ist. Die alten Carrier bekommen das natürlich zu spüren, denn sie muss noch die alte, teure Technik unterhalten, während IP-only-Anbieter das komplett nachgefragte Spektrum von Netzwerkdienstleistungen preiswerter anbieten können.

Um marktfähig zu bleiben, stellen die großen Traditionscarrier nun also Ihre Infrastruktur komplett auf IP um. Das heisst auch, dass höherwertige Dienste - wie beispielsweise virtuelle Standleitungen mit fester Bitrate und Latenz - nicht mehr im Overlay-Carriernetz realisiert werden, sondern innerhalb der allumfassenden IP-Infrastruktur, in der auch das normale Internet angeboten wird. Es macht einfach Sinn, das so zu tun, und dazu braucht man eben ein gemanagtes Netz, in dem sich unterschiedliche Verkehrsklassen realisieren lassen, und darin unterscheidet sich ein Carrier-Grade-IP-Netz vom "Internet". Im Internet nämlich, dessen Freiheit derzeit verteidigt wird, werden traditionell alle Daten als Best-Effort-Verkehr gleich behandelt. Es macht im Internet keinen Unterschied, ob ein Datenpaket einen Teil einer Website oder ein Stück Ton aus einem Telefonat enthält. Wenn es zu Engpässen kommt, dann wird das Netz für alle Verkehrsarten langsamer. Beim Laden einer Website muss man länger warten, bei einem IP-Telefonat versteht man seinen Gesprächspartner nicht oder die Latenz wird größer.

Wenn nun also behauptet wird, dass so ein gemanagtes Netz der Netzneutralität entgegen steht und nach Regulierungen gerufen wird, dann stellt sich die Frage, welches Ziel damit verfolgt werden soll. Sollen die Carrier keine höherwertigen Dienste anbieten dürfen? Sollen sie gezwungen werden, höherwertige Dienste nur auf Leitungen anzubieten, die nicht auch best-Effort-Verkehr transportieren? Wozu soll das denn eigentlich gut sein?

Mir kommt es so vor, als sei die Diskussion im wesentlichen durch Unkenntnis und den Unwillen geprägt, sich mit der Technik und den Skalierungsnotwendigkeiten auseinanderzusetzen. Es soll alles immer schneller werden und fast nichts kosten, und wenn es denn was kostet, dann soll es doch die Allgemeinheit bezahlen. Wenn dieses Thema jetzt im Bundestag diskutiert werden sollte, dann kann ich mir nicht vorstellen, dass dabei irgendwas Sinnvolles herauskommt. Wenn schon die elitäre Netzgemeinde nicht versteht, wie Datennetze funktionieren, und auf einem Niveau von "Bei mir kommt das Netz aus der Telefondose" argumentiert, wie sollen denn dann die Internet-Ausdrucker aus dem Bundestag einen sinvollen Beitrag leisten?

Liebe Netzgemeinde, fordert doch bitte mal was Präzises, technisch Realisierbares, und nicht von technischen Dienstleistern, dass sie Euch bitte für 30 Euro im Monat die Illusion von "Freiheit" erzeugen sollen. Damit überfordert Ihr sie. Für die meisten Menschen ist die Diskussion ohnehin unverständlich, da sie überall und immer und billig Netz haben und das auch so bleiben wird.

FPGA based tabletop Pengo console

As a kid in the 1980ies, one of my favoured arcade games was Pengo, a maze action / puzzle game. I spent most of my pocket money playing it, and when I was introduced to dialup bulletin board systems in the same era, I chose Pengo as my online nick name, which stuck for some 10 years.

The adaptions of the game for home computers never sparked any fire in me, though, mostly because of the inferior graphics. The arcade version only had a display resolution of 224 by 288 pixels, but sprites and colors made it much prettier than what Sinclair ZX Spectrum, Amstrad CPC 464 or Commodore 64 could do.

At one point, a friend gave me an original Pengo arcade game logic board, which I have been carrying around for years, always wanting to make it playable at some point. Due to the non-standard video output generated by the board, I've never actually done it. Recently, I wanted to do something electronics related in my free time, and I picked the Pengo project up.

Arcade game emulation

Emulation is a common way nowadays to run ancient software. The older the software is, the harder it usually gets to find original hardware to run it on. Emulators provide a way to run original ancient software on current hardware, using software to impersonate the original hardware that the program expects to run on. Emulators exist for all kinds of systems and they are also useful when developing for embedded or other non-desktop environments.

Arcade game emulation is rather popular, with the open source MAME emulator being ubiquitous. MAME emulates all sorts of game hardware, starting in the 1970ies up to rather recently. Versions for most popular desktop operating systems are available, and there is MAME4ALL for the Raspberry Pi, too. MAME emulates the hardware for a huge number of games, but it is not distributed together with the ROM images for any of these games, for licensing reasons. ROM images are distributed through the familiar channels, though.

Another way to run older software is to use an FPGA to actually implement the original hardware. In the FPGA, almost arbitrary digital hardware can be created using configuration, so to run arcade software, one needs to recreate the original hardware in a hardware description language. Several arcade hardware systems have been implemented using FPGAs, and Pengo is one of them.

Compared to the software emulation approach that MAME uses, hardware emulation is less flexible as only one typically only one game fits into the configuration memory of one of the cheap FPGA boards. Also, fewer hardware emulations are available. FPGA based emulation boots quicker and requires less power, though.

FPGA based Pengo build

As I wanted to play with FPGAs again, I opted to use a Paplio Pro FPGA board for which a port of Pengo exists. The port includes a video scan doubler so that a standard VGA output signal is generated. All I/O is done through an Arcade MegaWing, which conveniently makes all I/O needed for emulating Arcade hardware accessible on standard connectors.

Wanting to finish up the project once and for all, I decided to get a cheap, used Dell 1504FP 15'' TFT monitor, a Zippyy Arcade and Fight Stick, a bunch of arcade buttons from eBay and talked my brother, who is a carpenter, into helping me build a proper desktop cabinet in his workshop.

To complete the hardware, I found myself a nice industrial 5V switched mode power supply to power the FPGA board and a small Kemo M031N audio amplifier module connected to a speaker.

The port of Pengo to the FPGA required some tweaking in the top level VHDL module to adapt it to the wiring that I used inside of the cabinet - The first joystick port is used for the coin and start signals, the second port is connected to the joystick. I also tweaked the DIP switch settings to suit my taste, which is something that must be done in VHDL as the Arcade MegaWing does not have switches that one could use for run-time reconfiguration.

More games!

At this point, my tabletop console only works for Pengo, and sure enough there are other games that one would want to play on it. Using a more flexible MAME based engine would get me there, and I experimentally swapped the FPGA board for a Raspberry Pi with MAME4ALL. While Pengo works fine on the Pi, the video display quality is much lower because MAME4ALL unconditionally uses antialiasing. This makes the resulting image blurry, no matter what physical resolution is chosen for the Pi. The FPGA based emulation uses simple scan doubling for video scaling which results in super-crisp display quality even though the TFT's physical resolution is not matched by the FPGA video output. So for now, I'm going to stick with the one game solution until MAME4ALL is fixed or I can find another way to run MAME.

Dealing with Excel files from Common Lisp - Using ABCL and Apache POI

In my day job, I mostly program in Common Lisp. Most of what I do is file and database work which Common Lisp is pretty well-suited for. Sometimes, though, I have to deal with data that comes in Excel files, and in the past that meant loading the files into Excel, exporting it into some plain text format and then working with those plain text files from Common Lisp.

While this works, it is a manual and error prone process. Also, Excels plain text export mechanism often mangles the data in undesired ways, which requires yet more additional manual steps (or VB scripting), which I'd rather like to avoid for processes that need to be automatic. Thus, I was on the looks for a way to access the Excel files directly with a Common Lisp program.

Writing a new Excel file parser was out of the question - I have real customer needs to fulfill, and implementing a capable Excel file reader is a large infrastructure project. So I looked into using an existing Excel file reading library instead. There are numerous options, commercial and non-commercial, and I've looked into one of the libraries written in C, but the requirement to more or less manually create FFI stubs and foreign structure layouts for a library that in itself was not documented very well and also did not look like being very accessible made me look for other options.

Apache POI

One of the more prominent open source libraries for accessing Microsoft Office files is Apache POI. It has been around for over 10 years and supports most MS Office formats, including the old OLE2 Excel format as well as the newer OpenXML format (that, despite using XML as the base format, is a horribly complex mess that I hope to never have to deal with directly). Apache POI is a Java library, so it can't directly be used from SBCL, which is the Common Lisp implementation that I normally use.

Armed Bear Common Lisp (ABCL)

In the recent months, I have noticed that there was quite some activity around Armed Bear Common Lisp (ABCL). I had tried an earlier release of it, and while it somewhat worked, it seemed to have a fair number of restrictions that made it unsuitable for me at the time. In particular, ABCL lacked support for the Metaobject Protocol which is something that I often use, either directly or as a library dependency. Also, the older version that I tried could not load the Postmodern library that we use to access our Postgres database, which was the final show stopper. But all that was before the recent 1.1.1 release of ABCL.

ABCL is hosted on the Java Virtual Machine (JVM), and maybe the biggest advantage of that is that access to other JVM-hosted code is straightforward and easy from Common Lisp programs running in ABCL. Thus, using Apache POI should be a snap. Also, as ABCL is becoming a reasonably complete implementation of the Common Lisp standard now, I had hopes to be able to use some of my existing infrastructure code in the program that dealt with Excel files.

To make it short: ABCL works great now. It took me very little time to translate the calls that I found in some Apache POI example program to Common Lisp, and I could also use all of the Common Lisp libraries that I needed for the task. There are some important libraries that don't work on ABCL yet (i.e. CXML-STP, CL+SSL), but I don't need these right now. And ABCL, during development, behaves like any other reasonable Common Lisp implementation in that it supports SLIME.

The Excel reading was a snap and the read process is reasonably fast, but ABCL's startup times are a bit annoying. There currently is no way to do the equivalent of "saving the world" on ABCL, so one has to load all required software at startup time. We're using ASDF for that, and it seems that some of the slow startup times need to be attributed to it. The Excel file reader will run as a batch job, so the startup times don't matter for our production uses, but testing the scripts was a tad tardy.

To illustrate how easy accessing Excel files from Common Lisp is, here is some example code that dumps the first worksheet of an Excel file to the standard output in a Tab separated values format:

;; -*- Lisp -*-

(defpackage :export-tsv
  (:use :cl))

(in-package :export-tsv)

(defun init-classpath (&optional (poi-directory "~/poi-3.9/"))
  (let ((*default-pathname-defaults* poi-directory))
    (dolist (jar-pathname (or (directory "**/*.jar")
                              (error "no jars found in ~S - expected Apache POI binary ~
                                        installation there"
                                     (merge-pathnames poi-directory))))
      (java:add-to-classpath (namestring jar-pathname)))))

(defun process-file (pathname)
  (let* ((file-input-stream (java:jnew "java.io.FileInputStream"
                                       (namestring pathname)))
         (workbook (java:jstatic "create"
                                 "org.apache.poi.ss.usermodel.WorkbookFactory"
                                 file-input-stream))
         (sheet (java:jcall "getSheetAt" workbook 0))
         (formatter (java:jnew "org.apache.poi.ss.usermodel.DataFormatter" java:+true+))
         (total-row-count (java:jcall "getLastRowNum" sheet)))
    (dotimes (row-number total-row-count)
      (let* ((row (java:jcall "getRow" sheet row-number))
             (column-count (java:jcall "getLastCellNum" row)))
        (dotimes (column-number column-count)
          (unless (zerop column-number)
            (write-char #\Tab))
          (write-string (java:jcall "formatCellValue"
                                    formatter
                                    (java:jcall "getCell" row column-number))))
        (terpri)))
    (java:jcall "close" file-input-stream)))

Before the process-file function can be used, init-classpath must be called to add the Apache POI jars to the Java class path.

As you can see, the program is rather short, and even if all comments are stripped, the Java version contains a lot more ceremony. No surprise here, maybe you wanted to have your prejudice confirmed :).

ABCL will now have a firm place in my toolkit. Big shouts go to the maintainers who did a great job lifting ABCL up to a level where it will be very useful to me.