sslxy

Die Geschichte hinter dem Code

Seit 1996 begleite ich Webauftritte technisch mit einer eher einfachen Grundhaltung: Dinge sauber aufbauen, verständlich halten und so pflegen, dass sie auch später noch lesbar und brauchbar bleiben. Diese Arbeitsweise hat sich über viele Jahre hinweg bewährt.

Wichtig ist mir dabei die zeitliche Trennung. 1996 ist der Beginn der Webarbeit. Die technische Geschichte dahinter beginnt früher. Schon ab 1979 entstand die Grundprägung durch frühe Rechnererfahrungen. Ab 1983 wurde daraus ein kleiner Kreis, in dem Disketten, Reparaturen, Improvisation und gemeinsames Ausprobieren zum Alltag gehörten. Im weiteren Umfeld waren wir damals etwa 15 Jugendliche. Der kleine feste Kern bestand aus 5 – unser harter Kern, den wir intern halb ironisch die Beklopften nannten. 1994 kamen Übergangssysteme wie die beiden C65 in greifbare Nähe. Erst danach wurde daraus mit Shell-Accounts, HTML und Logdateien die spätere sichtbare Webspur.

Webseiten wurden dabei nicht ständig neu erfunden, sondern über viele Jahre hinweg ruhig weiterentwickelt – Schritt für Schritt. Das entspricht meinem Zugang bis heute mehr als jedes große Redesign-Gerede.

Ich bin weder Software-Architekt noch Agentur. Eigentlich bin ich nur jemand, der 1996 angefangen hat, HTML zu schreiben, dessen technische Denkweise aber schon viele Jahre vorher geformt wurde. Gerade deshalb bin ich lieber bei klaren Strukturen geblieben, während um mich herum vieles immer komplizierter wurde.

Zu dieser Haltung gehört heute auch, aktuelle Werkzeuge wie KI-Modelle und Cloud-Dienste praktisch zu prüfen. Nicht aus Begeisterung für Schlagworte, sondern um Nutzen, Grenzen und unnötigen Ballast im realen Einsatz zu erkennen. Dabei geht es bewusst nicht nur um freie Einstiege, sondern auch um bezahlte Varianten, wenn sich nur so sinnvoll beurteilen lässt, was ein Werkzeug tatsächlich kann.

Ich pflege dieses System eher wie einen alten Garten: von Hand, ohne große Maschinen und mit viel Geduld. Mein Wissen über PET, VC 20, C64, Amiga und andere ältere Systeme ist heute vor allem ein privates Archiv-Hobby. Aber genau daraus ist auch etwas geblieben, das für meine Arbeit bis heute wichtig ist: die Vorliebe für Ordnung, Ruhe und technische Klarheit.

Ich mag es, wenn Dinge auch nach Jahrzehnten noch funktionieren, ohne dass man dafür ein ganzes Team von Spezialisten braucht. Für mich ist guter Code wie ein sauber aufgeräumter Werkzeugkasten: nicht spektakulär, aber übersichtlich, verlässlich und so gebaut, dass man alles blind wiederfindet.

Warum der Name sslxy blieb

Der Name sslxy entstand Ende 1995 / Anfang 1996 nicht als Künstlername, nicht als bewusst erfundenes Pseudonym und auch nicht mit dem Gedanken an irgendeine tiefere Bedeutung. Er entstand schlicht aus einer praktischen Notwendigkeit.

Gemeint ist dabei meine erste selbst programmierte Website auf einem Shell-Account. Für den Shell-Account wurde ein kurzer Benutzername benötigt – für FTP, CGI und Logdateien. Der interne Servername lautete ssl-server-xy.

ssl stand dabei für frühe SSL-Experimente, unter anderem mit SSLeay unter FreeBSD – dem direkten Vorläufer von OpenSSL, der Mitte der 1990er-Jahre noch aktiv weiterentwickelt wurde – und selbstsignierten Zertifikaten. xy war eine einfache Kennung für ein Testsystem – im Sinn von Maschine Y, weil X bereits belegt war.

Eines der ersten Logfiles hieß sslxy.log. Der String blieb danach einfach erhalten – zunächst technisch, später auch nach außen: für Usenet, Mail und statische Seiten.

Mehr steckt eigentlich nicht dahinter. Kein Alias im klassischen Sinn, keine tiefere Bedeutung, keine inszenierte Figur. Eher ein technischer Rest, der geblieben ist, weil er funktioniert hat.

„Kein Alias. Keine tiefere Bedeutung. Eher ein Dateiname, der geblieben ist.“

Fernmeldelogik, Großraum Stuttgart und warum Infrastrukturdenken blieb

Ein Teil der technischen Prägung hinter sslxy entstand nicht in einem luftleeren Raum und auch nicht nur aus privaten Rechnerstunden. Es gab schon früh ein Umfeld, in dem Technik, Betrieb, Leitungen, Werkstattpraxis und funktionierende Systeme als etwas Alltägliches erschienen. Als grober Rahmen genügt dafür der Großraum Stuttgart – nicht als genauer Ort und nicht als nachprüfbarer Lebenslauf, sondern als industriell und infrastrukturell geprägte Kulisse, in der Maschinen, Netze, Fahrzeuge, Klinikbetrieb, Bürotechnik und Fernmeldelogik nie völlig fern lagen.

Entscheidend ist dabei gerade nicht eine einzelne Firma, keine eine Berufsbiografie und kein konkreter Name. Prägend war vielmehr die Summe vieler Berührungen: Gespräche mit Menschen aus technischen Berufen, Einblicke in Geräte und Arbeitsweisen, praktische Hinweise aus Werkstatt- und Betriebsalltag, dazu Bekannte, Durchreisende und Gesprächsfetzen aus Welten, in denen Systeme nicht als Dekoration galten, sondern als etwas, das funktionieren musste. In so einem Umfeld lernt man früh, dass Technik nicht zuerst schön aussehen, sondern unter Last tragen soll.

Man bekam keine offizielle Schulung, aber man hörte zu. Da waren Menschen aus großen Betrieben, aus Medizin, Werkstatt, Verwaltung, Netzbetrieb, Fahrzeugtechnik oder Fernmeldelogik. Sie saßen am Tisch, erzählten beiläufig, schimpften über Störungen, erklärten Geräte oder brachten eine bestimmte Sicht auf Ordnung, Erreichbarkeit und Belastbarkeit mit. Für jemanden, der ohnehin schon auf Rechner, Funk, Modems und Schnittstellen schaute, blieb davon mehr hängen, als man zunächst meinte.

Genau daraus entstand ein Blick, der bis heute geblieben ist: Ein System ist nicht interessant, weil es laut beworben wird, sondern weil es stabil arbeitet. Eine Leitung ist gut, wenn sie trägt. Eine Oberfläche ist gut, wenn sie den Betrieb nicht behindert. Ein Werkzeug ist gut, wenn seine Fehler erkennbar, seine Zuständigkeiten klar und seine Grenzen nicht mystifiziert sind. Das ist kein romantischer Technikbegriff, sondern eher eine nüchterne Form von Respekt gegenüber Infrastruktur.

Dazu passt auch, dass frühe DFÜ-Technik, BTX, Dataphon, Akustikkoppler, Modems und spätere Shell-Accounts nie bloß wie Spielzeug wirkten. Sie waren Endpunkte realer Netze. Wer mit so etwas umging, lernte fast zwangsläufig in Signalwegen, Gebühren, Verbindungszuständen, Leitungsqualität, Wartezeiten, Fehlversuchen und Protokolldisziplin zu denken. Es ging nicht darum, eine hübsche Benutzeroberfläche zu bestaunen, sondern darum, ob die Verbindung trägt, ob der Rückweg stimmt und ob ein Fehler sich eingrenzen lässt.

Für die spätere Webbetreuung war das wichtiger, als es nach außen sichtbar ist. Wer Systeme aus dieser Perspektive liest, baut Webseiten anders. Dann wird HTML nicht zum Marketingträger, sondern eher zur festen Verdrahtung einer Seite. CSS ist nicht Show, sondern Ordnungswerkzeug. JavaScript ist keine Atmosphäre, sondern gezielt eingesetzte Funktion. Und Wartung bedeutet nicht ständiges Neuerfinden, sondern sauberes Nachziehen, Prüfen und Vereinfachen.

Ebenso wichtig: Aus diesem Abschnitt soll ausdrücklich keine eindeutige Personenbeschreibung ableitbar sein. Er ist absichtlich so formuliert, dass nur eine technische Haltung sichtbar wird – nicht ein Arbeitgeber, nicht eine Familienlinie, nicht eine nachprüfbare Ortsgeschichte. Genau das entspricht sslxy eher als jede laute Legende. Was zählt, ist nicht, wer wo genau saß, sondern welche Denkweise geblieben ist.

„Code ist für mich keine Dekoration. Eher eine Leitung, die sauber terminiert sein und unter Last stehen muss.“

Dateiübersicht und vorhandene Unterseiten

Diese Seite ist die ruhige Übersicht. Die tieferen Einzelthemen liegen auf eigenen Dateien. So bleibt /sslxy/ die Hauptkarte, während Geräte-, Haltungs-, Web-, DFÜ- und Archivthemen auf die passenden Unterseiten verteilt sind.

Die Übersicht verlinkt die vorhandenen sslxy-Themenseiten gruppiert. Alte oder doppelte Startdateien bleiben aus SEO-Gründen nicht als separate Inhalte im Archiv hervorgehoben.

Vom PET 2001 bis zum Amiga – einige Systeme, die geblieben sind

Die Technikgeschichte hinter SSLXY ist mehr als nur eine Liste alter Gerätenamen. Jeder dieser Rechner steht für eine bestimmte Erfahrung, für eine andere Art zu arbeiten und für ein technisches Verständnis, das sich über viele Jahre aufgebaut hat.

Wichtig ist dabei: Die folgenden Systeme sollen gerade nicht den Eindruck erzeugen, sie seien irgendwann um 1996 gesammelt worden, um rückwirkend eine Geschichte zu dekorieren. Die Wurzeln dieser Technikbiografie reichen ab 1979 zurück. Ab 1983 wurde daraus ein kleiner praktischer Kreis. Im weiteren Umfeld waren das damals etwa 15 Jugendliche, mit einem festen Kern von 5. Die späteren Geräte und Archivstücke setzen darauf auf.

Mehr als Überblick steht auf der eigenen Chronikseite systems.htm. Die größere Gerätekarte mit weiteren Querverbindungen liegt auf hardware.htm.

Der harte Kern

Was später als Webarbeit sichtbar wurde, hatte seinen praktischen Ursprung schon deutlich früher. Ab 1983 gab es einen kleinen Kreis Gleichgesinnter. Nicht offiziell, nicht geschniegelt und meist ziemlich pragmatisch organisiert. Man traf sich, verglich Systeme, brachte Disketten mit, testete Programme, sprach über Erweiterungen und probierte immer wieder etwas aus.

Im weiteren Umfeld waren wir damals etwa 15 Jugendliche. Der kleine feste Kern bestand aus 5 – unser harter Kern, den wir intern halb ironisch die Beklopften nannten. Das war keine offizielle Gruppe und kein groß inszenierter Name, sondern eher der raue O-Ton dieser Zeit.

Dazu gehörte auch der Kontakt zu einem damaligen Computerladen, bei dem wir manche Teile oder Programme günstiger bekamen. Gelegentlich entstand das einfach daraus, dass wir normalen Kunden oder auch dem Laden selbst bei Hardware- und Softwareproblemen halfen. Gerade deshalb war dieser Kreis keine Pose, sondern praktisch gelebte Technik.

Zu dieser Zeit gehörte auch, dass wir Spielkonsolen und andere Geräte reparierten, darunter Atari, ColecoVision, Vectrex und Kassettenrekorder. Auch Video-2000- und Betamax-Geräte reparierten wir damals im Rahmen unserer Möglichkeiten, VHS eher seltener. So war das oft: nicht als festes System, sondern aus persönlichem Kontakt, technischem Wissen und gegenseitiger Unterstützung.

Dazu gehörten auch typische Bastellösungen aus der damaligen Zeit: In eine Schreibmaschine vom Typ Triumph-Adler Gabriele 8008 wurde selbst ein Interface eingebaut, um sie am C64 als Drucker zu nutzen. Auch erste Versuche mit selbstgebauten Akustikkopplern gehören in diese Zeit. Gerade solche Improvisationen waren prägend, weil man Technik nicht nur nutzte, sondern sie wirklich verstand und sich Schritt für Schritt aneignete. Natürlich ging auch vieles schief, und gerade aus diesen Fehlern lernte man oft am meisten.

Überall lagen Kabel, Handbücher, Ausdrucke, Diskettenboxen, Notizen, Schraubenzieher und auch mal ein Lötkolben, offene Geräte und oft auch Teile, deren Zweck nicht mehr sofort klar war. Genau diese Werkstattatmosphäre war wichtig. Technik wurde nicht nur benutzt, sondern verstanden, besprochen und in kleinen Schritten weitergedacht. Der kleine Kreis von damals kann sich nur noch selten persönlich treffen, weil das Leben die Wege längst in ganz unterschiedliche Richtungen geführt hat. Über das Netz besteht von Zeit zu Zeit aber noch immer Kontakt.

Zur frühen Funk- und Vernetzungsphase unseres Kreises gehört auch die eigene Seite Das 11-Meter-Band (CB-Funk). Dort geht es um die CB-Funk-Zeit zwischen den späten 1970ern und den 1980ern – also um Antennen, Funkgeräte, Slang, Packet Radio und die technische Brücke zwischen Funk und späterer Computervernetzung.

„Im weiteren Umfeld etwa 15 Jugendliche. Der kleine feste Kern: 5 – intern einfach die Beklopften.“

Dieses kleine Chaos war nicht sinnlos. Gerade daraus entstand Verständnis. Man lernte nicht nur, wie etwas startet, sondern auch warum es funktioniert. Man lernte, wie man Systeme organisiert, logisch aufbaut und im Problemfall wieder in Gang bringt. Wer solche Erfahrungen gemacht hat, schätzt saubere Strukturen später nicht aus Theorie, sondern aus Praxis.

• Technik nicht nur benutzen, sondern verstehen.
• Nicht nur speichern, sondern organisiert sichern.
• Nicht nur etwas zum Laufen bringen, sondern beherrschbar halten.
• Nicht auf Blendwerk setzen, sondern auf robuste Logik.

Für Werkstatt, Reparaturen und die ruhigere technische Haltung stehen die vertieften Seiten werkstatt.htm, interfaces.htm und philosophy.htm.

Zwei C65 – zum Verstehen, nicht zum Vorzeigen

Die beiden C65 kamen 1994 nicht als Sammelobjekte in mein Umfeld, sondern eher als technisches Rätsel. Ein Bekannter aus dem Commodore-Umfeld fragte mich damals, ob ich Interesse an zwei C65 hätte. Die Lage war zu dieser Zeit bereits angespannt, und ich hatte den Eindruck, dass es ihm weniger um eine übliche Weitergabe als vielmehr darum ging, die Geräte in verlässliche Hände zu geben.

Kurz darauf schickte er sie mir per Post. Vielleicht ist mein Blick darauf deshalb bis heute pragmatisch geblieben: Ich sehe darin keine Trophäen, sondern Systeme, die man einschaltet, vergleicht und in ihrer Architektur untersucht.

Aus technischer Sicht ist der C65 ein faszinierendes Übergangssystem. Man erkennt schnell den Versuch, die vertraute 8-Bit-Welt zu erweitern, ohne die Herkunft aus der Commodore-Linie völlig aufzugeben. Der CSG 4510 als weiterentwickelte CPU und der VIC-III (CSG 4567) verweisen deutlich auf einen Schritt über den klassischen C64 hinaus: höhere Auflösungen, mehr Farben, andere Registerlogik und insgesamt den Eindruck eines Systems, das bereits in eine neue Richtung dachte. Auch das integrierte 3,5-Zoll-Laufwerk folgt einer ganz anderen Ordnung als die bekannte externe 1541-Peripherie.

Ein besonders aufschlussreiches Detail ist das Netzteil. Äußerlich steckt es in einem Standard-C64-Gehäuse mit entsprechender Prägung, intern wurde die Schaltung jedoch für den Betrieb mit dem C65 angepasst. Gerade solche improvisierten Übergangslösungen sind für mich aufschlussreicher als jedes glatte Serienprodukt, weil sie den Entwicklungsprozess sichtbar machen. Man erkennt daran, wie Hardware unter Zeitdruck, mit vorhandenen Gehäusen und mit praktischen Anpassungen weitergedacht wurde.

Dass die komplette Begleitumgebung bis heute erhalten geblieben ist – also Kartons, Styropor, Folien und selbst die Schachteln der Netzteile –, sehe ich vor allem als Glücksfall für die Dokumentation. Für mich ist das keine Frage der Wertsteigerung, sondern eine seltene Möglichkeit, den ursprünglichen Auslieferungszustand eines Systems nachzuvollziehen, das so nie regulär im Massenmarkt ankam.

Im Moment nenne ich dabei bewusst nur eine Seriennummer öffentlich: 000213. Mir ging es bei solchen Rechnern nie darum, sie möglichst laut zu markieren. Spannender ist für mich die ruhige Analyse einer technischen Zwischenstufe, die an vielen Details zeigt, wohin Commodore hätte weitergehen können. Der C65 ist für mich deshalb vor allem eines: Hardware und Systemlogik zum Begreifen, nicht zum Vorzeigen.

„Nicht auf Seltenheit geschaut, sondern darauf, wie ein System tatsächlich gedacht war.“

Die eigene Tiefenseite dazu bleibt c65.htm. Das Netzteil-Thema hängt direkt mit power-supplies.htm zusammen.

C65: Die technische Brücke zwischen 8-Bit-Herkunft und neuer Systemlogik

Die beiden C65, die 1994 über einen Commodore-Kontakt zu mir kamen, sind für mich vor allem Zeugnisse einer unvollendeten Evolution. Wenn man das Gehäuse öffnet, sieht man eine Architektur, die den C64 nicht nur erweitern, sondern in mehreren Punkten deutlich überholen sollte. Im Zentrum steht dabei der CSG 4510, eine weiterentwickelte 65xx-CPU mit 3,54 MHz, zusätzlichen Bit-Operationen und einer verschiebbaren Zeropage. Gerade daran erkennt man gut, wie sehr der C65 noch aus der 8-Bit-Welt kommt und zugleich schon in eine andere Richtung weist.

Besonders aufschlussreich ist die Grafikeinheit CSG 4567 VIC-III. Während der C64 auf klar begrenzte Grafikmodi festgelegt war, arbeitet der VIC-III bereits mit einer deutlich erweiterten Register- und Grafiklogik, einschließlich Bitplane-Strukturen, hoher Auflösungen von bis zu 1280 × 400 Pixeln und einer Farbpalette von 256 aus 4096 Farben. Bemerkenswert ist dabei nicht nur die reine Leistungsfähigkeit, sondern auch die Tatsache, dass die Nähe zur älteren Commodore-Welt an mehreren Stellen erhalten bleibt. Gerade diese Mischung aus Vertrautem und Neuem macht den C65 technisch so interessant.

Auch die Peripherie-Logik wurde spürbar umgebaut. Der Wegfall des Datasette-Ports und die Hinzufügung des Fast-Disk-Ports für das 3,5-Zoll-Laufwerk markieren einen klaren Bruch mit der Kassetten-Ära. Für den Techniker ebenfalls interessant: Der Userport liefert keine 9V-Wechselspannung mehr, was die Kompatibilität zu älteren Erweiterungen einschränkt, während der Expansionsport auf 50 Pins erweitert wurde. Genau solche Details zeigen, dass der C65 nicht bloß ein größerer C64 sein sollte, sondern ein eigenständiger Schritt in eine neue Systemordnung.

Ein fast beiläufiges Detail unterstreicht den Prototypen-Status zusätzlich: Das Netzteil sitzt in einem gewöhnlichen C64-Gehäuse, wurde intern aber für die spezifischen Anforderungen des C65 angepasst. Es sind genau diese unscheinbaren Übergangslösungen, die für mich besonders viel aussagen, weil sie sichtbar machen, wie Hardware-Entwicklung in der Realität oft tatsächlich aussieht: pragmatisch, lösungsorientiert und häufig unter Verwendung bereits vorhandener Gehäuseformen und Bauteile.

Dass heute noch die gesamte Begleitumgebung – vom Styropor bis zur Netzteilschachtel – erhalten ist, erlaubt einen ungewöhnlich unverfälschten Blick auf dieses System. Für mich bleibt der C65, speziell die öffentlich genannte Einheit 000213, kein Schaustück, sondern ein Objekt zum Verstehen, zum Prüfen der Register-Logik und zum Nachvollziehen einer technischen Vision, die kurz vor dem Ziel gestoppt wurde.

„Gerade die unfertigen Übergänge erzählen oft mehr über Technik als das fertige Serienprodukt.“

Der Amiga 1000 – Architektur-Studie und Instandsetzung

Meinen Amiga 1000 habe ich nicht als Ausstellungsstück erworben, sondern als defektes System von einem Bekannten übernommen. Für mich war das Ziel nie der Besitz eines frühen Meilensteins, sondern die technische Herausforderung, die erste Amiga-Generation in ihrer ursprünglichen Form zu begreifen und wieder funktionsfähig zu machen. Wer ein System repariert, lernt die Logik der Platine meist besser kennen als jeder reine Anwender.

Technisch ist der A1000 vor allem wegen seines Writable Control Store (WCS) besonders interessant. Da Kickstart noch nicht fest in ein klassisches ROM gegossen war, muss das System über eine Bootstrap-Diskette in einen speziellen 256-kB-Speicher geladen werden. Gerade dieser Startvorgang macht sichtbar, wie experimentell und offen die frühe Amiga-Phase noch war. Beim Öffnen des Gehäuses stößt man zudem auf die eingravierten Unterschriften der Entwickler um Jay Miner – ein Detail, das die enge Verbindung zwischen Hardware-Layout und persönlicher Handschrift bis heute spürbar macht.

Besonders faszinierend bleibt die dezentrale Architektur. Während viele andere Systeme der Zeit die Haupt-CPU mit Grafik- und Soundaufgaben zusätzlich belasteten, verteilt der Amiga die Arbeit auf eigene Bausteine wie Denise für die Grafik und Paula für Audio und Floppy-Logik. Auch die sogenannte Tastatur-Garage unter dem Gehäuse und das frühe Amiga-Häkchen-Logo gehören für mich zu diesen funktionalen Entscheidungen, die den Rechner aus der Masse der damaligen Heimcomputer herausheben.

Der A1000 ist für mich deshalb weit mehr als nur das erste Amiga-Modell. Er ist ein System zum Arbeiten, zum Verstehen der frühen OCS-Logik und ein Beleg dafür, dass gute Technik auch nach Jahrzehnten durch gezielte Wartung wieder in einen nachvollziehbaren, brauchbaren Zustand gebracht werden kann. Gerade als Defektgerät war er aufschlussreich, weil bei der Instandsetzung nicht der Mythos zählt, sondern die reale Struktur der Platine.

„Gekauft als Defektgerät, repariert aus Neugier – Hardware-Verständnis beginnt auf der Platine.“

Der Amiga 2000 mit A2386SX-25 – Amiga und 386SX-PC in einem Gehäuse

Der Amiga 2000 war für mich nie ein Gerät, das über irgendeinen emotionalen Nimbus funktionierte. Er war eher die sachliche Antwort auf die Frage nach einem erweiterbaren Arbeitssystem. Während die kleineren Modelle stärker auf den Wohnzimmertisch zielten, wirkte der A2000 von Anfang an nüchterner, technischer und deutlich offener für ernsthafte Erweiterungen.

In diesem Gerät steckt ein Commodore A2386SX-25 Bridgeboard. Damit ist der Rechner nicht nur ein klassischer Big-Box-Amiga, sondern zugleich ein PC-kompatibles 386SX-System mit 25 MHz im selben Gehäuse. Gerade diese Kombination macht den A2000 für mich so interessant: eine Amiga-Arbeitsmaschine und eine DOS-/PC-Seite, technisch getrennt und doch in einem gemeinsamen Systemrahmen.

Dazu kommen ein 3,5-Zoll-Floppy, ein 5,25-Zoll-Floppy und getrennte Festplatten für beide Welten. Die Amiga-Seite und die PC-Seite waren damit nicht nur theoretisch nebeneinander vorhanden, sondern praktisch nutzbar. Das ist keine bloße Retro-Spielerei, sondern ein sehr deutliches Beispiel für die Übergangszeit zwischen Amiga, DOS-PC, Datenträgerpraxis und ernsthafter Mehrsystem-Nutzung.

Aus technischer Sicht beeindruckt beim A2000 vor allem die klare Bus- und Erweiterungslogik. Mit seinen Zorro-II-Slots und AutoConfig bot er für die Zeit eine bemerkenswert komfortable Erweiterungsstruktur. Dazu kamen der Video-Slot und die ISA-Slots, die im Zusammenspiel mit Bridgeboards ihre eigentliche Bedeutung bekamen. Genau dadurch wurde der A2000 zur Plattform: nicht geschlossen, nicht verspielt, sondern offen genug, um verschiedene Rechnerwelten in einem Gehäuse zusammenzubringen.

Auch die Rückseite des Gehäuses zeigt diese Haltung sehr deutlich: serielle und parallele Schnittstellen, externer Floppy-Anschluss, getrennte Audio-Ausgänge, Kaltgeräteanschluss, Netzschalter, Lüftergitter und Typenschild. Das ist keine Dekoration, sondern eine technische Oberfläche. Gerade das passt zum A2000: Er wirkt weniger wie ein Heimcomputer für den schnellen Einsatz am Fernseher, sondern eher wie ein Arbeitsplatzrechner, den man öffnet, erweitert, prüft und dauerhaft betreibt.

Technik wie der A2000 macht deutlich, dass man Systemen nicht ausgeliefert sein muss. Die Zugänglichkeit des Innenaufbaus und die klare Struktur der Komponenten erlaubten es, Erweiterungen und Probleme nicht nur hinzunehmen, sondern wirklich zu verstehen. Genau darin lag für mich seine Glaubwürdigkeit: kein gefälliges Auftreten, sondern Substanz, Ordnung und die Freiheit, ein System nach eigenen Anforderungen umzubauen.

„Der A2000 mit A2386SX-25 ist keine einfache Retro-Maschine, sondern Amiga und 386SX-PC als sauber trennbares Doppel-System.“

Die eigene Detailseite dazu liegt künftig auf amiga-2000.htm. Der Schnittstellenbezug passt zusätzlich zu interfaces.htm, die Systemübersicht zu systems.htm.

Der Amiga 500 – Redundanz und Entlastung für das Hauptsystem

Den Amiga 500 habe ich mir ursprünglich als Zweitgerät zu meinem A2000 angeschafft. Die Logik dahinter war rein pragmatisch: Das größere Desktop-System für ernsthafte Arbeiten und umfangreichere Erweiterungen schonen, während der A500 als belastbares Alltagsgerät diente – zum direkten Arbeiten, zum Testen und natürlich auch für Spiele. Während der A2000 stärker die Erweiterbarkeit im Fokus hatte, war der A500 die kompakte, technisch nahe verwandte Lösung für den unmittelbaren Zugriff.

Architektonisch basiert der A500 auf derselben soliden Grundlage: einer Motorola-68000-CPU mit 7,09 MHz im PAL-Betrieb und dem bewährten OCS-Chipsatz. Was ihn auszeichnete, war die Konzentration auf das Wesentliche im kompakten Wedge-Gehäuse. Besonders der Trapdoor-Slot an der Unterseite war eine praktische Lösung für schnelle Speichererweiterungen, meist über eine A501 oder vergleichbare Erweiterung. In der Praxis bedeutete das oft mehr Arbeitsruhe und ein spürbar entspannteres System, auch wenn dieser Zusatzspeicher je nach Ausbau nicht einfach vollständig als Chip-RAM lief.

Trotz seiner Ausrichtung auf den Heimbereich blieb der A500 ein ernsthaftes System. Über den seitlichen Erweiterungsanschluss ließ sich der Rechner um Festplattenlösungen, zusätzliches Fast RAM oder andere Hardware ergänzen. Gerade das machte ihn für mich interessant: nicht nur als Spielerechner, sondern als zuverlässige Reserve neben dem Hauptsystem. Während der A2000 das ausbaufähigere Zentrum war, konnte der A500 vieles auffangen, ohne dass man den großen Rechner für jede Kleinigkeit beanspruchen musste.

Spiele waren auf dem Amiga 500 für mich nie nur Zeitvertreib. Sie zeigten sehr deutlich, was saubere Programmierung und gut abgestimmte Hardware leisten konnten. Kickstart lag beim A500 bereits im ROM; von Diskette kamen dann Workbench, Spiele oder andere Programme. Gerade diese direkte, klare Arbeitsweise hat mein Verständnis von effizientem Code geprägt: ein System einschalten, Diskette einlegen, arbeiten oder spielen – ohne unnötigen Umweg, ohne künstliche Schwere.

Auch deshalb war der A500 für mich mehr als nur ein kleiner Bruder des A2000. Er war Redundanz, Entlastung und zugleich ein Beispiel dafür, wie viel technische Qualität in einem kompakten System stecken kann. Der Rechner wirkte einfacher, war aber alles andere als banal. Gerade in dieser Mischung aus Zugänglichkeit, Klarheit und robuster Alltagstauglichkeit lag seine Stärke.

„Der A500 war die Versicherung für meinen A2000 – und der Beweis, dass Direktheit und technische Qualität zusammengehören.“

Der Amiga 4000 Tower – ein frühes System aus der letzten Commodore-Zeit

Ein besonderer Punkt war mein Amiga 4000 Tower Anfang 1994. Es handelte sich dabei nicht um einen späteren Nachbau, sondern um ein originales Commodore-Gerät mit der Seriennummer #0000098.

Für mich lag der Reiz in der inneren Substanz. Im Rechner arbeitet ein Motorola 68040 mit 25 MHz auf der legendären A3640-Prozessorkarte. Dazu kommen der AGA-Chipsatz mit Alice, Lisa und Paula, Super Buster 11, Ramsey 7 sowie der integrierte NCR-53C710-SCSI-2-Controller. Solche Details sieht man von außen nicht, aber sie sagen viel darüber aus, wie ernsthaft und klar diese Maschine aufgebaut war.

Auch die Grundarchitektur war stark: 2 MB Chip-RAM, 16 MB Fast-RAM auf dem Mainboard, eine Lithiumbatterie sowie zwei 1,76-MB-Floppy-Laufwerke. Dazu kamen der interne gepufferte IDE-Anschluss, der Fast-SCSI-2-Betrieb über den integrierten Controller und der interne 50-polige SCSI-Bus. Für meine zwei SyQuest-Wechsellaufwerke war das keine Spielerei, sondern eine sehr praktische und sauber organisierte Arbeitsumgebung.

Das eigentliche Tower-Potenzial lag aber im Ausbau: fünf Zorro-III-Steckplätze, zwei Videoslots, vier ISA-Slots und der CPU-Slot. Ein solches System wirkte nicht wie ein geschlossenes Gerät, sondern wie eine Plattform, die ernsthafte Erweiterungen und geordnetes Arbeiten von Anfang an mitdachte.

Der Gedanke dahinter war einfach. System und Daten nicht unnötig vermischen. Medien so organisieren, dass man im Problemfall schnell weiterarbeiten kann. Wenn eine Platte ausfiel, kam die nächste Wechselplatte hinein – und es ging weiter.

Genau solche Erfahrungen prägen den Blick auf Software und Webentwicklung bis heute. Wer einmal gelernt hat, Systeme bewusst aufzubauen, achtet später auch bei Code automatisch auf Struktur, Wartbarkeit und eine saubere technische Basis.

„Es ging nie nur um Seltenheit, sondern immer um die technische Klarheit eines Systems.“

Die große Einzelseite dazu bleibt amiga4000t.htm. Die Wechselmedien-Seite dazu liegt auf syquest.htm.

Vom Amiga zum PC – kein Bruch, eher ein leiser Übergang

Der Wechsel vom Amiga 4000 Tower auf ein PC-System entstand bei mir nicht aus einer bewussten Entscheidung für eine neue Plattform, sondern eher aus einer stillen Verschiebung der praktischen Realität.

Der A4000T war technisch sauber aufgebaut, nachvollziehbar und in sich stimmig. Erweiterungen, Massenspeicher, Systemstruktur – alles war geordnet und beherrschbar. Genau das entsprach meinem Verständnis von einem guten Rechner.

Mit der Zeit wurde jedoch weniger die Hardware selbst zum Problem als vielmehr das Umfeld. Software war schwerer verfügbar, der Datenaustausch wurde komplizierter und viele Werkzeuge verlagerten sich auf Systeme, die breiter eingesetzt wurden. Irgendwann war nicht mehr entscheidend, welches System technisch überzeugender war, sondern auf welchem System sich Arbeit im Alltag überhaupt noch sinnvoll fortsetzen ließ.

Der erste Windows-PC, auf dem dieser Übergang für mich konkret wurde, war ein Sony VAIO PCV-R702. Gerade an so einem Gerät zeigte sich der Wechsel sehr deutlich: weg von der vertrauten Amiga-Welt, hin zu einem System, das weniger über technische Eleganz überzeugte als über seine praktische Einbindung in die damals verfügbare Software- und Arbeitsumgebung.

Der PC mit Windows war dabei keine bewusste Hinwendung zu etwas vermeintlich Modernerem, sondern schlicht die Plattform, auf der sich die Dinge weiterentwickelten. Treiber, Programme, Schnittstellen und Austausch waren dort vorhanden – nicht unbedingt eleganter, aber verfügbar.

Apple spielte in diesem Zusammenhang für mich keine große Rolle. Die Systeme wirkten auf mich geschlossener und weniger auf die Art von Offenheit ausgelegt, bei der man ein Gerät in gleicher Weise zerlegt, erweitert und im Detail nachvollzieht, wie ich es vom Amiga gewohnt war. Für meinen Ansatz war deshalb weniger das Image entscheidend als die Frage, ob ein System offen genug bleibt, um verstanden zu werden.

So entstand der Wechsel nicht als ideologischer Bruch, sondern als leiser Übergang: vom Amiga als klar strukturierter Arbeitsmaschine hin zu einem PC, der vor allem deshalb genutzt wurde, weil sich auf ihm die Arbeit praktisch fortsetzen ließ.

Die ausführlichere Einzelseite dazu bleibt pcshift.htm.

Videotechnik – nicht nur Rechner, sondern auch Bandmaschinen

Technik beschränkte sich für mich nie nur auf Computer. Auch bei Videogeräten interessierten mich nicht bloß Bedienung oder Markennamen, sondern Aufbau, Mechanik, Signalführung und die Frage, wie sauber ein System tatsächlich konstruiert war. Gerade im Bereich analoger Aufzeichnung zeigte sich sehr schnell, ob ein Gerät nur für den Alltag gedacht war oder ob es technisch wirklich Substanz besaß.

Einige dieser Geräte sind bis heute noch vorhanden, darunter ein Sony SL-HF950 ES, ein Sony SL-HF100 ES sowie ein Sony SL-8000E. Gerade diese Spannweite ist für mich interessant, weil sie nicht nur einzelne Modelle zeigt, sondern auch eine Entwicklungslinie: von frühen Betamax-Geräten hin zu späteren, technisch aufwendigeren und hochwertiger ausgeführten Maschinen.

Solche Recorder waren für mich nie bloß Unterhaltungselektronik. Entscheidend waren vielmehr Transportmechanik, Kopfträger, Signalweg, Bedienlogik und die Frage, wie gut sich ein Gerät warten, vergleichen und im Zweifel auch wieder instand setzen ließ. Genau in diesem Punkt ähneln sie meiner Haltung zu Rechnern: Nicht der bloße Besitz zählt, sondern ob ein System nachvollziehbar gebaut ist und sich wirklich verstehen lässt.

Auch deshalb gehören diese Videogeräte für mich in dieselbe technische Biografie wie PET, C64, Amiga oder später der erste Windows-PC. Es sind unterschiedliche Welten, aber derselbe Blick: Dinge ansehen, vergleichen, erhalten und in ihrer Konstruktion ernst nehmen.

„Nicht nur Rechner, auch Videotechnik war für mich immer etwas zum Verstehen.“

Die reine Videoseite bleibt video.htm. Der Werkstattbezug dazu liegt auf werkstatt.htm.

Die Dell Precision M50 – Arbeitsgerät statt Wegwerfware

Ein System muss kein Wegwerfartikel sein. Ein gutes Beispiel dafür bootet bis heute zuverlässig sein originales Windows XP Professional: meine Dell Precision M50 Workstation aus dem Jahr 2002 in konkreter Vollausstattung.

Diese Maschine war auf ernsthafte Arbeit ausgelegt: robust, modular, schwer und ehrlich. Mobile Intel Pentium 4-M mit 2,2 GHz, 2 GB RAM, ein UXGA-Display mit 1600 × 1200 Pixeln, NVIDIA Quadro4 500 GoGL, 60-GB-IDE-Festplatte, Media Bay und eine Anschlussvielfalt, für die man heute oft mehrere Adapter bräuchte.

• Prozessor & Haltung: kein ultradünnes Modegerät, sondern eine mobile Workstation mit echtem Arbeitsanspruch.
• Display: 15 Zoll UXGA, 1600 × 1200 Pixel – viel Fläche für Programmierung, parallele Fenster und längere Sitzungen.
• Grafik: NVIDIA Quadro4 500 GoGL – professionelle Ausrichtung statt bloßer Standarddarstellung.
• Media Bay: CD/DVD, Diskettenlaufwerk, ZIP-Drive, zweites Festplattenmodul oder zweiter Akku.
• Anschlüsse: Ethernet, Modem, PCMCIA, VGA, S-Video, FireWire, Infrarot, PS/2, seriell, parallel, USB.
• Betriebssystem: Windows XP Professional – bis heute auf genau diesem Gerät funktionsfähig.

Gerade deshalb passt die M50 gut in diese Geschichte. Sie steht für denselben Grundgedanken wie der Amiga-Tower mit seinen SyQuest-Wechsellaufwerken: Technik muss nicht modisch sein, sondern nachvollziehbar, belastbar und im Alltag brauchbar.

Solche Geräte wirken heute fast wie technische Zeitkapseln. Aber sie sind mehr als Nostalgie. Sie zeigen eine Bauweise, die professionelle Nutzer ernst nahm: Anschlussvielfalt, Erweiterbarkeit und Nutzbarkeit. Genau das wirkt bis heute überzeugend.

„Kein Wegwerfgerät, sondern ein Arbeitsrechner, der seinen Zweck bis heute erfüllt.“

Die M50 als Einzelseite bleibt m50.htm.

Heute: Dell Pro Max 16 Plus, aber im Grunde dieselbe Haltung

Die Werkzeuge haben sich geändert, aber die Grundhaltung ist geblieben. Heute schreibe ich Code nicht mehr auf einem Tower, sondern auf einem Dell Pro Max 16 Plus. Was sich jedoch nicht verändert hat, ist die Vorliebe für Klarheit, Ruhe und das Weglassen von Überflüssigem.

• Handgeschriebenes HTML5 & CSS3: kein Baukasten, kein unnötiger Überbau, keine künstliche Komplexität.
• Vanilla JavaScript: nur dort eingesetzt, wo es für Funktionalität, Bedienung oder Barrierefreiheit wirklich sinnvoll ist.
• Performance First: Seiten sollen leicht, ruhig und schnell bleiben.
• Statische Lösungen: was nicht dynamisch berechnet werden muss, erzeugt auch keine unnötige Angriffsfläche.
• Wartbarkeit: eine gute Lösung ist auch später noch lesbar, pflegbar und nachvollziehbar.
• Heutige Werkzeuge: KI-Modelle und Cloud-Dienste werden praktisch geprüft – nicht nach Hype, sondern nach Nutzen, Grenzen und Alltagstauglichkeit.

Handgeschriebener Code ist für mich kein Selbstzweck. Er ist eher die logische Folge einer langen Rechnergeschichte. Wer früh gelernt hat, mit begrenzten Ressourcen und echter Verantwortung für das Funktionieren eines Systems umzugehen, entwickelt fast automatisch ein Bedürfnis nach Klarheit und technischer Ehrlichkeit.

Das gilt für mich inzwischen auch bei aktuellen Werkzeugen. KI-Modelle und Cloud-Dienste werden nicht ehrfürchtig behandelt und auch nicht pauschal abgelehnt. Sie werden ausprobiert, gegeneinander gehalten, in ihren Grenzen beobachtet und nur dann ernst genommen, wenn sie im realen Einsatz tatsächlich etwas tragen. Genau deshalb interessiert mich dort weniger der Werbeton als die praktische Frage: Was hilft wirklich, wo liegen die Brüche und was erzeugt am Ende nur neuen Ballast?

Dasselbe gilt für Webseiten insgesamt. Technische Sichtbarkeit und saubere Auffindbarkeit sind wichtig. Aber eine gute Platzierung nützt nichts, wenn der Besucher danach enttäuscht ist. Eine Seite ist erst dann wirklich brauchbar, wenn sie nicht nur gefunden wird, sondern die Informationen darauf auch klar, ehrlich und im Alltag nützlich sind.

Was aus dieser Zeit geblieben ist

Genau darum entstehen meine Lösungen bewusst schlank. Kein unnötiger Überbau, keine laut wirkenden Konstruktionen, nur weil etwas modern aussehen soll. Lieber verständliche HTML-Strukturen, sauberes CSS, gezieltes JavaScript und eine technische Handschrift, die auf Verlässlichkeit setzt.

Was am Ende sichtbar bleibt, ist meist nur die Oberfläche. Was darunter trägt, ist Struktur. Und genau diese Struktur soll nicht nur heute funktionieren, sondern auch später noch nachvollziehbar bleiben.

„Gute Struktur fällt im besten Fall gar nicht besonders auf. Sie sorgt nur dafür, dass Dinge funktionieren.“

Die ausführlichere Haltungsseite dazu bleibt philosophy.htm.