Statische Webseite mit Hugo

Tim Riemann

Seit Ewigkeiten gibt es hier tatsächlich mal eine technische Neuerung: ich habe mein Weblog von Wordpress auf Hugo umgestellt. Aber warum der ganze Aufwand? So viel schreibe ich ja in letzter Zeit nicht mehr, oder? Naja, im Prinzip sind statische Webseiten ja gerade wieder in Mode gekommen und sie haben einen großen Vorteil: sie werden einmal generiert und danach dann nur noch vom Webserver ausgeliefert. Das führt zu einer drastisch höheren Performance der Webseite, da keine dynamischen Inhalte mehr generiert werden müssen und auch der Browser die Seiten besser cachen kann. Hinzu kommt noch: Kein Backend mehr, keine Datenbank, keine Sicherheitslücken im Blogsystem und oben drauf kommt noch ein “entwicklerfreundliches” Editiersystem mit Markdown. Als Nachteil kommt aber erst einmal der Wegfall der Kommentare oben drauf (die wurden hier ja eher spärlich verwendet) und natürlich eine höhere Komplexität bei der Einarbeitung / Gestaltung der Webseite.

Für die Umstellung von Wordpress auf Hugo habe ich zwei Konverter-Skripte verwendet, die die Datenbank von Wordpress verwenden, um danach die Markdown Dateien und Bilder in die entsprechenden Verzeichnisse abzulegen. Danach kommt eine ganze Menge Handarbeit, denn der Export ist nicht perfekt. Also heißt es die Links nacharbeiten und kontrollieren, ggf. externe Inhalte überprüfen und schauen, dass keine absoluten Pfade zum Weblog mehr drin sind. Die Artikel ins Menü schieben und danch überhaupt erst einmal das ganze Theme wieder anpassen.

Die komplette Überarbeitung habe ich in einem eigenständigen Git Repository durchgeführt, das ich auf Azure DevOps abgelegt habe. Azure DevOps habe ich aufgrund meines bereits vorhandenen Kontos sowie die Unterstützung von Hugo durch die Build Pipelines gewählt. Das Projekt ist so eingerichtet, dass eine Azure Pipeline, sobald ich einen neuen Commit und Push in meinem Git Repository durchführe, automatisch die Webseite mit Hugo neu baut und direkt auf meinen Webspace schiebt. Durch die Automatisierung dieser Abläufe spare ich mir die lästige Handarbeit und durch die Versionsverwaltung mit Git habe ich außerdem auch noch dezentral Backups angelegt.

Es ist zwar noch nicht alles perfekt, aber insgesamt bin ich mit der Umstellung ganz zufrieden. Ob ich die anderen Unterseiten noch umstellen werde weiß ich noch nicht, aber die CPC Seite ist mir eher zu lange gewachsen und momentan auch nicht in meinem Fokus. Das Development Blog könnte eher wieder zurück in dieses Weblog wandern - die Trennung war damals doch zu optimistisch.

Schneider CPC BTX Modul reaktiviert

Tim Riemann

In den letzten Tagen habe ich daran gearbeitet, auf Basis eines DBT-03 Emulators für den Raspberry Pi, das Bildschirmtext (BTX) Modul für den Amstrad / Schneider CPC wieder zum Laufen zu bekommen. Ich werde in den nächsten Wochen daran arbeiten, den Aufbau und die Einrichtung des Emulators zu dokumentieren, sodass ihr - sofern ihr so ein Modul noch besitzen solltet - auch wieder mit eurem CPC einen BTX Server, der online gehostet wird, erreichen könnt. Mehr Infos gibt es dann im nächsten Beitrag.

Hier ist jedenfalls das Video des funktionierenden Moduls, samt Start, Einwahl, Aufruf einiger Seiten und Nutzung der Wikipedia zu BTX Bridge. Mehr Infos und ein paar Links findet ihr in der Videobeschreibung auf Youtube.

Dreamcast wiederentdeckt / Docker Devkit

Tim Riemann

Vor Kurzem bin ich mal wieder über meine Sega Dreamcast gestolpert, die schon seit einiger Zeit ein Schattendasein in einer Stapelbox geführt hat. Ich habe sie bereits vor einigen Jahren schon mit einem GDROM-Emulator ausgestattet, den Akku der Echtzeituhr getauscht, eine Wechselhalterung für den Akku eingebaut, der laute Lüfter durch einen Noctua Lüfter und auch schon das alte Netzteil durch ein Pico-PSU ersetzt. Für den GDROM Emulator habe ich entsprechende Einsätze gedruckt, das Pico PSU wurde auf eine Halterung aufgesetzt und auch für den Lüfter habe ich einige Vorlagen bei Thingiverse gefunden, die den Einbau erheblich erleichtert haben. Das sieht dann momentan so aus (ist nicht mehr viel vom Original über…):

Dreamcast Umbau

Umgebaute Sega Dreamcast

Also wurde die Dreamcast mal wieder aufgebaut und eine Runde Crazy Taxi gespielt. Evtl. hänge ich auch meinen RasPi mit DreamPi wieder an die Dreamcast und spiele eine Runde Phantasy Star Online auf dem Sylverant Server.

Coders Cable Umbau

In meiner Stapelbox lag auch noch mein altes Coders Cable von Lik Sang, das einen MAX3222 Chip zur Wandlung von 3.3V auf RS232 verwendet hat. Heutzutage ist das nicht mehr üblich und deshalb habe ich das Kabel abgetrennt und ein FTDI USB nach Seriell Konverter drangehängt. Wenn ich mal etwas mehr Zeit haben sollte, werde ich mal schauen, ob man da nicht auch einen ESP32 dranhängen kann.

FTDI Coders Cable

Sega Dreamcast Coders Cable mit FTDI USB-Seriell Konverter

Docker KallistiOS Development Kit

Wenn man ein Coders Cable testen möchte, dann ist es natürlich sinnvoll, ein kleines Programm zu schreiben, das z.B. einen 3D Würfel rendert und auf dem Bildschirm rotieren lässt. Um das Programm zu erstellen, benötigt man ein Cross Development Kit und davor hat es mir bisher immer wieder etwas gegraut. Man musste dafür damals erstmal eine entsprechende Umgebung samt dem KallistiOS Development Kit kompilieren und das hat bei mir selten auf Anhieb funktioniert. Glücklicherweise gibt es heute bereits komplett fertige Development Kits bspw. das DreamSDK, das als Installer für Windows daher kommt. Da ich aber nichts installieren möchte, habe ich mich dann für ein Docker Image entschieden, das das komplette Development Kit mitbringt und so konnte ich, nachdem ich das KallistiOS GitHub Repository lokal geklont habe, die enthaltenen Beispiele über die Kommandozeile auf Anhieb kompilieren. Ich verwende dafür den Befehl

docker run -it –rm -v :/src einsteinx2/dcdev-kos-toolchain:gcc-9

um eine interaktive Konsole zu starten und dort dann die Make Dateien aufzurufen. Danach purzeln die Kompilate für die Dreamcast in den entsprechenden Verzeichnissen heraus.
Die Dateien habe ich bisher erstmal mit einer alten Version des DC-Tool-Serial übertragen und gestartet. Die Version v1.0.6 habe ich leider bisher noch nicht für Windows gefunden, also werde ich mich die Tage wohl mal dran setzen und das selbst kompilieren und vielleicht hier zur Verfügung stellen. Es ist auf jeden Fall ganz schön, mal wieder die alten Spiele zu zocken und auch mal wieder zu schauen, was die Homebrew Szene momentan noch so alles für die alten Konsole bastelt.

Farbpalette finden mit Paletton

Tim Riemann

Ab und an stehe ich vor dem Problem, eine vernünftige Farbpalette für ein Programm oder ein Grafikdesign zu finden. Wenn man dann noch Softwareentwickler ist, wie ich, wird es ganz schnell mal “entwicklerschön”, also sollte man für solche Fälle ein Tool zur Hand haben, das einem wenigstens schon mal bei der Farbpalette hilft.
Paletton ist so ein Tool, über das ich heute gestolpert bin und das eine Fülle an Einstellungen hat, die euch helfen eine geeignete Farbpalette zu finden. Über den Farbkreis könnt ihr zuerst einstellen, was für eine Farbpalette ihr haben wollt. Die Namen beschreiben die Anordnung der gewählten Farben im Farbkreis (Monochromatisch, Adjazent, etc.). Danach wählt ihr im Farbkreis einfach die Grundfarbe aus und könnt direkt auf der rechten Seite die dazu passenden Farben sehen.

Farbpaletten mit Paletton erstellen

Paletton - Tool zum Finden einer Farbpalette

Im unteren Bereich des Tools findet ihr außerdem die Möglichkeit Presets mit der gewählten Grundfarbe anzeigen zu lassen und die gewählten Farben in einer Vorschau zu visualisieren. Für letzteres gibt es auch wieder einige Presets, die euch unter anderem auch zeigen, wie Text in den gewählten Farbtönen kombiniert aussieht.
Schlussendlich könnt ihr über “Export / Tables” euer eigenes Farbdesign exportieren oder auch drucken. Hier wird euch die komplette Farbpalette samt der RGB Farbwerte angezeigt und ihr könnt sie in den unterschiedlichsten Formaten exportieren.

Ach… und noch ein kleines Gimmick, das ich anfangs übersehen habe: unten rechts findet ihr den Punkt “Vision Simulation”. Mit ihm kann man bspw. simulieren, wie die Seite für einen Farbenblinden aussehen würde. Ich finde es sehr wichtig, dass das möglich ist, denn allzu oft vergisst man, dass manche Menschen davon betroffen sind. Also checkt euer Farbdesign einfach mal schnell damit durch, damit es auch für farbenblinde Menschen gut zu lesen ist.
Insgesamt mag ich die Einfachheit von Paletton sehr und dennoch ist es möglich, damit sehr komplexe Einstellungen vorzunehmen, um seine gewünschte Farbpalette zu finden. Vielleicht ist es ja auch etwas für euch.

TinyFPGA BX Bootloader korrupt

Tim Riemann

Kennt ihr das: Ihr freut euch auf ein neues Entwicklungsboard, es kommt an, ihr schaltet es ein, führt das Tutorial durch und… Feierabend… nichts geht mehr. Aber worum geht es überhaupt? Schon während meines Studiums fand ich FPGAs sehr interessant und habe mich auch immer wieder mit der rekonfigurierbaren Hardware beschäftigt, denn, im Gegensatz zu Software, entsteht durch die Textbeschreibung eine richtige Hardware. Da es im Bereich FPGAs bisher nur proprietäre Software gab, interessieren mich natürlich die TinyFPGAs sehr, denn sie setzen auf Open Source Software und Open Hardware.
Ich habe mir deshalb zum testen mal ein TinyFPGA BX Board bestellt und es wurde auch sehr schnell geliefert. Nach dem ersten Einstecken und der Installation der entsprechenden Software unter Linux habe ich dann den Befehl (wir im Tutorial vorgegeben)

tinyfpga –update-bootloader

ausgeführt. Er wurde gestartet, brach aber direkt nach dem Löschen des EEPROMs ab. Der Chip war damit neudeutsch “gebricked” und ließ sich nicht mehr ansprechen. Man muss dazu erklären, dass das EEPROM die Hardwarebeschreibung für das FPGA enthält und natürlich auch den Bootloader.

An dieser Stelle hat man dann zwei Möglichkeiten: man schreibt den Hersteller an und er liefert dann ein neues Modul mit - hoffentlich - aktuellem Bootloader und probiert es dann noch einmal oder man schreibt den neuen Bootloader selbst in das EEPROM. Ich habe mich für die zweite Variante entschieden und möchte hier den Weg kurz beschreiben.

Zuerst musste ich an die Pins für das EEPROM herankommen. Glücklicherweise sind sie beim TinyFPGA auf der Unterseite verfügbar, allerdings nur als Pad. Die einfachste Variante wäre jetzt, ein Kabel an die Pads zu löten. Da aber das Board ggf. auch mal in einem Prototypenboard landen soll, habe ich mir ein kleines Programmierboard gebaut, das so genanne Pogo Pins (Deutsch: Federkontaktstift) zur Kontaktierung verwendet. Das sind kleine Pins, die mit Federn gegen die Kontakte gedrückt werden (siehe Bild).

Pogo Pins - Federkontaktstifte

Pogo Pins auf dem TinyFPGA Programmieradapter

Als nächstes musste noch irgendwie der Bootloader in das EEPROM gebracht werden. Genau für sowas habe ich mir vor Ewigkeiten mal den Bus Pirate von Dangerous Prototypes gekauft. Zusammen mit dem Tool flashrom kann man damit dann EEPROMs neu beschreiben.

TinyFPGA Programmieradapter mit Bus Pirate

Bus Pirate mit Programmieradapter und TinyFPGA BX Board

Anschließend braucht man nur noch das TinyFPGA Board in den Programmieradapter einstecken und mit flashrom das EEPROM neu schreiben. Hat aber leider nicht beim ersten Mal funktioniert, denn das FPGA stört die SPI Kommunikation mit dem EEPROM. Dafür gibt es aber eine ganz einfache Abhilfe: einfach den Reset-Knopf auf dem TinyFPGA Board während der Kommunikation gedrückt halten, das FPGA bleibt dann im Reset Modus und schaltet die Ein- / Ausgänge auf Tristate und die Kommunikation wird nicht gestört. Weitere Informationen zum Flashvorgang und den Bootloader findet man im TinyFPGA Forum.

Übrigens: solltet ihr auch ein Programmierboard zusammenstellen, dann denkt daran, es wenigstens halbwegs zu beschriften. Solltet ihr mal wieder vor dem gleichen Problem stehen müsst ihr nicht erst die Pinbelegung wieder herausfinden.