Christian Berger (Casandro) und Hans Hübner (hans) haben auf der Classic Computing 2025 einen Vortrag über Bildschirmtext gehalten.

Der BT-1000 ist ein kombinierter Videotext und Bildschirmtext Dekoder.

Da dieses Gerät aus dem Versuchsbetrieb ist, ist es noch ein Prestel Gerät. Laut einem Werbeprospekt wurde nur eine „begrenzte Zahl“ dieser Dekoder gebaut, „über die inzwischen verfügt wurde“.

Was ist da also drin?

Oben sieht man das Netzteil und die Anschlüsse. Darunter ist die breite Hauptplatine. Auf der rechten Seite ist der SAA50xx Chipsatz für Videotext. Auf der linken Seite ist ein kleines 8053 System mit 2 Kibibytes ROM für die Software. Was ungewöhnlich ist, ist dass da ein UART IC drin ist.

Von unten sieht man oben das Netzteil sowie die gelbe „Interface-Platte“ und rechts eine kleine Platine die vermutlich die Verbindung zum Bandlaufwerk dar stellt.

Die „Interface-Platte“ enthält 2 Kibibytes an EPROM, und einige Schieberegister. Einen Mikrocontroller konnte ich da noch nicht finden.

So bald ich mal wieder Zeit habe untersuche ich das Gerät mal genauer.

In unserem auf xcept basierenden BTX-Dekoder  haben wir jetzt auch ein Programm welches CEPT-Dateien in Bilder umwandeln kann. Das Programm gibt nur Portable Anymap Bilder aus, welche jedoch einfach in PNG oder andere Formate konvertiert werden kann.

DIN-Steckverbinder haben ein Problem, sie sind spiegelsymmetrisch. Leider sind viele dieser Steckverbinder nicht durchnummeriert was die Nutzung relativ schwierig macht.

Allerdings haben wir hier einen Vorteil. Die ED-Leitung hat meistens einen Pull-Up Widerstand Richtung 5V. Somit kann man bei eingeschalteten Dekoder 5V an dieser Leitung messen. Damit das nicht jeder immer wieder machen muss, und da ich das jetzt eh gerade machen muss, hier die Belegung als Bild.

Nachdem wir auf dem 36c3 festgestellt haben, dass die ESP32-Module quasi gar nicht im Congress-WLAN funktionieren, kam der Entschluss das man eine verkabelte Lösung braucht.

Der momentane Ansatz sieht wie folgt an. An einen Raspberry Pi wird per SPI ein ATMega 8 angebunden, welcher dann per Optokoppler an das Terminal angebunden wird.

Die Idee ist wie folgt. Wir brauchen um ein DBT-03 zu emulieren nicht nur 1200/75 asynchrone Daten, sondern auch noch einige Signale, die ein UART nicht liefern kann. Zum Beispiel einen 440 Hz und einen 1700 Hz Ton, sowie einige Gleichspannungspegel.

Die naheliegende Lösung ist es einen Timer so einzustellen, dass er mit einer für das Signal passenden Frequenz Interrupts feuert und man dann den Rest in Software macht. So wurde das scheinbar auch in einigen Terminals realisiert. (z.Bsp Loewe Multitel)

SPI deshalb, weil der UART bei einigen Raspberry Pi-Modellen nicht zuverlässig funktioniert. Außerdem kann man dadurch auch den ATMega direkt programmieren. avrdude gibs auch auf den Raspberry Pi und das sollte auch direkt so den Controller flashen können, völlig unabhängig von eventuellen Bootloadern.

Der Prototyp ist noch ein wenig kostenoptimiert auf einer möglichst kleinen Platine. Natürlich kann man das auch auf eine Europlatine packen um das dann in ein original DBT-03 Gehäuse zu packen. Dann würde man zweckmäßigerweise auch gleich einen Schaltregler für die Spannungsversorgung einbauen, oder gar auf Power over Ethernet zugreifen.

Der momentane Stand dieses Projekts ist jetzt auch auf github unter https://github.com/bildschirmtext/rpi-dbt03

Zunächst benötigt man das ESP-IDF Framework. Wie man das installiert wird hier erklärt: https://docs.espressif.com/projects/esp-idf/en/latest/get-started/linux-setup.html

Es ist wichtig, dass man die Umgebungsvariablen setzt wie in Punkt 4 erklärt.

Ist das Framework installiert so holt man sich den Quellcode von hier: https://github.com/bildschirmtext/esp32_dbt03

Mit make menuconfig kann man die Einstellungen der Umgebung anpassen. Dort ist zum Beispiel unter „Serial flasher config“ der serielle Port auszuwählen. (häufig /dev/ttyUSB0, kann aber auch was anderes sein. Einfach mal ls /dev/ttyUSB* eingeben, mal mit und mal ohne eingesteckten Programmer und sehen welches dazu kommt)

Im Prinzip muss man dann nur noch make ausführen welches am Ende ausgibt welchen Befehl man zum Flashen eingeben soll.

Wenn das Gerät keine WLAN-Verbindung aufbauen kann, wartet es auf die Eingabe von 1. Gibt man das ein, so bekommt man ein Menü in dem man die Einstellungen bezüglich des WLANs und der TCP/IP Verbindung zum Server.

Unter https://github.com/bildschirmtext/btl_recovery/tree/master/src/tools gibt es jetzt display_chunks.c und split_chunks.c

display_chunks.c sucht in den Blöcken nach Zeiger-Längen-Tupeln die auf nicht-überlappende Bereiche zeichen und gibt diese, wenn man irgendeinen Parameter mitgibt, auf einer 256-Farbenkonsole bunt markiert aus. Die Position des Zeiger-Längen-Tupel wird oben in der gleichne Farbkombination markiert. So hat man einen guten Eindruck davon welche Elemente die Datei enthält.

split_chunks.c trennt einen Block in seine Chunks auf.

Wir haben einige Dateien bekommen welche wohl aus dem Programm BTX-Infotool 3 stammen. Dieses Programm diente wohl zur Erstellung von Bildschirmtextseiten und stammt von einer inzwischen nicht mehr existierenden Firma namens InfoTeSys in Düsseldorf.

Das Dateiformat scheint Blöcke von 2048 Bytes aufzuweisen und jeder dieser Blöcke (bis auf die ersten 3) wird mit 0-Bytes aufgefüllt. Davor befinden sich die CEPT Daten. Allerdings sind diese immer an unterschiedlicher Position innerhalb des Blockes.

Ein einfaches Programm welches versucht den Anfang des CEPT Teils zu erkennen findet sich hier:
https://github.com/bildschirmtext/btl_recovery