Der fertige Joystick

Der fertige Joystick

Dies ist ein Projekt von 2004, auf der alten Schatenseite war es ausführlich beschrieben. Da gab es noch ein paar Bilder mehr, dazu Schaltpläne und eine Beschreibung wie ich den Tastaturcontroller analysiert habe.

Der PS/2-Anschluss von damals ist heutzutage obsolet. Mittlerweile würde ich so ein Projekt auf Basis von Mikrocontrollern machen, und dann per USB an den Rechner gehen. Deshalb lasse ich die Einzelheiten in der Vergangenheit und stelle das Projekt hier nur kurz vor.

Seinerzeit habe ich mich für MAME interessiert, den Multi Arcade Machine Emulator. Damit konnte man — man kann immer noch — auf einem PC die alten Spielhallenklassiker spielen. Eine Tastatur lässt aber nicht das authentische Feeling aufkommen, und so habe ich mir was gebastelt.

Ein Vogelnest

Ein Vogelnest

Die Joysticks waren eigentlich Zubehör für eine Sega Dreamcast Konsole. Ich habe die originale Elektronik rausgeworfen und stattdessen einen Controller aus einer PC-Tastatur implantiert. Dazu musste ich herausfinden wie die Matrix der Tastatur aufgebaut war, und die nötigen Kontakte dann mit den Mikroschaltern im Joystick verbinden. Gar nicht so kompliziert, eigentlich.

Die Kontakte für den zweiten Spieler habe ich auf einen Stecker gelegt, über ein Kabel das eigentlich für eine serielle Schnittstelle gedacht war konnte ich den zweiten Joystick anschliessen. Zusätzlich habe ich eine Y-Weiche gebastelt, damit ich neben den Joysticks auch noch eine richtige Tastatur anschliessen konnte. Irgendwie will so ein PC ja auch bedient werden.

Das Ergebnis war vom Aufbau her nicht schön, aber es hat funktioniert. :-D

Mittlerweile habe ich keinen PC mehr mit einer PS/2-Schnittstelle. Einen Joystick habe ich schon zerlegt und einer anderen Verwendung zugeführt. Aber das ist eine andere Geschichte, und die soll ein anderes Mal erzählt werden…

Siehe auch…

  • MAME – Die offizielle Seite des Arcade-Emulators
  • xMAME – Die Unix- bzw. Linux-Version
  • ArcadeControls – Tips und Anleitungen zum Selbstbau

Vor längerer Zeit habe ich hier mal auf eine Seite hingewiesen die Text durch entsprechende Homoglyphen ‚verschönert‘ hat, also Buchstaben durch ähnlich aussehende Zeichen aus anderen Alphabeten ersetzt hat.

Die Seite ist mittlerweile offline, aber hier gibt es einen Unicode Text Converter der das gleiche tut. Und wenn ich das Original noch richtig in Erinnerung habe mit noch mehr unterschiedlichen Varianten.

Wohlgemerkt: Da wird nicht der Font ausgetauscht. Es werden lediglich Teile aus den Fonts benutzt die man über eine gängige Tastatur kaum erreicht. Also Zeichen die eigentlich nicht dazu gedacht sind, normalen deutsch- oder englischsprachigen Text herzustellen. Copy & Paste funktionieren trotzdem, wenn man beispielsweise mal in irgendwelchen Messengern Schindluder treiben will…

Ḳäá¹…á¹… ṡëïṅ bAê™…ê™… biɘ ÆŽá´™gɘdá´Žiꙅꙅɘ иісЂт іммэѓ 🅖🅤🅣 𝖆𝖚𝖘𝖘𝖊𝖍𝖊𝖓. :-)

Ich sehe mir immer mal wieder gerne esoterische Programmiersprachen an. Lustig, auf was für Ideen Leute kommen — einfach nur weil es geht. :-)

Die meisten Sprachen haben eine vergleichsweise einfache Grammatik (es sei denn sie legen es speziell darauf an eben keine einfache Grammatik zu haben). Bei fast allen werden die Quelltexte in ASCII-Notation verfasst. Nennenswerte Ausnahmen sind Piet (da liegen die Quelltexte als GIF vor) und neuerdings vielleicht noch Emojicode. Aber selbst wenn es kein ASCII ist: es sind Dateien.

Jetzt habe ich von Folders gehört. Bei der Sprache liegen Quelltexte nicht mehr als Dateien vor, sondern als Ordner. Und damit die Ordner nicht so aus der Reihe tanzen haben sie griffige Namen bekommen: so heißt die Entsprechung für if jetzt New Folder, und aus print wird Setup. Der Datentyp für Integers heißt Vacation photos, der für Texte ist Img

Eingängig, oder? Und das beste: Quelltexte haben eine Länge von Null Bytes (nur halt eine komplexe Verzeichnisstruktur). Wer schreibt jetzt einen Flugsimulator? :-D

Traditionell bewege ich mich viel in der Shell, und da habe ich es oft mit verschiedenen Datenformaten zu tun die ich lesen oder schreiben möchte. Lesen ist mittlerweile vergleichsweise einfach: jq für JSON, XMLStarlet für XML.

Wie man sinnvoll XML generiert weiss ich noch nicht, aber vor ein paar Tagen hat Jan-Piet Mens ein Tool veröffentlicht mit dem man sauber JSON generieren kann: jo (hier bei Github).

Ausprobiert habe ich das noch nicht, aber die Beschreibung sieht sehr vielversprechend aus. Gerade in Verbindung mit dem Monitoring-Tool meiner Wahl — Zabbix — hätte ich mit so einem Tool im Werkzeugkasten einiges deutlich eleganter schreiben können…

Was stimmt hier nicht?

Was stimmt hier nicht?

Dies ist ein weiteres altes Projekt, entstanden etwa um 2004. Ich hatte das auf der alten Schatenseite, und damit es nicht komplett verloren geht stelle ich es hier nochmal kurz vor.

Damals konnte ich einen Commodore C64 der Mülltonne entreissen. Die ganz alte Bauform, in Fachkreisen auch liebevoll Brotkiste genannt. Leider war das Ding nicht mehr einzuschalten, und da ich eh keine Commodore-Vergangenheit habe tat es mir auch nur ein bisschen leid das Teil zu zerlegen.

Leider hatte ich zu der Zeit noch keine Ahnung von Mikrocontrollern, ansonsten hätte ich versucht die Tastatur funktionstüchtig zu halten. So ging das nicht, dementsprechend ist sie dem Dremel zum Opfer gefallen um Platz für Kühlkörper und Speicher frei zu machen. Schade. :-(

Eingebaut habe ich dann ein VIA EPIA M10000b, somit lief der C64 mit einer Taktfrequenz von 1GHz. Dazu kamen 256MB RAM, eine 2,5″-Platte mit 20GB, ein CD-Laufwerk aus einem Notebook und ein externes Netzteil.

Der C64-PC

Der C64-PC

So ausgestattet hing das Ding damals an meinem Fernseher. Hauptsächlich als Daddelkiste. Wirklich oft ist er dann aber ehrlich gesagt nicht mehr zum Einsatz gekommen…

Heutzutage würde man das anders angehen. In dem Gehäuse würde sich ein Raspberry gut machen. Der braucht wesentlich weniger Platz, also könnte man sogar die Funktion der Tastatur erhalten. Und mit Retropie als Distribution wäre das 80er-Jahre-Feeling fast authentisch… :-D

Siehe auch…

Eine alte Weisheit besagt folgendes:

Wenn man erstmal einen Hammer in der Hand hat sieht alles aus wie ein Nagel.

Wenn man also halbwegs mit dem gängigen Unix-Werkzeugkasten (grep, cut, sed und awk) umgehen kann ist man geneigt diese Tools immer einzusetzen wenn Informationen aus Dateien zu extrahieren sind. Damit auf strukturierte Daten loszugehen ist allerdings nicht nur fehlerträchtig sondern auch alles andere als elegant.

Vor längerer Zeit habe ich hier mal auf jq hingewiesen. Das ist die Lösung wenn man in seiner Eigenschaft als Shell-Skript Daten aus JSON-Datensätzen braucht, mittlerweile konnte ich da schon einige Male drauf zurück greifen.

Jetzt habe ich was vergleichbares für XML-Daten gesucht, und wie es aussieht ist XMLStarlet das Werkzeug der Wahl (Disclaimer: ich habe nicht lange gesucht, NOCH bin ich für Gegenvorschläge offen ;-) ).

Erste Anwendung ist wieder, einen ungetrübten Blick auf das gewählte Dokument zu werfen. Mein Feed ist ein insofern ein schlechtes Beispiel als dass der Code ziemlich sauber formatiert ist, aber der Trick wird klar (die Sache mit dem Backslash am Zeilenende setze ich mal voraus):

Als nächstes interessieren mich vielleicht die Titel der letzten Artikel. Dazu selektiere ich alles was auf den XPath //rss/channel/item matched, und lasse mir jeweils den Wert von title ausgeben. Gefolgt von einem Zeilenumbruch:

Aber wann habe ich denn meinen letzten Artikel veröffentlicht? Dazu matche ich nur auf das erste Element und lasse mir davon das pubDate geben, zur besseren Lesbarkeit wieder gefolgt von einem Zeilenumbruch:

Abschließend wüsste ich gerne noch worum es in meinem letzten Artikel ging. Auch das können wir formschön aus dem Feed extrahieren, allerdings wird das Kommando natürlich entsprechend unübersichtlicher. Wir matchen wieder auf das erste Item, lassen uns den Titel und einen Zeilenumbruch geben. Dann matchen wir innerhalb des Items (!) auf category. Dem Inhalt dieser Felder stellen wir jeweils einen Spiegelstrich voran, die Zeile beenden wir wieder mit dem Zeilenumbruch. So sieht das Kommando dann fertig aus:

Das Netz hält einige Artikel mit Beispielen parat, aber genau wie dieser Text kratzen die nur an der Oberfläche. XMLStarlet ist sicher ein Spielzeug mit dem man sich bei Gelegenheit mal länger auseinandersetzen sollte. Zumindest macht es den Standard-Werkzeugkasten im Umgang mit XML-Daten absolut obsolet.

Gestern habe ich auf Twitter gelesen dass es im Zabbix-Share ein Modul gibt mit dem man das Monitoring-Tool meiner Wahl — Zabbix — direkt auf einen Arduino zugreifen lassen kann: Zabbuino nennt sich das.

Komischerweise habe ich letzte Woche erst überlegt wieviel Aufwand es wohl sein mag, das Zabbix-Protokoll nachzuimplementieren. Ich bastele zur Zeit wieder mal mit dem WLAN-fähigen Chip ESP8266 herum, den hatte ich hier auch schon erwähnt. Damit lassen sich prima Messwerte einsammeln, und das schreit dann nach Zabbix. Mein erster Ansatz war, Messdaten per HTTP zur Verfügung zu stellen. Die werden dann von einem Skript periodisch abgeholt und per zabbix_send eingespeist. Wesentlich eleganter wäre es natürlich, Zabbix direkt auf den Sensor zugreifen zu lassen…

Es wäre also wirklich mal einen Versuch wert, das Zabbuino-Modul in Verbindung mit einer kleinen ESP8266-Platine zu testen, die kann man auch fuer deutlich unter fünf Euro kaufen. Oder hat das schon jemand ausprobiert?

Da ich das letzte Woche aber noch nicht kannte habe ich schon einen dritten Weg eingeschlagen. Noch viel besser, wie ich finde. Das ist aber eine andere Geschichte, und die soll ein anderes Mal erzählt werden…

Nachgemessen

Nachgemessen

Vor einer Weile hat mich jemand auf WeMos aufmerksam gemacht. Das sind kleine Entwicklungsplatinen, ähnlich wie Arduino. Im Gegensatz zu dem befindet sich darauf allerdings kein kleiner AVR-Controller, sondern der deutlich schnellere ESP8266 — mit dem ich ja in anderer Bauform auch schon rumgespielt habe. Dementsprechend funken die kleinen auch im WLAN. Da die WeMOS-Boards direkt per USB an den Rechner angeschlossen werden können entfällt das Gefummel mit RS232-Konvertern und 3,3V Versorgungsspannung, und programmiert wird komfortabel über die Arduino-IDE.

Sehr interessant ist die Mini-Variante. Dabei muss man zwangsläufig an das Buzzword Internet of Things denken. :-)

Für den Mini gibt es auch direkt ein Shield mit einem DHT22. Das ist ein Sensor mit dem man digital Temperatur und Luftfeuchtigkeit auslesen kann. Solche Messknoten will ich schon seit langem im Haus verteilen, und diese Boards sehen so aus als ob sie dafür gemacht sind. Der Wemos und das Shield kosten jeweils rund 4,50 Euro, so ist das auch ein bezahlbarer Spaß.

Abweichung je nach Anordnung

Abweichung je nach Anordnung

Die Programmierung war — Arduino-typisch dank der vielen Bibliotheken — nicht allzu schwer, so hatte ich nach kurzer Zeit einen funktionierenden Messknoten, samt der Messwerte im Zabbix.

Aber die Temperaturen waren verblüffend. Im Wohnzimmer ist es warm, aber nicht über 28°C. Nanu?

Das Infrarot-Thermometer hat mir dann verraten dass der WeMos stellenweise bis zu 32°C warm wird, und die Temperatur im DHT etwa 7°C über Raumtemperatur. Und richtig genug: wenn ich mein Platinen-Sandwich senkrecht positioniert habe waren es dank der Luftzirkulation nur noch 5°C zu viel. Mit dem Shield direkt neben dem WeMos — also nicht als Sandwich — waren es nur noch 2°C. Vielleicht hätte ich für den Versuch auch dünnere Drähte nehmen sollen. Vernünftige Werte habe ich erst bekommen als ich den Sensor thermisch komplett von dem WeMos entkoppelt habe, durch etwa 10cm Draht. :-(

Also: gute Idee, leider nicht ganz zu Ende gedacht. Von den WeMos-Boards werde ich mir wohl noch ein paar zulegen, aber die Sensoren kommen dann wohl in freier Verdrahtung zum Einsatz. Und vielleicht durch ein Gehäuse vom ESP getrennt…

Oh, eine andere Möglichkeit wäre vielleicht, die Sensoren aktiv zu machen. Bei mir werden die zur Zeit passiv abgefragt, per HTTP. Dazu müssen sie natürlich durchgehend im Netz sein. Wenn die sich beispielsweise nur alle fünf Minuten aktivieren und dann zum Beispiel per MQTT ihre Werte abliefern hätten sie vielleicht gar keine Zeit um sich aufzuheizen… und vielleicht würde diese Variante eh mehr Sinn machen. Schon allein wegen des Stromverbrauches (der im Moment übrigens bei 70mA am USB-Port liegt). Mal sehen…