Ausgabe 11/2026

Als Anwender setzt man sich an seinen Computer, schaltet ihn ein und bekommt ein Bild zu Gesicht. Egal ob jetzt am Amiga, einem DOS-PC oder modernen Rechnern. Immer flackert da sofort etwas über die Mattscheibe und zeigt an, dass der Computer gerade am Arbeiten ist und irgendwann einen betriebsbereiten Zustand erreicht hat.

Auch als Entwickler ist das der ganz normale Alltag. Selbst wenn die gerade geschriebene Software crasht oder dann doch korrekt läuft, dass sie läuft und dass man etwas sieht, darüber macht man sich eigentlich nie Gedanken.

Zumindest ging es mir so, und ich kann nur sagen, diese Zeiten sind vorbei! Ich habe die Leistung zu schätzen gelernt, die hinter diesen bunten Bildern steht, die der normale Anwender für ganz selbstverständlich erachtet.

Die Insert-Disk-Animation des Amigas, ich glaube seit AmigaOS 2. Der Boing-Ball, etwas Schrift, ein Floppy und eine Diskette, die ins Floppy fliegt, um zu signalisieren, man solle doch bitte eine Diskette einlegen. Jeder, der einen Amiga mit entsprechendem OS hat oder hatte, weiss, man schaltet das Gerät ein, und genau das erscheint. Auch für mich war das nie ein nennenswertes Thema.

Am 12. Mai 2026 konnte ich voller Stolz mein erstes Video zu Chica der Welt präsentieren. Zwei Tage zuvor war der Moment gekommen, wo zum ersten Mal überhaupt ein echtes, nahezu korrektes Bild durch meine Hardware-Portierung, Hardware-Abstraktion oder wie auch immer man das jetzt nennen will, erschienen ist. Nur der Raspberry Pi 3B+, Chica und das Kickstart-ROM. Kein Linux, kein sonstiges Host-System, der Pi führte einzig und allein die Amiga-Hardware aus.

Auch wenn zuvor schon viele Dinge darauf hingedeutet hatten, dass Chica am Leben ist, war das doch für mich der ultimative Beweis, dass ich nicht nur einem Hirngespinst nachgejagt war, sondern mein Vorhaben wirklich zu einem Ergebnis führen wird.

Was ich an dem Tag noch nicht wusste, eine unglaublich anstrengende und vor allem nervende Jagd nach dem Grund für die nicht korrekt gezeigte Insert-Disk-Animation hatte begonnen.

Es war eine Zeit voller Frust und mangelnder Nachvollziehbarkeit. Wie konnte ich denn weite Teile von Agnus, Blitter, Copper und Denise ändern oder gar neu schreiben und bekam trotzdem immer und immer wieder das exakt gleiche Ergebnis? Ich fing an, jeden einzelnen Blit zu untersuchen, sogar eigene Copperlisten zu bauen, um die Funktionsweise besser zu verstehen. Eine eigene Debug-Konsole baute ich ein, und? Nichts! Den Fehler konnte ich einfach nicht finden.

Bis zum 30. September, über vier Monate später, konnte ich das Problem endlich beheben. Und? Was war es? Das Modulo im absteigenden Blitter-Modus hatte ich addiert statt subtrahiert. Wie ich also die ganzen vier Monate behauptet hatte, es war nichts weiter als ein +, dort wo ein - hinmusste. Mehr nicht!

Ich habe dabei eines ganz klar gelernt. Baremetal ist einfach nur die Hölle! Nicht nur Baremetal. Auch verschiedene Chips nachzubauen, die alle ihr eigenes Ding machen, ist einfach nicht feierlich. Es gibt keinen Absturz, keine Fehlermeldung, kein Hängen. Keine der gefürchteten Race Conditions, wo ein Kern etwas in dem Moment schreibt, wo der andere liest. Nein. Jeder Chip macht genau das, was er machen soll. Tja, er muss eben nur das Richtige machen, und das war in dem Fall wegen eines Vorzeichens falsch. Für das Ergebnis falsch, nicht für den Chip, denn der tat ja einfach das, was er tun sollte.

Seit dieser Erfahrung weiss ich eins. Ich habe den grössten Respekt vor den Menschen, die so etwas in Hardware bauen. Winzig kleine Kontakte treffen, mit Messgeräten verschiedenster Art in die Arbeitsweise der Chips hineinschauen usw. Ich ziehe meinen Hut! Ich musste nur Code ändern, und da einen Fehler zu finden, war schon der blanke Horror. So etwas an einer Platine, mit unzähligen kleinen Kontakten, nein danke. Das hätte ich nie und nimmer überstanden.

Ab da war dann bislang alles wieder relativ einfach. Eine ADF zu lesen war jetzt weniger das Problem. Der Vorgang ist gut dokumentiert, da kann man nicht so viel falsch machen, und dann?

Ja. Es ist "nur" die Amiga Workbench. Ist doch ganz normal, wenn man mit einem Amiga arbeitet, oder?

Oh nein! Die Workbench ist geladen und präsentiert sich in ihrem gewohnten Look, weil die Hardware darunter, also mein Chica, endlich so läuft, wie sie laufen soll. Die Chips arbeiten zusammen, dirigiert über Agnus, gesteuert über Zustände. Alles läuft so, dass Kickstart der Meinung ist, es läuft auf echter Hardware. Die Daten werden geladen, die Zustände gesetzt, die Chips erledigen ihre Arbeit. Nicht, weil da ein gekaufter Amiga drunter sitzt, sondern weil ich diese Hardware gebaut habe. Nicht auf einer Platine mit dem Lötkolben, sondern als Code auf einer SD-Karte. Mein seit gut 25 Jahren gehegter Traum, Kickstart auf einer verfügbaren, günstigen Hardware zum Laufen zu bringen, ist damit endlich wahr geworden!

Damit ist der Weg zum Ziel aber noch lange nicht zu Ende gedacht. Da mussten noch Maus und Tastatur dran, und es ist ein unglaublich gutes Gefühl, wenn man mit der Maus über die Workbench gleitet, einen Doppelklick auf ein Symbol macht, und das Fenster oder Programm öffnet sich. Ich kann dieses Gefühl nicht beschreiben.

Zeit, von fest in den Code kompilierten ROMs auf das Laden von ADF umzusteigen. Nach etwas Gefummel war das Ziel erreicht. Das ROM wird nicht mehr direkt in den Code kompiliert, sondern von der SD-Karte geladen. Wichtigster Schritt für eine Veröffentlichung, da ich das ROM ja nicht mit ausliefern kann. Dann noch das Laden über ein angeschlossenes USB-Gerät, in meinem Fall dem Floppinator, und Chica ist seinem Ziel schon ein gutes Stück näher.

Chica soll ja aber auch zeigen, ob und was es kann. Was eine nachgebaute Hardware auf blanker Pi-Hardware leisten kann. Die Voraussetzungen waren da. Chica lädt von Diskette, ich kann die Maus benutzen, also Sysinfo ins Spiel bringen.

Sysinfo zeigt es deutlich. ECS Agnus, ECS Denise, 68000 Prozessor usw. Dazu eine Geschwindigkeit, die über einem A2500 liegt.

Viele sehen wahrscheinlich diese Bilder und fragen sich, was da nun so besonders ist. Kann man auf jedem Amiga und jedem Emulator sehen, ist doch nichts dabei!

Für mich bedeuten diese Bilder jedoch so viel mehr. Sie laufen nicht auf einem Amiga, sie laufen nicht in einem Emulator, den ich mir irgendwo runtergeladen und installiert habe. Sie laufen auf einem nackten Raspberry Pi 3! Mit dieser SD-Karte kann der nichts anderes, als Amiga-Hardware emulieren. Die Chips aufgeteilt auf seine vier Kerne, die über den Bus, koordiniert von Agnus, brav nebeneinander ihren Dienst tun und dadurch ermöglichen, dass der Pi nun die Workbench lädt, Sysinfo darauf läuft usw.

Diese Bilder sind für mich der Lohn für eine unglaublich mühsame Arbeit, ein Beweis, dass alle Aussagen von wegen so ein Projekt wird niemals auf allen vier Kernen Baremetal laufen, falsch sind. Ein Beweis, dass der Pi 3 stark genug ist, die Geschwindigkeit eines Amiga 500 bei weitem zu übertreffen, obwohl mir das als technisch aussichtslos genannt wurde.

Wenn ich diese Bilder vor mir sehe, weiss ich, Chica lebt, Chica funktioniert.

Auch wenn ich wirklich überhaupt nichts Schlechtes über Moira als Prozessor für Chica sagen kann, gibt es doch drei Dinge, die mich zum Aufbau der Hirnfrei-68k-Familie bewegen:

1. Moira unterstützt maximal den 68020 und keine FPU.
2. In Chica ist alles selbst entwickelt, ausser der CPU.
3. Die ewigen Diskussionen, wenn der 68000 mehr als 7 MHz hat.

In einem Gespräch mit einem befreundeten Amiganer habe ich voller Stolz erzählt, dass Chica mit seinem 68000 mehr Dhrystones erzeugt als ein A2500 mit 68020-Prozessor, der in Sysinfo zum Vergleich aufgeführt wird. Als Reaktion bekam ich zu hören, ein echter 68000 habe aber nur 7 MHz.

Das ist ein Punkt, der mich wirklich stört. Genauso wie die Tatsache, dass Moira nicht weiter geht als bis zum 68020 und das auch noch ohne FPU.

Weiterhin finde ich es irgendwie auch nicht konsequent, wenn ich alles selbst entwickle und mich bei der CPU dann woanders bediene. Das hat nichts mit Moira zu tun, aber diesen Baustein sollte, meiner Meinung nach, dann doch bitte auch aus dem Hause Projekt Hirnfrei kommen.

Alles zusammen hat mich jetzt zu dem ehrgeizigen Plan bewogen, die Hirnfrei-68k-Familie zu entwickeln. Angefangen beim 68000, auf dem die nächsten Generationen, wie auch bei der echten 68k-Familie, aufbauen, bis hoch zum 68060, natürlich mit FPU.

Dazu sei sofort gesagt: Diese Prozessoren werden nicht zyklengenau sein, wie es Moira ist. Einfach deshalb, weil Chica das nicht braucht. Ja, in der ECS-Version von Chica ist es mir wichtig, aber das liegt darin begründet, dass die ECS-Version das Fundament von Chica darstellt und ich mittels Demos testen will, wie gut die Hardware zum Original funktioniert. Denkt dran, Chica soll so kompatibel sein wie möglich, und da gehört das, meiner Meinung nach, als Grundstock einfach dazu.

Chica selbst wird aber auf dem ECS aufbauen, AGA beinhalten, RTG beherrschen und natürlich den maximalen Prozessor verwenden, also den 68060. Wobei ich bei der 300d-Variante nicht ganz sicher bin, ob es dort nicht beim 68040 bleiben wird. So weit bin ich aber logischerweise noch nicht.

Wichtig wird sein, dass die Prozessoren ISA-konform sind (ISA steht für Instruction Set Architecture), damit sich der Prozessor in Chica so nah wie möglich so verhält wie das Original in einem echten Amiga.

Darüber hinaus darf ein Hirnfrei 68000 aber gerne einen echten 68020 abhängen. Die Hirnfrei-Prozessoren werden nicht an den Takt der originalen CPUs gekoppelt sein, sondern dürfen alles aus dem Pi herausholen.

Da Chica selbst nie mit einem 68000 veröffentlicht wird, von der ECS-Version abgesehen, fallen Demos direkt von Diskette ohnehin flach. Von daher besteht hier auch kein Grund für Zyklengenauigkeit im Prozessor. Das ist bei einem echten Amiga mit Turbokarte oder von Haus aus mit besserem Prozessor nicht anders. Die Custom-Chips sollen hingegen ihr Timing behalten.

Darüber hinaus habe ich auch angedacht, die Prozessoren mit JIT (Just-in-Time) auszustatten, wodurch die Instruktionen direkt vom ARM-Core verarbeitet werden, was noch einmal Leistung bringen dürfte. JIT ist allerdings so etwas wie das Sahnehäubchen. Ob sich der Aufwand lohnt, ob der Nutzen die Kosten übersteigt oder ob ein Chica 500(d) mit 68060 ohnehin schnell genug ist, wird die weitere Entwicklung zeigen.

Die FPU soll direkt auf der FPU des Pi laufen, was wiederum die Leistung steigern sollte. Hier gibt es noch eine offene Frage: Ein 68881/68882 rechnet mit 80 Bit, während die FPU des Pi nur mit 64 Bit rechnet. Inwieweit das zu unterschiedlichen Ergebnissen führt und wie stark das ins Gewicht fällt, wird sich erst noch zeigen müssen.

Da bliebe jetzt die Frage, wie hardwarekompatibel das dann noch ist. Hier verweise ich auf Projekte wie zum Beispiel den PiStorm, mit dem man einen echten Amiga auch mit ARM-Power beschleunigen kann und mehr Leistung bekommt, als die originale Hardware zu bieten hat. Von daher sehe ich an dieser Stelle keinen Bruch von Chicas Hardwarekompatibilität.

Wenn ich also wieder einmal einen Meilenstein erreicht habe und stolz anmerke, dass Chica mit einem Hirnfrei 680x0 in Sysinfo mehr Dhrystones liefert als ein echter Amiga mit Motorola-680x0-Prozessor, dann ist das einfach so. Es mag dann richtig sein, dass ein echter Motorola nie mit dieser Leistung existiert hat, es ist ja aber auch kein echter Motorola, sondern ein Hirnfrei.

Los gehen wird es, wie ja schon gesagt, mit dem Hirnfrei 68000. Chica werde ich dabei so aufbauen, dass ich einfach zwischen Moira und Hirnfrei wechseln kann, um die Funktionsfähigkeit zu überprüfen. Läuft der 68000 so, dass man nicht mehr unterscheiden kann, ob da jetzt Moira oder Hirnfrei läuft, geht es weiter zum 68020, 68030, 68040 und natürlich zum 68060. Bis zum 68020 werde ich dabei noch direkt mit Moira vergleichen können, ab da ist es dann förmlich Handarbeit.

Beim PC ist man es gewohnt: Man stöpselt irgendwas per USB dran, und das läuft. So ein Gerät hat aber auch normalerweise ein Netzteil mit entsprechend Power.

Beim Pi, zumindest bei meinem 3B+, sieht die Sache anders aus, man muss aber auch erst einmal drauf kommen.

Ich hatte ja das Problem, dass Bochser mir dauernd abgestürzt ist. Also ein kompletter Hänger, der sich nur durch das Trennen vom Strom beheben liess. Der Absturz war auch nicht reproduzierbar, sondern tauchte auf, wenn ich nichts gemacht habe, wenn ich einen Benchmark hatte laufen lassen oder wenn Windows 3.1 aktiv war. Es kam nie an der gleichen Stelle oder nach der gleichen Laufzeit.

Des Rätsels Lösung war die Spannung. Auch wenn ich an meinem Pi 3 ein originales Netzteil vom Pi 4 betreibe, reicht bei voller Power, also wenn alle Kerne mit 1400 MHz laufen, die Spannung in manchen Situationen nicht aus. Dann schaltet die Kiste nicht ab und meldet auch nichts. Eigentlich merkt man es nicht. Aber es kann durchaus dazu führen, dass irgendwo ein Bit verloren geht. Ja, ein einzelnes, kleines Bit. Auf einmal stimmt eine Adresse nicht mehr, es wird von einer falschen Adresse gelesen oder darauf geschrieben, und man hat den Salat.

Dem kann man aber Abhilfe schaffen. Das habe ich aber in dieser Ausgabe im Artikel “Der Fehler lag woanders” geschildert.

Der Strom spielt aber auch bei der Peripherie eine tragende Rolle. Mein Gedanke war ja: Ich stöpsle den Floppinator und mein externes CD-ROM da dran, und alles ist toll. Erste Tests haben das auch bestätigt, da habe ich aber auch nur das Inhaltsverzeichnis von der CD gelesen.

Nun wollte ich FreeDOS installieren, und das brach mir immer und immer wieder ab, ohne mir zu sagen, warum. Der Code gab mir keine Hilfestellung. Die Idee war dann: Wenn das CD-ROM anläuft, zieht es Saft, vielleicht mehr, als der Pi bereitstellen kann. Also klemme ich einfach ein Y-Kabel dazwischen und schliesse noch eine Powerbank an. Ja, das funktioniert. Manchmal!

Das hat mich echt wahnsinnig gemacht, bis ich das Rätsel lösen konnte. Meine Powerbank schaltet nach einer Zeit ohne Last schlicht ab. Dann bekommt das CD-ROM seine extra Power nicht mehr und läuft nicht an. Bochser ist da schon tapfer am Lesen, bekommt aber keine Daten, versteht das nicht und bleibt einfach stehen.

Hier konnte ich mir mit einem Ladegerät fürs Handy behelfen. Das schaltet nicht ab, und siehe da, die Installation von FreeDOS läuft anstandslos durch. Problem erkannt, Problem gebannt.

Auch wenn das schön und gut ist, eine Dauerlösung ist es nicht. Da wäre die Tatsache, dass vom Ladegerät dann über den USB Spannung anliegt, wodurch es passieren kann, dass man den Pi vom Strom trennt und ihn das nicht interessiert. Er zieht dann seinen Strom einfach über USB. Aber es tritt nicht immer auf.

Ich habe nirgendwo etwas gefunden, was hier eine Gefahr bescheinigen würde. Anscheinend ist das für den Pi also kein wirkliches Problem. Ich weiss es aber nicht sicher.

Für mich heisst das: Ein USB-Hub mit eigener Stromversorgung muss her, an den ich dann die ganze Peripherie anschliesse. So habe ich mir das zwar nicht vorgestellt, aber schlussendlich ist es auch kein Beinbruch. Tatsächlich stachelt es mich zum Basteln an, wenn ich Bochser ein Gehäuse baue.

Ich habe da schon Ideen im Kopf: ein Desktop-Gehäuse mit einem vernünftigen Netzteil, das den Hub und den Pi sicher mit Strom versorgt, dazu ein Schalter zum Einschalten und ein 5¼-Zoll-CD-ROM mit USB-Adapter. Das ist aber eine andere Geschichte.

Es gibt eine Sache, die mich unter Linux hin und wieder stört. Manche PDFs lassen sich nicht so ausfüllen oder gar anzeigen wie mit dem Adobe Acrobat Reader.

Es gibt PDFs, die einen zwingen, den Acrobat Reader zu verwenden, weil man sie sonst gar nicht erst öffnen kann. Wieder andere haben eingebaute Formulare, die aber nicht rechnen oder Werte übertragen, wenn man nicht dieses Programm verwendet.

Im Laufe der Zeit habe ich vieles ausprobiert und bin immer zum gleichen Schluss gekommen: Manche PDFs gehen nicht ohne den Acrobat Reader, und das hat mich genervt, gerade weil die Linux-Unterstützung seit Jahren tot ist.

Mit PdfCraft kommt nun die Hoffnung zurück. Kann dieses Programm das, was ich unter Linux manchmal wirklich vermisse?

Die Antwort ist leider ernüchternd. Nein, das kann es (noch) nicht. Zumindest nicht in der Version 0.8.0.

Was ich aber jetzt schon sagen kann: Dieses Ding ist wirklich unglaublich schnell. Selbst Atril, das ich aktuell verwende, wirkt beim Öffnen einer PDF etwas langsamer. PdfCraft ist sofort da, und nirgendwo scheint es arbeiten zu müssen. Egal was man macht, alles reagiert sofort, und das finde ich überaus interessant. Liegt das vielleicht an Rust oder an der Tatsache, dass es per Vibe Coding entstanden ist und die KI den Code einfach effizient hält? Ich kann es nicht sagen.

Auch das Ausfüllen von PDFs gestaltet sich flott und intuitiv. In die nächste Zelle springen mit Tab? Kein Problem. Das macht das Ausfüllen sehr einfach und schnell. Aber wie bei Atril und allen anderen Programmen, die ich getestet habe, rechnet auch PdfCraft nicht und überträgt keine Werte in eine andere Zelle, wie es der Acrobat Reader tut. Das ist richtig schade! Aber vielleicht oder hoffentlich kommt das ja noch. Ich bin hier guter Dinge und voller Hoffnung.

Ich habe nicht alles ausprobiert, was PdfCraft in seinen Menüs aufführt. Das Bearbeiten von PDFs, das Drehen, das Einfügen von Text und so weiter funktioniert, während OCR bei mir nicht funktioniert hat und ohnehin aktuell nur für englische Dokumente gedacht ist. Das ist schade, denn die Funktion finde ich eigentlich echt gut. Mein reMarkable 2 kann das zum Beispiel ziemlich gut, und ich nutze es dort auch immer wieder.

Ich werde die weitere Entwicklung auf jeden Fall im Auge behalten, und wenn die Formulare wirklich einmal wie im Acrobat Reader ausgefüllt werden können, muss Atril seinen Hut nehmen. Wobei ich jetzt schon am Überlegen bin, ob ich PdfCraft nicht schon jetzt als Ersatz verwende. Geprüft, wie sich das einrichten lässt, habe ich aber noch nicht, da ich PdfCraft nicht ohne den Launcher (siehe WordCraft) starten kann.

Ein schlechtes Gewissen habe ich allerdings gar nicht dabei, dass hier ja eigentlich der Acrobat Reader nachgebaut wird. Das hat einen einfachen Grund. Wenn ich mal wirklich auf das Original zurückgreifen muss, bekomme ich regelmässig Schnappatmung. Das Ding ist langsam und vollgestopft mit irgendeinem Kram, den ich überhaupt nicht will. Dauernd erscheint irgendwas und will, dass ich etwas benutze, und das macht die Arbeit damit einfach mies.

Wir haben ja schon das Spiel in unserer Horror-am-Freitag-Reihe durchgespielt, und ich war damals, nach einer kurzen Eingewöhnungszeit, von dem Spiel sehr gefesselt. Nun haben wir die erste Staffel der Serie geschaut, und ich hatte zu Beginn gemischte Gefühle.

Wenn ein Spiel so gut ist, kann eine Serie das transportieren? Wie wird es umgesetzt? 1:1 oder komplett anders, wie es zum Beispiel bei Resident Evil der Fall war?

Dann ging es los, und ich hatte sofort ein Problem. Pedro Pascal. Nein, nicht weil ich ihn für einen schlechten Schauspieler halte, aber mein Kopf hat sich einfach geweigert, dauernd Sätze wie "Das ist der Weg" zu erwarten. Auch wenn man ihn in der Serie Mandalorian fast nie sieht, er ist in meinem Kopf einfach ein Mandalorianer.

Aber! Auch wenn ich in der Serie immer wieder das Gefühl hatte, er kommt aus seiner Rolle als Mandalorianer nicht wirklich heraus, hat er einen grandiosen Job abgeliefert. Er transportiert Joel einfach unglaublich gut, und schon nach relativ kurzer Zeit konnte ich ihn voll und ganz mit dem Charakter aus dem Spiel identifizieren, auch wenn da immer wieder die Gedanken an den Mandalorianer aufkamen. Gerade bei Verwundungen wollte ich ihm zu gerne zurufen, er solle Bactaspray nehmen.

Etwas schwer tat ich mich hingegen von Beginn an mit Ellie. Bella Ramsey will in meinem Kopf optisch nicht zur Ellie aus dem Spiel passen. Da hilft auch die schauspielerische Leistung nichts, denn die war grossartig und hat diesen frechen Ton und die Art aus dem Spiel wirklich gut eingefangen. Auch die Dynamik zwischen Ellie und Joel passt in meinen Augen wie die Faust aufs Auge, aber eben optisch passt es für mich einfach nicht.

Zu meiner Frage, ob es eine 1:1-Nachbildung wird oder einen ganz eigenen Weg geht, war ich überrascht. So vieles hatte starken Wiedererkennungswert, während wieder anderes vom Spiel abwich.

Dazu kann ich eines sagen. Es passt einwandfrei! Ich war nicht enttäuscht, weil die Serie einen anderen Weg geht, sondern immer wieder überrascht, dass ich etwas Neues entdecken konnte und nicht alles so war, wie ich es erwartet hatte. Die Mischung ist hervorragend gelungen, sodass ich nie den Eindruck hatte, einfach das Spiel nun als Serie zu sehen.

Die Serie macht für mich hier alles richtig. Während das Spiel viele Actionsequenzen hat, in denen man sich mit Infizierten oder nicht so netten Menschen herumschlagen muss, fehlt davon viel in der Serie, und das ist auch gut so. In Spielen will man die Action, sonst wird es langweilig. Beim Schauen kann so etwas dann aber schnell unsinnig und künstlich wirken, und die Serie hält sich dabei perfekt zurück.

Was bei der Serie auch super funktioniert: Man muss das Spiel nicht gespielt haben. Mein Kind und ich haben es gespielt und wussten, wo der Hase langläuft. Meine Frau hingegen ging komplett frisch an die Sache heran und wurde trotzdem genauso gefesselt. Das spricht in meinen Augen sehr stark für die Serie, wenn sie auch Zuschauer, die mit dem Spiel nichts anfangen können, abholen kann.

Als Fazit kann ich hier nur sagen, diese Serie lohnt sich, egal ob man das Spiel gespielt hat oder nicht. Während viele Verfilmungen von Spielen ja doch eher mager bis schlecht ausgefallen sind, ist The Last of Us eine Zierde seiner Art. So und genau so sollte man Spiele auf den Fernseher bringen. Ich kann nur sagen, alles richtig gemacht!

Der Film stammt aus dem Jahr 2026 und ist irgendwie komplett an mir vorbeigegangen. Entweder gab es für ihn keine grosse Werbung, oder er ist einfach nicht bei mir hängen geblieben.

Im ersten Moment wirkte er wie genau das, was ich gesucht habe. Raumschiffe erreichen die Erde, Wissenschaftler wollen eine Waffe entwickeln, man kennt das alles, und so etwas taugt hervorragend, um bei der Arbeit nebenher laufen zu können, ohne die Konzentration zu stören.

Tja, damit lag ich falsch. Zwar ist der Film mal wieder nichts Neues, und so etwas kennt man durchaus aus anderen Filmen, von der Machart her ist er aber dann doch wirklich fesselnd.

Was mich beeindruckt hat, ist, wie die beklemmende Stimmung aufgebaut wird. Die Menschen treffen sich relativ schnell nicht mehr normal, sondern nur noch per Video. Es hat mich richtig mitgenommen, was für ein Gefühl der Hilflosigkeit das in einem auslöst.

Nach und nach drehen die Leute in ihren Bunkern durch, wohl ausgelöst durch sogenannte Scans der Besucher, die dadurch in die Köpfe der Menschen eindringen können. Eigentlich gibt es dagegen einen Stuhl, der vor den Sensorstrahlen schützen soll, doch der Schutz scheint nicht zu wirken. Dann fangen die Menschen an, ihren Verstand zu verlieren und sich selbst töten zu wollen.

Dieses Gefühl, über das Video mit anzusehen, wie sich die Menschen das Leben nehmen wollen, und dabei zu merken, dass man nichts dagegen tun kann, ist beachtlich. Selten habe ich einen Film gesehen, der das so beklemmend darstellen konnte.

Dazu spielt der Film viel mit Licht und Dunkelheit, mit abgehackten Videoszenen, mit Panik durch herumspritzende Proben im Labor und mit der immer wiederkehrenden Frage: Ist die Protagonistin des Films ebenfalls infiltriert und am Rand eines Suizids, oder kann sie sich dagegen zur Wehr setzen?

Was der Film für mich auch richtig gut macht: Den eigentlichen Angreifer, die Besucher, sieht man nie. Man kann genau genommen überhaupt nicht sagen, ob es eine reale Bedrohung gibt oder ob sich das alles nur in den Köpfen der Wissenschaftler im Bunker abspielt.

Interessant fand ich auch, dass eine Wissenschaftlerin, deren Stuhl angeblich top funktioniert und die deshalb gar nicht infiltriert worden sein kann, dann doch zum Suizid getrieben wird, indem Nachrichten über Zerstörungen in den Bunker dringen und sie davon ausgehen muss, dass ihr Sohn verstorben ist. Sind das echte Zerstörungen oder ein Fake? Lebt ihr Sohn? Sie sagt, sie spüre, dass er tot ist, und man sieht, dass sie sich das Leben nehmen will. Sie spürt es, sagt sie. Ist das aber nun echt, oder ist es ein Effekt der Besucher?

Ihren Suizid fand ich ebenfalls hervorragend gespielt. In wie vielen Filmen sieht man, wie sich jemand in den Hals sticht und dann einfach umfällt? Hier nicht. Ihr sieht man den dadurch entstandenen Schmerz an, sie ist nicht sofort tot, sondern man sieht sie leiden, und die Beobachter erleben es live mit. Das hat selbst bei mir eine emotionale Reaktion ausgelöst, anders als in vielen anderen Filmen, wo mein Kopf einfach sagt: Stand eben so im Drehbuch.

Am Ende dringt dann jemand in den Bunker der Protagonistin ein. Ist es nun einer ihrer Kollegen, der eigentlich an einem Selbstversuch verstorben ist? Hat sie sich das alles nur eingebildet? Ich war tatsächlich in dem Moment selbst am Zweifeln und habe die offensichtlichen Anzeichen nicht erkannt. Sie schon. Warum trägt er einen Schutzanzug? Sie kann atmen, also müsste er es doch auch können. Oder ist er ein Besucher? Die können nämlich in unserer Atmosphäre nicht atmen. Dreht sie nun durch oder ist es ein Besucher? Findet es heraus.

Ich finde es faszinierend, wie sich die Wahrnehmung verändern kann, wenn sich die Umstände ändern.

Seit ich das AmigaOS 3.2 gekauft habe und wieder aktiv mit dem AmigaOS arbeite, hat mich eine Sache immer gestört. Der Amiga läuft in einem Fenster auf dem Desktop. Ich kann das Fenster in der Grösse verändern, verschieben, in den Hintergrund legen und mit etwas anderem arbeiten, FS-UAE zeigt mit F12 ein Menü an, und Ähnliches. Auch wenn das AmigaOS genau das macht, was man von ihm erwartet, hat mir mein Kopf immer gesagt, dass ich nicht an einem echten Amiga sitze.

Diesen Umstand wollte ich umgehen, indem ich DietPi auf meinen Pi 3 gepackt und Amiberry darauf installiert habe. Mein Gedanke war: Wenn der Pi direkt in Amiberry startet, sollte sich das Gefühl, nicht an einem Amiga zu sitzen, doch relativieren.

Da habe ich falsch gedacht. Zuerst sieht man beim Booten die Ausgaben des Linux-Kernels. Dann kommt immer wieder ein Punkt, an dem man doch mal in die Konfiguration schaut oder Ähnliches. Nein, auch hier wollte sich das Gefühl eines echten Geräts bei mir einfach nicht einstellen.

Mein Kopf braucht einfach etwas anderes: das Gerät einschalten, und Kickstart bootet. Kein Linux oder sonst etwas. Schon damals, als Commodore die Früchte seines falschen Marketings erntete, hatte ich den Gedanken im Kopf: Irgendwie muss man doch ein verfügbares Gerät davon überzeugen können, sich wie ein Amiga zu verhalten.

Dann kam der DraCo. Kein Amiga, keine Custom-Chips, aber wenn ich ihn einschaltete, wurde sofort und ausschliesslich Kickstart gestartet. Für mich war das genau das, was ich wollte. Nach dem DraCo ging die Entwicklung aber in Richtung Casablanca, und damit war das Thema für mich vom Tisch. Klar, der DraCo war als Videoschnittplattform gedacht, und ich hatte ihn eigentlich zweckentfremdet.

Einiges an Zeit musste vergehen, bis eine geeignete Hardware erschien und ich die Erfahrung hatte, mich an ein Projekt wie Chica zu wagen. Chica hat im Timebolus ihre eigene Rubrik.

Mein Traum hat sich mittlerweile erfüllt. Chica ist so weit fortgeschritten, dass ich den Pi 3 starte, und nach wenigen Sekunden bootet das AmigaOS 3.2 von der Festplatte und ist einsatzbereit.

Betrachten wir es dabei einfach mal nüchtern: Chica bildet die Amiga-Hardware in Software nach und macht damit genau das, was auch FS-UAE macht. Es ist also technisch gesehen ein Emulator, wenn auch mit ein paar Unterschieden. Es ist keine echte Amiga-Hardware.

Dennoch: Der Pi bekommt Strom, ich halte die linke und die rechte Maustaste gedrückt, und auf dem Bildschirm erscheint das Menü. Ohne diese Tasten erscheint das typische Bild eines Amigas, der kein bootfähiges Medium hat. Oder, wenn eines vorhanden ist, wird von dort gebootet. Ein Spiel erscheint, eine Demo oder eben die Workbench. Sofort, ohne irgendwelche Randerscheinungen wie die Kernel-Ausgaben von Linux.

Selbst die Tatsache, dass man nichts irgendwo einstellen kann, trägt deutlich zum Gefühl bei. Es ist ein echtes Gerät mit eigener Tastatur, eigener Maus und eigener Peripherie. Für mich macht das einen himmelweiten Unterschied, obwohl der Emulator eigentlich praktischer ist: keine weitere Tastatur auf dem Schreibtisch und ein deutlich einfacheres Kopieren von Dateien auf die Amiga-Festplatte.

Trotzdem: Ich fühle mich jetzt schon weit zufriedener, als ich es jemals zuvor in einem Emulator war, obwohl ich noch nichts Produktives mit Chica gemacht habe, da sie ja noch in Entwicklung ist. Es fühlt sich einfach echt an. Allein für dieses Gefühl hat sich der ganze Aufwand schon mehr als gelohnt.