1. Start
  2. Retro
  3. 2026

Another TRS-IO Story: Teuer und ungepflegt zum Glück(?)

3 Min. Lesezeit Retro
Another TRS-IO Story: Teuer und ungepflegt zum Glück(?)

Die Moral von der Geschicht': Tja, manch GitHub-Fund bereut man.

Auf der Suche nach einem weiteren Abenteuer für meinen TRS-80 Model III bin ich auf das Projekt TRS-IO gestoßen und habe mutig JLCPCB bemüht. Die ersten Bauteile, inklusive SMD, waren schnell bestellt. Dazu gesellten sich, eher teuer, ein Tang Nano 9K und ein ESP32-WROVER-E mit 8 MB. Ab jetzt war klar: Kosten dürfen hier nicht weiter kümmern.

Fein gelötet

Bauen, kompilieren, Rabbit Hole

Nachdem das gute Stück fein gelötet war, wurde klar: Sowohl die Software für den ESP32 als auch die für den Tang muss passend kompiliert werden. Bam. Ein Projekt von 2024, offenbar ohne weitere Pflege, und ohne jeden Hinweis zur Installation.

Frisch auf: Repo geklont, die ESP-Bibliotheken unter Linux installiert, und los ging die wilde Fahrt. Das make lief selbstverständlich herrlich schief. Der Erfinder hatte kein 8-MB-Modul und keine Anstalten gemacht, darauf vorbereitet zu sein. Also anpassen, wieder make. Ach, dann geht's. Und der ESP ließ sich auch befüllen.

Der Tang Nano bespielt sich aber nicht selbst, also selber ran. Dafür braucht es GoWin. Nach sechs Stunden Warten auf das verpflichtende Lizenzfile gab es Version 1.9.12. Böse Ahnung, und ein Issue auf GitHub bestätigte sie: kompiliert nicht. Code von 2024 trifft Software von 2026. Däng, es geht nur bis 1.9.9, und die ist nicht mehr freigegeben. Eine Stunde später hatte das Internet die alte Version aus der hinterletzten Ecke ausgespuckt. Nach weiteren undokumentierten Anpassungen (an der Stelle muss ich echt der KI danken, die Optionen hätte ich niemals gefunden) brutzelte GoWin eine Firmware ins Flash.

Die Spannung steigt. Tang Nano aufs Board, USB-Strom auf den ESP, und: LED-Blinkie-Blinkie. JUHU!

Äh, nein. Bootloop. „Guru Meditation Error“. ES. WAR. EINE. FALLE! ES. IST. TOT, JIM!

Kompatibilität ist König

Und es ging gleich weiter. Mein ESP32-WROVER-E nutzt die GPIOs 16 bis 18 für sein PSRAM, obwohl dort eigentlich Eingänge erwartet werden, die nur der „richtige“ ESP32-WROOM mitbringt. Klassisch zu doof, die Hardware korrekt auszuwählen. Also ein ESP32-DevKitC mit WROOM-32E bestellt. Weitere 15 Euro für nix. Hach, bin ich bescheuert. Aber nützt ja nix.

Mit dem WROOM kam das nächste Problem: Jetzt monierte der Boot, es gäbe kein RAM. Stellt sich raus, die Versionierung des Projekts ist komplett für den Eimer. Meine Fehler bezogen sich bereits auf den Zukunftsstand TRS-IO++, und ich habe kein ++. Mit einer Weiche im Makefile greift er auf die Quellen ohne PSRAM zurück und erinnert sich an seine WROOM-Wurzeln:

ifeq ($(BOARD),trs-io-pp)
  SDKCONFIG_DEFAULTS := sdkconfig.defaults;sdkconfig.trs-io;sdkconfig.$(BOARD)
else
  SDKCONFIG_DEFAULTS := sdkconfig.defaults;sdkconfig.$(BOARD)
endif

Damit wird es ein Model III mit 4 MB Flash und ohne PSRAM, statt des TRS-IO++ mit 16 MB Flash und 8 MB PSRAM. Jetzt geht der Compile durch, und ich sehe zumindest eine grüne LED und:

Die Weboberfläche des TRS-IO

Und nach einem SMB-Freigabe-String und einem ROM-Image auch:

SMB verbunden, FreHD gefunden

Die nächste Teststufe steht an! (Wow, haben die ihr Git versemmelt.)

Fast

Fehlt noch ein letztes Stück Hardware, für das sie einen GANZ speziellen Footprint gewählt haben.

Die Platine mit dem fehlenden Bauteil

Pfeiltasten wählen, Enter öffnetEsc schließt