sslxy

Die Geschichte hinter dem Code

Seit 1996 werden Webauftritte mit einer einfachen technischen Grundhaltung begleitet: 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 und bildet einen wesentlichen Teil der Webgeschichte, die sslxy.de dokumentiert.

Die zeitliche Trennung ist dabei wesentlich. Erste eigene Webarbeiten und Webseiten entstanden bereits 1994/95; 1996 markiert den Beginn der kontinuierlichen Webarbeit, wie sie auf sslxy.de als langfristige Webspur dokumentiert wird. Die technische Geschichte dahinter beginnt deutlich 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 damals etwa 15 Jugendliche beteiligt. Der kleine feste Kern bestand aus 5 – intern halb ironisch die Beklopften genannt. 1994 kamen Übergangssysteme wie die beiden C65 in greifbare Nähe. In diese Phase fallen auch die ersten eigenen Webseiten; Ende 1995 war ein früher Stand der Website des Goldenen Ochsen im Netz.

Webseiten wurden dabei nicht ständig neu erfunden, sondern über viele Jahre hinweg ruhig weiterentwickelt – Schritt für Schritt. Große Redesigns waren nie Selbstzweck. Entscheidend blieb, dass eine Struktur nachvollziehbar, technisch sauber und auch nach späteren Änderungen noch beherrschbar war.

Diese Entwicklung ist keine Agenturgeschichte und keine Erzählung über Software-Architektur als Berufsbild. Sie beschreibt praktische Webarbeit, deren erste eigene Seiten bereits 1994/95 entstanden und die sich ab 1996 kontinuierlich fortsetzte. Ihre technische Denkweise war schon viele Jahre zuvor durch Rechner, Hardware, Datenträger, Werkstattpraxis und Kommunikationssysteme geprägt worden.

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 werden auch kostenpflichtige Varianten einbezogen, wenn sich nur so sinnvoll beurteilen lässt, was ein Werkzeug tatsächlich kann.

PET, VC 20, C64, Amiga und andere ältere Systeme bilden heute vor allem ein privates Technik- und Archivthema. Aus dieser langen technischen Linie ist jedoch eine Vorliebe für Ordnung, Ruhe und technische Klarheit geblieben. Systeme sollen nachvollziehbar bleiben und nicht allein durch zusätzliche Schichten komplexer werden.

sslxy ist ein privates Technikarchiv und wird neben einem beruflichen Alltag in einem völlig anderen Bereich gepflegt. Auch außerhalb des Archivs gibt es andere praktische und technische Aufgaben. Deshalb entstehen Gerätefotos, Innenaufnahmen und genaue Bestandsaufnahmen Schritt für Schritt und nicht nach einem festen Veröffentlichungsplan. Gründlichkeit und ein schonender Umgang mit der erhaltenen Technik gehen dabei vor Geschwindigkeit.

Gut erhaltene Technik zeigt, dass Dinge auch nach Jahrzehnten noch funktionieren können, wenn Aufbau, Wartung und Nutzung stimmen. Für den Webbereich lässt sich dieselbe Haltung übertragen: guter Code ähnelt einem sauber aufgeräumten Werkzeugkasten – nicht spektakulär um seiner selbst willen, sondern übersichtlich, verlässlich und auch später wieder verständlich.

Langjährige Webbegleitung: Hotel Goldener Ochsen in Göppingen-Hohenstaufen

Zur dokumentierten Webgeschichte gehört die Website des Hotel Goldener Ochsen in Göppingen-Hohenstaufen. Sie zählt zu den besonders langjährig technisch begleiteten Webauftritten und macht über einen langen Zeitraum sichtbar, wie sich Anforderungen an statische Websites, Browser, mobile Darstellung, Sicherheit, strukturierte Daten, Performance und Suchmaschinen verändert haben.

Die technische Unterstützung dieser Website erfolgt unentgeltlich und aus freundschaftlicher Verbundenheit. Der Bezug wird auf sslxy.de deshalb als Teil der technischen Webgeschichte dokumentiert, nicht als Referenzkunde, Agenturprojekt oder kommerzielles Leistungsangebot.

Gerade die lange Laufzeit ist technisch interessant. Eine Website, die über Jahrzehnte weiterentwickelt wird, stellt andere Anforderungen als ein kurzfristiger Demonstrationsauftritt: bestehende Pfade müssen verständlich bleiben, alte Inhalte dürfen nicht unkontrolliert brechen, neue Standards müssen in eine gewachsene Struktur integriert werden und jede Modernisierung muss sich daran messen lassen, ob sie langfristig wartbar bleibt.

„Langfristige Webtechnik zeigt ihre Qualität nicht beim ersten Aufruf, sondern nach Jahren der Pflege.“

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. Ausgangspunkt war schlicht eine praktische technische Notwendigkeit.

Ausgangspunkt war eine der ersten selbst programmierten Websites 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.

Es gab keine offizielle Schulung, aber viele praktische Eindrücke. Menschen aus großen Betrieben, aus Medizin, Werkstatt, Verwaltung, Netzbetrieb, Fahrzeugtechnik oder Fernmeldelogik erzählten beiläufig von Störungen, erklärten Geräte oder brachten eine bestimmte Sicht auf Ordnung, Erreichbarkeit und Belastbarkeit mit. In einem Umfeld, das ohnehin stark von Rechnern, Funk, Modems und Schnittstellen geprägt war, blieb von solchen Gesprächen viel technisches Denken hängen.

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.

Für die technische Einordnung ist nicht entscheidend, welcher einzelne Arbeitgeber, welche Familienlinie oder welcher exakte Ort hinter einer bestimmten Erfahrung stand. Aussagekräftiger ist die Summe aus Industrie, Werkstatt, Medizin, Betrieb, Netzen und Fernmeldelogik im Großraum Stuttgart. Diese Umgebung erklärt, warum Stabilität, Zuständigkeiten, Signalwege und Wartbarkeit im Archiv immer wieder wichtiger erscheinen als technische Mode.

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

Themenübersicht

Diese Seite ist die ausführliche Hauptübersicht des Archivs. Die tieferen Einzelthemen liegen zusätzlich auf eigenen Dateien. So bleibt https://sslxy.de/ die zentrale Hauptkarte, während Geräte-, Haltungs-, Web-, DFÜ- und Archivthemen auf die passenden Unterseiten verteilt sind.

Mehrere Querschnittsseiten verbinden inzwischen Themen, die zuvor nur über einzelne Geräte oder Zeitabschnitte verteilt waren. Dazu gehören die Entwicklung von DOS und Windows auf der PC-Plattform, E-Mail und Mailprotokolle, Dateisysteme und Datenträger, Programmierung und Skripting, Prozessoren und Rechnerarchitekturen, Arbeitsspeicher, ROM und Speichererweiterungen, Emulation und digitaler Erhalt, Dateitransfer und Dateiaustausch sowie Domains, DNS und Webhosting. Ergänzend vertiefen eigene Seiten die dokumentierte Reparaturhaltung, LaserVision und das Tefifon als besondere historische Medientechniken sowie Atari- und CPC-Heimcomputer als eigenständige Rechnerarchitekturen. Die Übersicht bleibt dadurch bewusst eine zentrale Karte und kein Ersatz für die ausführlichen Einzeldokumentationen.

Die Themen sind bewusst gruppiert: Die Startseite gibt den Überblick, die verlinkten Unterseiten führen einzelne Geräte, Plattformen und technische Entwicklungen ausführlicher weiter.

Eigener Bestand, Bekanntenkreis und praktische Vergleichssysteme

Die Technikgeschichte hinter SSLXY ist mehr als eine Liste alter Gerätenamen. Wichtig ist die Trennung zwischen eigenen Arbeitsrechnern, Geräten aus dem engen Freundes- und Bekanntenkreis sowie Systemen, die beim Reparieren, Vergleichen oder gemeinsamen Experimentieren praktisch kennengelernt wurden.

Nicht jede interessante Plattform musste deshalb selbst gekauft werden. Geld und Zeit waren schon damals nicht unbegrenzt. Über mehrere gute Bekannte bestand trotzdem über längere Zeit praktischer Zugang zu anderen Rechnerwelten. Genau diese Mischung aus Eigenbestand und gemeinsam genutzter Technik erklärt, warum im Archiv auch Systeme auftauchen, die nie dauerhaft zum persönlichen Bestand gehörten.

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

Die technische Denkweise und praktische Erfahrung, die später auch die Webarbeit prägten, entstanden 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 damals etwa 15 Jugendliche beteiligt. Der kleine feste Kern bestand aus 5 – der harte Kern, intern halb ironisch die Beklopften genannt. 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 manche Teile oder Programme günstiger erhältlich waren. Das ergab sich gelegentlich daraus, dass Mitglieder des Kreises 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 die Reparatur von Spielkonsolen und anderen Geräten, darunter Atari, ColecoVision, Vectrex und Kassettenrekorder. Über mehrere gute Bekannte kamen außerdem Atari-Heimcomputer und später Atari-ST-Systeme praktisch ins Blickfeld; ähnlich war es bei Schneider CPC 464, 664 und 6128. Auch Video-2000- und Betamax-Geräte wurden damals im Rahmen der Möglichkeiten repariert, VHS eher seltener. Das geschah 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 dieses 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 Anfang 1994 nicht als Sammelobjekte in den technischen Bestand, sondern eher als technisches Rätsel. Ein Bekannter aus dem Commodore-Umfeld fragte damals, ob Interesse an zwei C65 bestünde. Die Lage war zu dieser Zeit bereits angespannt; der Eindruck war, dass es weniger um eine übliche Weitergabe als vielmehr darum ging, die Geräte in verlässliche Hände zu geben.

Kurz darauf wurden die Geräte per Post geschickt. Der Blick darauf blieb deshalb bis heute pragmatisch: keine Trophäen, sondern Systeme, die sich einschalten, vergleichen und in ihrer Architektur untersuchen lassen.

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 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 –, ist vor allem ein Glücksfall für die Dokumentation. Entscheidend ist nicht die Wertsteigerung, sondern die seltene Möglichkeit, den ursprünglichen Auslieferungszustand eines Systems nachzuvollziehen, das so nie regulär im Massenmarkt ankam.

Öffentlich genannt wird dabei weiterhin nur eine Seriennummer: 000213. Bei solchen Rechnern geht es nicht darum, sie möglichst laut zu markieren. Spannender ist die ruhige Analyse einer technischen Zwischenstufe, die an vielen Details zeigt, wohin Commodore hätte weitergehen können. Der C65 steht deshalb vor allem für 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 in den technischen Bestand kamen, sind 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 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. Der C65, speziell die öffentlich genannte Einheit 000213, bleibt 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

Der Amiga 1000 kam Ende 1986 als defektes System von einem Bekannten in das technische Umfeld. Er wurde nicht wegen eines späteren Sammlerstatus übernommen, sondern weil Reparatur und die damals ungewöhnliche Architektur interessant waren. Ziel war, 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 zu diesen funktionalen Entscheidungen, die den Rechner aus der Masse der damaligen Heimcomputer herausheben.

Der A1000 ist 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 in dieser technischen Linie 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 technisch 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 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 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

Der Amiga 500 wurde 1987 als Zweitgerät zum A2000 gekauft. 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 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 in dieser technischen Betrachtung 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 prägte später auch das Verständnis von effizientem Code: ein System einschalten, Diskette einlegen, arbeiten oder spielen – ohne unnötigen Umweg, ohne künstliche Schwere.

Auch deshalb war der A500 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 Reserve neben dem 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 der Amiga 4000 Tower, der Anfang April 1994 in den Bestand kam. Es handelte sich dabei nicht um einen späteren Nachbau, sondern um ein originales Commodore-Gerät mit der Seriennummer #0000098.

Der Reiz lag 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 die zwei eingesetzten 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 – zuerst Experimente, später reguläre Arbeitsrechner

Der Übergang zur PC-Welt begann nicht mit einem einzelnen gekauften Windows-Rechner. Parallel zur Amiga-Zeit wurden im technischen Freundeskreis immer wieder PCs aus vorhandenen Teilen aufgebaut: 386-, 486- und später Pentium-Systeme, häufig aus Komponenten nicht mehr sinnvoll reparierbarer Komplettrechner oder aus zusammengetragenen Einzelteilen.

Diese Maschinen waren keine persönlichen Haupt-PCs. Sie waren Versuchssysteme: Hardware zusammenstellen, Komponenten kombinieren, Fehler suchen, DOS und Windows ausprobieren und sehen, was aus vorhandenen Teilen noch herauszuholen war. Darauf liefen überwiegend DOS, Windows 3.x, Windows 95 und Windows 98. Manche Aufbauten waren schneller als damalige fertige PCs, aber nicht immer in einem Zustand, den man heute als berührungssicher oder alltagstauglich bezeichnen würde.

Dadurch war die PC-Welt lange vor einem späteren Markenrechner praktisch bekannt. Gleichzeitig blieb der Amiga die eigene Arbeitsplattform. Die Trennung zwischen Experimentiersystem und persönlichem Arbeitsrechner ist für die Chronik deshalb wichtig.

2002 wurde die Dell Precision M50 gekauft. Sie war ein regulärer Windows-XP-Arbeitsrechner und liegt zeitlich vor dem späteren Sony-Desktop. Im Herbst 2004 kam dann ein Sony VAIO PCV-RS704 als Build-to-Order-System im Vollausbau hinzu.

Der VAIO war damit weder der erste Kontakt mit PCs noch der erste eigene Windows-Rechner. Seine Rolle liegt anders: Er dokumentiert einen bewusst vollständig ausgestatteten Desktop-PC der damaligen Arbeitsphase. Die ausführliche Übergangsseite liegt auf pcshift.htm, die Geräteakte auf vaio.htm.

Videotechnik – nicht nur Rechner, sondern auch Bandmaschinen

Die technische Beschäftigung beschränkte sich nie nur auf Computer. Auch bei Videogeräten standen nicht bloß Bedienung oder Markennamen im Vordergrund, 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 vorhanden. Neben Sony SL-HF950 ES, SL-HF100 ES und SL-8000E gehören dazu auch der Sony EV-S1000E von Ende 1989 oder 1990, der Sony EV-S9000E von Ende 1992/Anfang 1993, der Sony DHR-1000VC von Ende 1997, der Colour Video Printer CVP-M1E und der ab Ende 2005 genutzte DPP-EX50. EV-S1000E, EV-S9000E, DHR-1000VC, CVP-M1E und DPP-EX50 sind weiterhin vorhanden und funktionsfähig.

Dadurch lässt sich eine zweite Entwicklungslinie neben der Rechnergeschichte direkt nachvollziehen: Video8/Hi8 → DV → Videostandbilddruck → i.LINK/FireWire → Bearbeitung am VAIO → digitaler Fotodruck. Die ausführliche technische und praktische Darstellung steht auf video.htm.

Solche Recorder waren 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 entsprechen sie derselben Haltung wie bei 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 in dieselbe technische Geschichte wie PET, C64, Amiga oder die späteren Windows-PCs. Es sind unterschiedliche Welten, aber derselbe Blick: Dinge ansehen, vergleichen, erhalten und in ihrer Konstruktion ernst nehmen.

„Nicht nur Rechner, auch Videotechnik war immer etwas zum Verstehen.“

Die reine Videoseite bleibt video.htm. LaserVision und die frühe optische Bildplatte werden auf laservision.htm vertieft. 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 ist die 2002 gekaufte Dell Precision M50 Workstation. Sie bootet bis heute zuverlässig ihr originales Windows XP Professional und ist im Archiv in ihrer konkreten Ausstattung dokumentiert.

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 entsteht der Code nicht mehr auf einem alten Tower, sondern unter anderem 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 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 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 ist dort weniger der Werbeton interessant 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 bleiben die hier dokumentierten Weblö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. Die praktische Reparaturhaltung und der Umgang mit Fehlersuche, Erhalt und vertretbaren Eingriffen werden zusätzlich auf repair-attitude.htm gebündelt.