Commodore CBM 700 (1983) – Viel Rechner, wenig Erklärung

CC BY-SA 3.0, Wikimedia Commons, Curid 16547

Dr. Reinhard Grabowski wollte den Commodore CBM 700 1984 für die mc testen. Statt lediglich Leistung und Bedienung zu prüfen, musste er zunächst herausfinden, wie das System überhaupt arbeitete. Er suchte Systemadressen, untersuchte Befehle durch eigene Versuche und veröffentlichte seine Ergebnisse anschließend in seinem fünfseitigen Bericht „Computer mit Dokumentations-Defizit – Commodore-700“.

Die mc – Die Mikrocomputer-Zeitschrift war kein Magazin für Gelegenheitskäufer. Das seit 1981 im Franzis-Verlag erscheinende Fachblatt behandelte Prozessoren, Schaltungen und maschinennahe Programmierung. Seine Leser sollten Computer nicht nur bedienen, sondern ihren Aufbau verstehen. Wenn selbst der Autor eines solchen Magazins den CBM 700 teilweise selbst dokumentieren musste, saß das Problem nicht vor der Tastatur.

Auf den ersten Blick machte der Rechner einen freundlichen Eindruck. Der Bildschirm zeigte saubere grüne Zeichen, die abgesetzte Tastatur arbeitete leise, und das abgerundete Gehäuse wirkte neben den kantigen PET-Modellen wie der Beginn einer neuen Commodore-Generation. Im Inneren steckten reichlich Speicher, IEEE-488, RS-232 und sogar der SID des Commodore 64. Es fehlten jedoch Programme und Unterlagen, die daraus einen verlässlichen Arbeitsplatz machten.

Ein neuer Commodore für das Büro

Commodores PET- und CBM-Rechner hatten sich in Schulen, Laboren und kleineren Betrieben etabliert. Anfang der 1980er-Jahre stieß ihre Architektur jedoch an Grenzen. Größere Speichererweiterungen ließen sich nur mit angepasster Software sinnvoll nutzen, während neue Geschäftsanwendungen mehr Platz verlangten.

Die 1982 angekündigte CBM-II-Familie sollte diese Beschränkungen beseitigen. Die flachen 600er-Modelle arbeiteten mit einem externen Monitor, während die 700er einen eingebauten 12-Zoll-Bildschirm und eine frei aufstellbare Tastatur erhielten. In Europa kamen vor allem der CBM 710 mit 128 KByte RAM und der CBM 720 mit 256 KByte auf den Markt.

Daneben kursierten Bezeichnungen wie B700, CBM 128-80, CBM 256-80 oder PET 700. Commodore plante außerdem Modelle mit Doppellaufwerken und zusätzlichen Prozessoren. Ein übersichtliches Sortiment entstand daraus nicht.

Das Gehäuse entwarf Ira Velinsky, ein amerikanischer Industriedesigner bei Commodore. Seine Softline ersetzte die Blechkanten älterer PETs durch Rundungen und ein nach hinten abfallendes Monitorgehäuse. Die Bürocomputer-Serie erhielt 1983 eine iF-Auszeichnung. Später verwendete Commodore die Form unter anderem für den CBM 8032-SK, den 8096-SK und den 8296 weiter.

Grabowski lobte die praktische Ausführung des 700ers. Die entspiegelte Bildfläche zeigte kräftig grüne Zeichen, deren vergleichsweise lange Nachleuchtdauer für ein ruhiges Bild sorgte. Schnelle Veränderungen blieben allerdings kurz sichtbar. Auch der eingebaute Lüfter meldete sich hörbar – im stillen Büro lästiger als auf einem Messestand.

Viel Speicher hinter mehreren Türen

Im CBM 700 arbeitete ein MOS 6509A mit rund 2 MHz. Der mit dem 6502 verwandte Prozessor konnte mittels Bank-Switching zwischen mehreren Speicherbereichen wechseln. Das war nötig, weil ein gewöhnlicher 6502 nur 64 KByte unmittelbar ansprechen konnte.

Der 6509 teilte den Speicher in bis zu 16 Bänke mit jeweils 64 KByte auf. Damit entstand theoretisch ein Adressraum von einem Megabyte. Der CBM 710 besaß 128 KByte, der CBM 720 256 KByte; Erweiterungen sollten insgesamt bis zu 960 KByte ermöglichen.

Der Prozessor sah jedoch nie den gesamten Speicher gleichzeitig. Er arbeitete innerhalb einer ausgewählten Bank und wechselte bei Bedarf in eine andere. BASIC verteilte Programmtext, Variablen und Zeichenketten weitgehend automatisch auf die verschiedenen Bereiche. Wer ausschließlich in BASIC arbeitete, bekam vom Bank-Switching daher wenig mit.

In Maschinensprache wurde es schwieriger. Programmierer mussten wissen, in welcher Bank ihr Code lag, welche Systemroutinen erreichbar waren und auf welchen Speicherbereich ein Befehl tatsächlich zugriff. Genau hier ließ das deutsche Handbuch Grabowski im Stich. Es erklärte zwar die grundsätzliche Speicheraufteilung, enthielt aber keine vollständige Übersicht der vom Betriebssystem verwendeten Adressen. Grabowski suchte deshalb selbst nach Cursorposition, Bildschirmzeile, Textfenster und Tastaturpuffer und veröffentlichte seine Ergebnisse im Test.

BASIC war nicht das Problem

Nach dem Einschalten meldete sich der Rechner mit BASIC 4.0+. Das wirkte 1983 bei einem Bürocomputer bereits etwas konservativ, doch die Sprache war deutlich besser ausgestattet als das schlichte BASIC V2 des C64.

Mit PRINT USING ließen sich Zahlenkolonnen, Dezimalstellen und Währungsbeträge sauber ausrichten – nützlich für Rechnungen, Lagerlisten und Tabellen. Verzweigungen konnten übersichtlicher geschrieben und Programmfehler behandelt werden, ohne dass die Ausführung sofort abbrach. Hinzu kamen Befehle für Laufwerke, Dateien, Zeichenketten und die Speicherbänke. Grabowski beurteilte vor allem die Fehlerbehandlung positiv und sah in BASIC 4.0+ ein brauchbares Fundament für kaufmännische und technische Programme.

Auch die Tastatur passte zum Büroeinsatz. Sie besaß einen eigenen Ziffernblock und programmierbare Funktionstasten, auf denen Befehle oder kurze Eingabefolgen abgelegt werden konnten. Der Editor arbeitete komfortabler als beim CBM 8032.

Eine kleine Eigenheit fiel erst bei längerer Benutzung auf: Hielt man eine Cursortaste gedrückt, verschwand der Cursor während der Bewegung und tauchte erst am Ziel wieder auf. Der Benutzer konnte zwischendurch nur schätzen, wie weit er gewandert war.

Der SID im Rechnungsbüro

Zwischen Speichersteuerung und Schnittstellen saß ein MOS 6581 SID. Der Chip bot drei programmierbare Stimmen, Hüllkurven, mehrere Wellenformen und ein gemeinsames Filter.

Beim C64 wurde der SID zum Ausgangspunkt zahlloser Spiele und Musikprogramme. Im CBM 700 war er eher für Signaltöne und akustische Rückmeldungen gedacht. Ein Rechner für Buchhaltung und Textverarbeitung konnte damit drei Stimmen durch ein analoges Filter schicken, während der Anwender am Grünmonitor seine Zahlenkolonnen bearbeitete.

Für den Büroalltag wichtiger war der IEEE-488-Bus. Vorhandene Commodore-Laufwerke und Drucker ließen sich grundsätzlich weiterverwenden. Der CBM 700 benötigte dafür allerdings ein besonderes Adapterkabel, weil sein Anschluss nicht in der von älteren Geräten gewohnten Form herausgeführt wurde.

Hinzu kam eine RS-232-Schnittstelle für Drucker, Modems und Terminals. Auch hier verlief der praktische Einsatz nicht immer geradlinig. Commodores eigener Zeichencode stimmte nicht vollständig mit dem ASCII-Code vieler Geräte überein. Grabowski warnte daher vor möglichen Zusatzkosten für eine Codewandlung.

Z80- und 8088-Koprozessoren sollten später CP/M beziehungsweise MS-DOS zugänglich machen. Die 8088-Platine erreichte mehrere Entwicklungsstufen, wurde jedoch nie zu einer breit verfügbaren und verlässlich unterstützten Erweiterung.

Das Handbuch kam nicht beim Käufer an

Der Titel „Computer mit Dokumentations-Defizit“ bedeutete nicht, dass Commodore überhaupt keine Unterlagen verfasst hatte. Ein deutsches Handbuch existierte, und auch ein umfangreicher englischer Reference Guide ist erhalten geblieben. Entscheidend war jedoch, was der Käufer 1984 tatsächlich bekam.

Das deutsche Handbuch behandelte maschinennahe Fragen nur oberflächlich. Das ausführlichere englische Material war nach Grabowskis Angaben in Deutschland nicht erhältlich. Nach späteren Berichten aus der CBM-II-Szene stellte ein Mitarbeiter von Commodore UK das englische Programmiererhandbuch weitgehend aus eigener Initiative und teilweise in seiner Freizeit zusammen, weil die britische Niederlassung den Rechner an Geschäftskunden verkaufen wollte.

Der Autor verfügte demnach nicht über vollständigen Zugang zu den Entwicklern und ihren Unterlagen. Das könnte erklären, weshalb das Handbuch viele nützliche Angaben enthielt, an anderen Stellen aber unklar blieb oder Beispiele aufführte, die nicht zuverlässig funktionierten.

Auch der erhaltene Reference Guide wirkt nicht wie eine vollständig durchredigierte Systembeschreibung. Bereits auf den ersten Seiten werden Hoch- und Niedrigprofilmodelle sowie verschiedene Bezeichnungen miteinander vermischt. Wer tiefer einsteigen wollte, benötigte zusätzliche Bücher und musste selbst herausfinden, welche Angaben für das eigene Modell galten.

Diese Lücke traf den CBM 700 besonders hart. Die neue Speicherarchitektur machte Programme des CBM 8032 häufig inkompatibel. Reines BASIC ließ sich noch anpassen, doch kommerzielle Anwendungen verwendeten oft feste Speicheradressen, eigene Bildschirmroutinen oder Maschinensprache. Neue Software hätte geschrieben werden können – dafür benötigten Programmierer jedoch genau jene Systeminformationen, die Commodore nicht zuverlässig bereitstellte.

Zu spät für den Markt

Ein Geschäftskunde kaufte keinen Computer, um auf eine künftige Umsetzung seiner Buchhaltung zu warten. Das Gerät sollte am Tag der Lieferung eine konkrete Aufgabe übernehmen. Grabowski berichtete, einige Händler würden den CBM 700 bereits nur noch mit ausdrücklichen Vorbehalten verkaufen.

Die älteren Commodore-Systeme boten weniger Speicher, konnten dafür aber auf vorhandene Programme und erfahrene Anwender zurückgreifen. Gleichzeitig wuchs rund um den IBM PC ein Markt aus Software, Erweiterungskarten und kompatiblen Nachbauten.

Innerhalb Commodores beanspruchte der erfolgreiche C64 einen großen Teil der Entwicklungskapazitäten, Fertigung und Werbung. Änderungen an Hardware und Firmware verzögerten unterdessen die CBM-II-Reihe. Die europäischen Geräte gingen erst gegen Ende 1983 in Braunschweig in Produktion. Bereits 1984 endete die Fertigung wieder.

In Großbritannien senkte Commodore den Preis der 700er-Serie 1983 um 18 Prozent auf 650 Pfund. Inflationsbereinigt entspricht das rund 2.960 Pfund im Jahr 2026. Laufwerk, Drucker und Anwendungssoftware waren damit noch nicht bezahlt.

Der Nachlass änderte nichts am Kernproblem. 128 oder 256 KByte RAM waren für einen Betrieb nur dann nützlich, wenn am Montagmorgen ein Programm bereitstand, das damit arbeitete.

Die Benutzer übernehmen

In den USA gelangten viele Geräte über den Restpostenhändler Protecto an neue Besitzer. Rund um Chicago entstand eine Benutzergruppe, die Programme, technische Hinweise und interne Unterlagen sammelte. Sie hielt das aufgegebene System noch einige Jahre am Leben.

Vier Jahrzehnte später stieß ein heutiger CBM-II-Programmierer auf dieselben Lücken. Er wollte das alte, mit der Schreibmaschine erstellte Referenzmaterial zunächst nur neu setzen und besser lesbar machen. Beim Durcharbeiten fand er jedoch unklare Erklärungen und Beispiele, die nicht funktionierten. Aus der Neusetzung entstand deshalb ein neues Handbuch mit Speicherkarte, KERNAL-Routinen und eigenen Programmbeispielen.

Commodore verwendete das Softline-Gehäuse später für Rechner, deren ältere Technik besser dokumentiert war und auf eine vorhandene Softwarebasis zurückgreifen konnte. Der modernere CBM 700 verschwand dagegen aus dem Programm.

Der Rechner war längst ein Sammlerstück. Seine Gebrauchsanweisung war noch immer nicht fertig.

Commodore MDS 6500 – Der PET als Entwicklerwerkzeug

Wer Ende der 1970er-Jahre Software für einen 6502-Rechner entwickeln wollte, benötigte mehr als einen Texteditor und eine freie Steckdose. Quelltexte mussten eingegeben, übersetzt, auf Fehler untersucht und schließlich auf das eigentliche Zielsystem übertragen werden. MOS Technology hatte dafür zunächst das MDT650 entwickelt, ein kostspieliges Microcomputer Development Terminal mit Diskettenlaufwerk und eigener Entwicklungssoftware. Der spätere Commodore MDS 6500 übertrug dieses Prinzip auf eine wesentlich vertrautere Grundlage: den PET.

Die Abkürzung MDS stand für Microcomputer Development System. Hinter der besonderen Modellbezeichnung verbarg sich kein vollständig neu konstruierter Rechner, sondern ein für Entwicklungsarbeiten angepasster Commodore PET 2001-32N mit 32 KB RAM. Auf dem Gehäuse saß anstelle der üblichen PET-Modellbezeichnung ein MDS-6500-Schriftzug. Zum System gehörte ein passend beschriftetes CBM-2040-Doppeldiskettenlaufwerk, das Programmtexte, Objektdateien und weitere Entwicklungsdaten aufnehmen konnte.

Der PET brachte dafür bereits eine zweckmäßige Grundausstattung mit. Sein MOS-6502-Prozessor arbeitete mit ungefähr 1 MHz, der eingebaute Monitor stellte 40 Zeichen in 25 Zeilen dar, und über den IEEE-488-Anschluss ließ sich das externe Doppellaufwerk betreiben. Für gewöhnliche Büroarbeiten war diese Kombination ebenfalls geeignet, doch beim MDS 6500 lag der Schwerpunkt auf der Erstellung von Software für die MCS6500-Prozessorfamilie.

Der Name sorgt leicht für Verwirrung. MCS6500 war die Bezeichnung der von MOS Technology entwickelten Mikroprozessorfamilie, zu der neben dem bekannten 6502 auch der 6501 sowie mehrere Varianten mit abweichender Anschlussbelegung gehörten. Das MDS 6500 bezeichnete dagegen ein komplettes Entwicklungssystem. Es steckte also kein besonderer „6500-Prozessor“ im Rechner; im Inneren arbeitete weiterhin der aus dem PET bekannte 6502.

Wie solche Systeme eingesetzt wurden, zeigt das MCS6500 Family Hardware Manual. Es beschreibt neben Prozessoren, Speicherbausteinen, Bussystemen und Interruptsteuerung auch das ältere MDT – Microcomputer Development Terminal. MOS bezeichnete dieses als fertig zusammengestelltes System, mit dem Entwickler ihre Programme und die Verbindung zu Ein- und Ausgabegeräten prüfen konnten. Der Vorteil lag auf der Hand: Statt gleichzeitig nach Fehlern in selbst aufgebauter Hardware und im eigenen Programmcode suchen zu müssen, erhielt der Entwickler eine bekannte Arbeitsumgebung. Damit ließ sich das Problem wenigstens auf eine Seite des Schreibtisches eingrenzen.

Bei Commodore waren die ursprünglichen MDT650-Systeme nur in geringer Zahl vorhanden. Auf ihnen wurde der MOS Resident Assembler eingesetzt, mit dem unter anderem Software für den ersten PET und das CBM-2040-Laufwerk entstand. Als das 2040 verfügbar war, portierte Commodore-Mitarbeiter John Feagans den Resident Assembler auf den PET. Damit konnte Commodore die Entwicklungsarbeit von den seltenen und teuren MDT-Terminals auf die eigenen Serienrechner verlagern.

Bekannte Versionen des PET Resident Assemblers tragen die Datierungen 27. November 1979 und 15. Dezember 1979. Commodore veröffentlichte diese Software 1980 als Teil des PET Assembler Development System. Der Assembler verarbeitete Quelltexte, erzeugte Maschinencode und konnte Listen mit Speicheradressen, Opcodes und Fehlermeldungen ausgeben. Zusammen mit dem Diskettenlaufwerk wurde der PET damit zu einer vollständigen Entwicklungsstation, ohne dass dafür erneut ein spezielles Terminal von Grund auf konstruiert werden musste.

Die praktische Bedeutung dieser Arbeitsweise ging über den MDS 6500 hinaus. Commodore verwendete den auf den PET übertragenen Resident Assembler für Betriebssystem- und BASIC-Bestandteile späterer PET-Modelle, des VIC-20, des C64 und der CBM-II-Reihe. Auch ROMs verschiedener Diskettenlaufwerke, Drucker und Commodore-eigener Programme entstanden mit dieser Entwicklungsumgebung. Erst ab 1984 verlagerte Commodore einen größeren Teil der Arbeit auf einen unter VAX/VMS laufenden Cross-Assembler.

Wie deutlich sich ein MDS 6500 technisch von einem normalen PET 2001-32N unterschied, ist nur unvollständig dokumentiert. Die erhaltenen Beschreibungen sprechen von einem modifizierten PET mit Assembler und einem passend gekennzeichneten 2040-Laufwerk. Ob der Assembler fest im Rechner untergebracht war oder zum ausgelieferten Diskettensatz gehörte, lässt sich aus den derzeit verfügbaren Unterlagen nicht eindeutig ableiten. Auch eine vollständige Liste der zusätzlich gelieferten Programme, Handbücher und Kabel fehlt.

Eine häufig zitierte Commodore-Modellübersicht nennt 500 gefertigte Geräte, während eine weitere Beschreibung von weniger als 500 Exemplaren spricht. Eine dazugehörige Produktionsaufstellung von Commodore ist bislang nicht bekannt. Die Zahl sollte daher als überlieferte Größenordnung und nicht als abschließend bestätigte Stückzahl verstanden werden.

Der MDS 6500 war damit kein eigenständiger Heimcomputer und auch kein gewöhnliches PET-Sondermodell für Schulen oder Büros. Er gehörte zu den professionellen Werkzeugen, mit denen Software für die wachsende 6502-Rechnerfamilie entstand. Äußerlich blieb er ein PET mit passendem Doppellaufwerk. Seine eigentliche Aufgabe lag jedoch nicht vor dem Bildschirm, sondern in den Programmen, ROMs und Betriebssystemteilen, die mit seiner Hilfe entwickelt wurden.

Commodore Educator 64 – Der C64 im PET-Gehäuse

Foto: Marcin Wichary / Wikimedia Commons, CC BY 2.0

Auf den ersten Blick wirkte der Commodore Educator 64 wie ein verspäteter Vertreter der PET-Familie: ein großer Tischcomputer mit fest eingebautem Bildschirm, aufklappbarem Gehäuse und einer Tastatur, die nicht ohne Weiteres vom Arbeitsplatz verschwinden konnte. Nach dem Einschalten meldete sich jedoch kein PET, sondern ein Commodore 64. Commodore verband die Technik seines erfolgreichen Heimcomputers mit einer Gehäuseform, die bereits seit den späten 1970er-Jahren in Schulen, Universitäten und kleinen Betrieben zu finden war.

Die Bezeichnungen fallen weniger eindeutig aus als das Gerät selbst. Der Rechner wurde als Educator 64, PET 64, CBM 4064 oder Commodore 4064 geführt. Dabei handelte es sich nicht um vier grundsätzlich verschiedene Computer, sondern um Namen und Ausführungen derselben C64-basierten Schulcomputerfamilie. Erhaltene Geräte tragen teilweise vorne die Bezeichnung „Educator 64“, während auf dem rückwärtigen Typenschild weiterhin 4064 steht. Frühe Ausführungen konnten sich bei ROM, Bildaufbereitung und Tonausstattung von späteren Geräten unterscheiden.

Commodore zielte damit vor allem auf den nordamerikanischen Bildungsmarkt. Ein gewöhnlicher C64 war zwar vergleichsweise preiswert, bestand aber aus Rechner, externem Netzteil, Monitor oder Fernseher und den dazugehörigen Kabeln. Im Unterricht konnten Stecker gelöst, Netzteile vertauscht oder einzelne Komponenten beschädigt und mitgenommen werden. Häufig wird deshalb erzählt, Schulen hätten nach einem C64 verlangt, der nicht in einem Rucksack verschwinden konnte. Eine eindeutige Commodore-Aussage, nach der Diebstahl den Ausschlag für die Entwicklung gab, ist nicht überliefert. Das schwere All-in-one-Gehäuse verringerte diese Risiken jedoch tatsächlich: Rechner, Monitor und Stromversorgung bildeten eine Einheit, und auf den Tischen lagen deutlich weniger lose Teile.

Als Grundlage diente ein Gehäuse im Stil der PET- und CBM-4000-Serie. Bei erhaltenen Educator-Geräten besteht der Unterbau aus Metall, während das Oberteil aus dickem Kunststoff gefertigt ist. Wie bei den PET-Rechnern lässt sich die obere Gehäusehälfte aufklappen und mit einer Stütze offen halten. Darunter sitzt keine klassische PET-Platine, sondern eine quer eingebaute C64-Hauptplatine. Hinzu kommen die interne Stromversorgung, die Ansteuerung des Monitors und bei den besser ausgestatteten Geräten eine zusätzliche Audioelektronik.

Im technischen Kern entsprach der Educator 64 weitgehend dem nordamerikanischen C64. Der MOS 6510 arbeitete in der NTSC-Ausführung mit ungefähr 1,02 MHz. Zur Verfügung standen 64 Kilobyte RAM, Commodore BASIC 2.0 sowie die BASIC-, KERNAL- und Zeichensatz-ROMs des C64. Die Bildausgabe übernahm der VIC-II, gewöhnlich ein MOS 6567. Er beherrschte die bekannten Text- und Grafikmodi, bis zu 320 × 200 Bildpunkte, acht Hardware-Sprites und intern eine Palette aus 16 Farben. Zwei MOS 6526 CIA steuerten unter anderem Tastatur, Joysticks, serielle Schnittstelle und Zeitgeber.

Der eingebaute Bildschirm konnte diese Farben jedoch nicht direkt darstellen. Der Grünmonitor setzte die vom VIC-II erzeugten Signale in verschiedene Helligkeitsstufen um. Helle und dunkle Flächen blieben unterscheidbar, Farben mit ähnlicher Leuchtdichte konnten dagegen nahezu gleich aussehen. Für BASIC-Unterricht, Textverarbeitung, Mathematikprogramme und andere vorwiegend textorientierte Anwendungen genügte das. Farbabhängige Lernprogramme konnten problematisch werden, wenn beispielsweise ein rotes und ein blaues Feld auf dem Monitor als ähnlich helle Grünflächen erschienen. Spiele liefen ebenfalls, verloren aber einen großen Teil jener Farbgrafik, mit der sich der C64 von älteren Schulcomputern absetzte.

Die Tastatur entsprach weitgehend der des C64, verzichtete jedoch auf die Farbbezeichnungen an den Vorderseiten der Zahlentasten. Über ihr befand sich eine großflächige Referenztafel mit BASIC-Befehlen, PETSCII-Zeichen, Variablentypen, Gerätenummern und teilweise Tabellen für Binär-, Dezimal- und Hexadezimalwerte. Je nach Ausführung kamen Hinweise zu Logo oder zur Bedienung typischer Peripheriegeräte hinzu. Einen Teil des Spickzettels lieferte Commodore damit gleich ab Werk.

Bei vollständig ausgestatteten Educator-Geräten gehörte auch der MOS 6581 SID zur Hauptplatine. Seine drei Stimmen, Filter und Wellenformen standen der Software wie beim normalen C64 zur Verfügung. Commodore ergänzte einen kleinen internen Lautsprecher, einen Verstärker, einen Lautstärkeregler und einen Kopfhöreranschluss. Der Lautsprecher eignete sich eher für Signaltöne und Lernprogramme als für eine eindrucksvolle SID-Vorführung. Der Kopfhörerausgang war im Unterricht dafür umso nützlicher: Eine ganze Klasse gleichzeitig laufender C64-Musikprogramme hätte selbst die Vorzüge des SID rasch relativiert.

Die beiden Joystickbuchsen und der Kopfhöreranschluss lagen an der Vorderseite unterhalb der Tastatur. Modulport, Videoanschluss, serielle IEC-Buchse, Datasettenanschluss und User Port befanden sich an der rechten Seite. Damit blieb der Educator mit C64-Laufwerken, Druckern, Datasetten, Joysticks und Steckmodulen verwendbar. Die Einpassung der C64-Platine in das größere Gehäuse brachte allerdings kleine Schwierigkeiten mit sich. Einige Buchsen lagen hinter den Gehäusekanten zurück, sodass besonders breite Stecker oder große Module am Kunststoff anstoßen konnten. Bei sperrigen Erweiterungen halfen kurze Verlängerungen oder Portexpander.

Die interne Stromversorgung ersetzte den bekannten externen C64-Netzteilblock und speiste zugleich den Monitor. Der Educator benötigte daher nur ein gewöhnliches Netzkabel. Für einen einzelnen Heimarbeitsplatz war das Gehäuse weder klein noch leicht, in einem Computerraum ließ sich eine Reihe gleichartiger Geräte jedoch übersichtlicher aufstellen als mehrere C64 mit separaten Monitoren und Netzteilen.

Erhaltene Exemplare zeigen, dass Commodore während der Fertigung unterschiedliche C64-Hauptplatinen verwendete. Dokumentiert sind unter anderem frühe Platinen vom Typ ASSY 326298 sowie spätere ASSY 250425. Auch Stromversorgung, Monitoranschluss, Tastaturverkabelung und Audioausstattung konnten voneinander abweichen. Mehrere Sammlerberichte behaupten, Commodore habe dabei instand gesetzte Garantierückläufer verwendet. Die verbauten frühen Platinen und die Nutzung vorhandener PET-Gehäuse passen zu Commodores pragmatischer Fertigung, beweisen aber nicht, dass jede Educator-Platine zuvor in einem verkauften C64 eingesetzt gewesen war.

Trotz des PET-Namens war der Educator nicht mit den klassischen PET- und CBM-Rechnern softwarekompatibel. Programme für PET 2001, CBM 3032 oder CBM 4032 liefen nicht automatisch. Im Inneren blieb er ein C64 mit dessen Speicheraufteilung, BASIC, ROMs und Schnittstellen. Schulen mit vorhandener PET-Software mussten Programme anpassen oder auf C64-Versionen wechseln. Das vertraute Gehäuse täuschte eine technische Kontinuität vor, die auf Softwareebene kaum bestand.

Auf dem amerikanischen Schulmarkt traf Commodore auf die bereits etablierte Apple-II-Familie. Apple verfügte nicht nur über Hardware, sondern auch über Schulprogramme, Händlerkontakte, Unterrichtsmaterial und Erfahrungen aus bestehenden Computerräumen. Der Educator vereinfachte zwar Aufbau und Verkabelung, schuf aber kein vergleichbares Bildungsökosystem. Gleichzeitig nahm der monochrome Monitor dem C64 gerade jene Farbfähigkeiten, die ihn von vielen günstigeren Büro- und Schulrechnern unterschieden.

Verlässliche Produktions- oder Verkaufszahlen sind nicht bekannt. Konkrete Angaben von wenigen Hundert oder einigen Tausend Geräten lassen sich bislang nicht ausreichend belegen. Erhaltene Exemplare erscheinen heute nur gelegentlich in Museen, Sammlungen und Restaurationsberichten, während der gewöhnliche C64 millionenfach verbreitet war.

Eine spätere amerikanische Händleranzeige zeigt den Educator bereits als Rest- beziehungsweise Gebrauchtposten. Beworben wurden vollständig überholte Geräte mit 90 Tagen Garantie, eingebautem Grünmonitor, robuster Stromversorgung und „100% C-64 Compatible“. Als regulärer Verkaufspreis nannte die Anzeige 499,95 US-Dollar, als Händlerpreis 325 Dollar und als Abverkaufspreis 199,95 Dollar. Nach heutiger Kaufkraft, Stand Juni 2026, entsprechen 199,95 Dollar ungefähr 579 US-Dollar beziehungsweise rund 500 Euro. Die genannten 499,95 Dollar lägen bei etwa 1.447 heutigen US-Dollar oder rund 1.250 Euro. Die Anzeige belegt damit vor allem den späteren Abverkauf; als sicherer Einführungspreis des Educator 64 kann der genannte Listenpreis nicht gelten.

Commodore Amiga 500: Die Alltagsmaschine, die zur Legende wurde

Ist es wirklich notwendig, über den Amiga 500 zu schreiben? Über einen Computer, den viele als ihren ersten „echten“ Rechner erlebt haben, über den sich Mythen ranken, dessen Name noch heute nostalgische Reflexe auslöst? Vielleicht ist es genau deshalb notwendig. Denn der Amiga 500 war nicht nur ein Erfolgsmodell, sondern ein kulturelles Phänomen – eines, dessen Bedeutung sich erst im Rückblick vollständig erschließt. Wir sprechen von einem Computer, der millionenfach verkauft wurde, der Generationen prägte und dennoch wirtschaftlich nie jene Stabilität erreichte, die sein Einfluss vermuten ließe. Zeit also, den Amiga 500 in Ruhe einzuordnen. Der Amiga 500 war weniger Neuentwicklung als bewusste Neupositionierung.

Nachdem der technisch revolutionäre, aber teure Amiga 1000 den Markt kaum erreichte, wurde bei Commodore früh klar, dass die Zukunft der Plattform nicht in einem weiteren Prestigeobjekt lag, sondern in einem erschwinglichen, massentauglichen System. Ziel war es, die außergewöhnlichen Fähigkeiten der Amiga-Architektur in ein kompaktes Gerät zu überführen, das näher an der Lebensrealität der Nutzer lag. Der Amiga 500 sollte kein Demonstrator sein, sondern ein Alltagsrechner – wohnzimmertauglich, preislich erreichbar und vielseitig einsetzbar. Diese Pragmatik war kein Rückschritt, sondern Voraussetzung des Erfolgs.

Dabei spiegelte sich auch eine unterschiedliche Entwicklungsphilosophie innerhalb des Commodore-Konzerns wider. Beide Modelle wurden bei Commodore in West Chester entwickelt, verfolgten jedoch von Beginn an unterschiedliche Zielsetzungen. Während der Amiga 500 konsequent auf den Heim- und Massenmarkt ausgerichtet war, wurde der Amiga 2000 auf eine modularere, professionell erweiterbare Nutzung hin konzipiert. Anforderungen aus dem internationalen Umfeld – insbesondere aus Europa – beeinflussten dabei vor allem die Auslegung des Amiga 2000, etwa im Hinblick auf Steckplätze, Videoanbindung. Dort standen Erweiterbarkeit, Steckplätze, Videoanwendungen und Studioeinsätze im Vordergrund. Beide Modelle nutzten dieselbe Grundarchitektur, verkörperten jedoch unterschiedliche Antworten auf dieselbe Frage: Was sollte ein Amiga sein? Der Amiga 500 beantwortete sie aus Sicht des Heimcomputers, der Amiga 2000 aus Sicht der Workstation.

Technisch basierte der Amiga 500 auf derselben grundlegenden Architektur wie der zuvor erschienene Amiga 1000. Herzstück war der Motorola 68000, intern mit rund 7,14 MHz im NTSC- und etwa 7,09 MHz im PAL-Betrieb getaktet. Für sich genommen war dieser Prozessor kein Hochleistungswunder, doch das Zusammenspiel mit den spezialisierten Custom-Chips machte den Unterschied. Agnus übernahm Speicherverwaltung und DMA-Zugriffe, Denise war für die Grafik zuständig, Paula kümmerte sich um Audio, Diskettensteuerung und Interrupts. Ergänzt wurde dieses Trio durch Gary, der Bus-Logik und zentrale Teile der Adressdekodierung kontrollierte.

Diese Aufgabenteilung erlaubte es dem Amiga, viele audiovisuelle Prozesse parallel zur CPU auszuführen – ein Ansatz, der ihn im Heimcomputerbereich der Mitte der 1980er-Jahre durch die Kombination aus Grafik-, Sound- und Multitasking-Fähigkeiten deutlich von zeitgenössischen Systemen abhob.

Diese Architektur zahlte sich besonders in der Praxis aus. Während zeitgenössische Rechner viele Aufgaben vollständig der CPU überließen, konnte der Amiga Grafik- und Soundoperationen auslagern, ohne den Hauptprozessor zu blockieren. Das Ergebnis war eine Leistungsfähigkeit, die sich unmittelbar in Spielen, Demos und Multimedia-Anwendungen zeigte. Grafikmodi mit bis zu 4096 Farben (HAM), vier unabhängige 8-Bit-Audiokanäle und echtes präemptives Multitasking waren im Heimcomputerbereich Mitte der 1980er-Jahre nahezu konkurrenzlos.

Zwar beruhte auch der Amiga 1000 auf derselben Architektur, erwies sich im Auslieferungszustand jedoch als deutlich unpraktischer im Alltag. Da das Kickstart noch nicht im ROM vorlag, musste das Betriebssystem beim Start von Diskette in den Arbeitsspeicher geladen werden, wodurch ein erheblicher Teil der ursprünglich nur 256 KB RAM bereits belegt war, bevor Anwendungen oder Spiele überhaupt beginnen konnten. Technisch war der Amiga 1000 keineswegs eingeschränkt – mit Speichererweiterungen ließ er sich leistungsfähig ausbauen –, doch erst der Amiga 500 beseitigte diese Einstiegshürden konsequent und machte die Architektur im Serienzustand wirklich alltagstauglich.

Mit dem A500 wanderte Kickstart fest ins ROM. Der Rechner war nach dem Einschalten sofort funktionsfähig – kürzere Bootzeiten, höhere Robustheit, geringere Einstiegshürden. Der Preis: Updates erforderten ROM-Tausch.

Während der Amiga 1000 sein Betriebssystem bei jedem Start von Diskette laden musste, stand dem Amiga 500 nach dem Einschalten sofort eine lauffähige Systembasis zur Verfügung. Das verkürzte Startzeiten, erhöhte die Zuverlässigkeit und senkte die Einstiegshürde erheblich. Diese Entscheidung war jedoch nicht unumstritten. Teile des Entwicklerumfelds sahen im festgeschriebenen Kickstart-ROM eine Einschränkung, da frühe Designentscheidungen damit schwerer korrigierbar wurden und Weiterentwicklungen einen physischen Austausch des ROMs erforderten. Was für den Alltag ein Gewinn war, konnte langfristig zur Fixierung werden – ein klassischer Zielkonflikt zwischen Benutzerfreundlichkeit und technischer Flexibilität.

Auf Kickstart aufbauend stellte die Workbench die grafische Arbeitsumgebung des Amiga dar. Sie folgte bewusst nicht der damals verbreiteten Desktop-Metapher, sondern setzte auf eigene Begriffe und Konzepte. Verzeichnisse hießen „Drawer“, Programme „Tools“, Dateien „Projects“. Parallel dazu existierte mit der CLI von Beginn an eine vollwertige Kommandozeile, die nicht als Notlösung, sondern als gleichberechtigter Zugang zum System gedacht war. Der Amiga war nie ein reines GUI-System, sondern ein Rechner, der grafische und textbasierte Arbeitsweisen selbstverständlich miteinander verband. Besonders bemerkenswert war, dass das Betriebssystem bereits früh präemptives Multitasking bot – nicht als Demonstration, sondern als Alltagsfunktion, selbst auf Systemen mit begrenztem Speicher.

Ein zentrales Merkmal der Amiga-Architektur war das differenzierte Speicherkonzept. Chip-RAM bildete den gemeinsamen Arbeitsbereich von CPU und Custom-Chips und war essenziell für Grafik und Sound. Slow-RAM, häufig über den Trapdoor-Slot unter der Gehäuseklappe realisiert, konnte zwar von der CPU genutzt werden, lief jedoch über den Chip-Bus und unterlag dessen Busarbitration, wodurch der Zugriff langsamer war als auf echtes Fast-RAM. Erst mit späteren Agnus-Revisionen oder beim Amiga 500 Plus ließ sich dieser Speicher direkt als Chip-RAM einbinden. Fast-RAM schließlich war ausschließlich der CPU vorbehalten und deutlich effizienter, da es nicht am Chip-Bus hing und somit keine Wartezyklen durch den Chipsatz entstehen konnten. Im Amiga 500 wurde solches Fast-RAM vor allem über den seitlichen Expansionsport realisiert.

Vereinfacht lässt sich das so verstehen: Chip-RAM ist eine Hauptverkehrsstraße, auf der sich CPU, Grafik und Sound den Zugriff teilen. Slow-RAM ist eine Nebenstraße mit Wartezeiten. Fast-RAM hingegen ist eine exklusive Schnellstraße nur für die CPU. Für Spiele war Chip-RAM entscheidend, für Anwendungen Fast-RAM – ein Spannungsfeld, das den Ausbau des Amiga 500 prägte.

Frühe A500 mit dem Agnus 8370/8371 boten 512 KB Chip (plus 512 KB Slow über Trapdoor). Spätere Revisionen erhöhten auf 1 MB Chip; mit dem 8375 konnten in entsprechend bestückten Systemen bis 2 MB Chip genutzt werden (z. B. A500 Plus).

Ergänzend dazu konnten über den seitlichen Expansionsport mehrere Megabyte Fast-RAM nachgerüstet werden – in der Praxis meist bis zu acht Megabyte –, während zusätzliches Slow-RAM in bestimmten Konfigurationen ebenfalls genutzt werden konnte.
In der Alltagspraxis blieben solche Maximalbestückungen jedoch die Ausnahme. Die meisten Anwender begnügten sich mit moderaten Speichererweiterungen und investierten eher in Komfortzubehör wie Festplattenlösungen. Turbokarten mit 68020- oder 68030-Prozessoren existierten zwar bereits, waren jedoch teuer, nicht immer vollständig kompatibel und boten für viele Spiele kaum einen spürbaren Vorteil. Der typische Amiga-500-Nutzer investierte daher weniger in rohe Rechenleistung als in Speicher und Bedienkomfort. Genau hier zeigte sich, wo die Erweiterbarkeit des Amiga 500 an ihre Grenzen stieß. Mehr Speicher machte das System angenehmer, aber nicht grundlegend moderner. Die CPU und der Chipsatz blieben unverändert, während sich der PC-Markt über stetige Prozessor-Upgrades weiterentwickelte. Der Amiga 500 ließ sich optimieren, aber nicht beliebig weiterdenken. Erweiterbarkeit wurde zur Feinarbeit, nicht mehr zur Zukunftsperspektive.

Mit seiner Markteinführung 1987 traf der Amiga 500 auf einen Markt im Umbruch. In Großbritannien hatte sich der ZX Spectrum etabliert, in Deutschland war der Commodore 64 allgegenwärtig. Der A500 trat nicht an, um diese Systeme direkt zu ersetzen, sondern um sie abzulösen. Besonders in Europa wurde er rasch als der „neue C64“ wahrgenommen – leistungsfähiger, moderner, aber ähnlich zugänglich. Diese Rolle als natürlicher Nachfolger des klassischen Heimcomputers erwies sich als außerordentlich erfolgreich.

In Deutschland entwickelte sich der Amiga 500 zur dominierenden Heimcomputerplattform der späten 1980er-Jahre. Er fand seinen Weg in Kinder- und Jugendzimmer, in Wohngemeinschaften und Hobbykeller. Spiele wie Shadow of the Beast, Turrican, Speedball 2 oder The Secret of Monkey Island zeigten eindrucksvoll, wozu die Maschine fähig war. Action-, Sport- und Arcade-Titel dominierten dabei zahlenmäßig den Markt, während Adventures vor allem kulturell und erzählerisch prägend waren.

Bemerkenswert war, dass der Amiga 500 nicht nur Spieler ansprach. Er wurde zugleich zum kreativen Werkzeug für Musik, Grafik, Textverarbeitung und Programmierung. Programme wie Deluxe Paint oder ProTracker machten ihn zur Produktionsplattform. Diese Offenheit war gewollt – und sie hatte Konsequenzen. Die einfache Kopierbarkeit von Disketten, das Fehlen wirksamer Schutzmechanismen und eine schnell wachsende Cracker-Szene führten dazu, dass Softwareverkäufe oft weit hinter der tatsächlichen Nutzung zurückblieben.

Aus diesem Umfeld entwickelte sich auch die legendäre Demoszene. Was als technische Spielerei begann, wuchs zu einer eigenständigen Kunstform heran, in der Gruppen nicht um Verkaufszahlen konkurrierten, sondern um Effizienz, Kreativität und das Ausloten technischer Grenzen. Der Amiga 500 wurde zur Bühne für audiovisuelle Experimente, deren Einfluss bis heute spürbar ist. Die wirtschaftlichen Folgen für Softwarehersteller resultierten dabei jedoch weniger aus der Demoszene selbst als aus dem weiteren Umfeld der Cracker-Szene, aus dem viele Gruppen hervorgingen und das insgesamt ein Klima schuf, in dem Software vielfach unentgeltlich verbreitet wurde.

Für Commodore selbst war der Erfolg des Amiga 500 ein zweischneidiges Schwert. Der Rechner verkaufte sich hervorragend, doch das Unternehmen verdiente fast ausschließlich an der Hardware. Anders als Konsolenhersteller verfügte Commodore über kein geschlossenes Lizenzsystem, das kontinuierliche Einnahmen aus Software generiert hätte. Die aggressive Preispolitik sicherte Marktanteile, reduzierte jedoch die Margen. Der Amiga 500 hielt Commodore am Leben, stabilisierte das Unternehmen jedoch nicht nachhaltig.

International zeigte sich ein deutliches Gefälle. Während der Amiga in Europa kulturell dominierte, blieb er in den USA ein Nischenprodukt. Dort setzten sich IBM-kompatible PCs zunehmend durch, getragen von Standardisierung, beruflicher Nutzung und klaren Upgrade-Pfaden. Der Amiga gewann Herzen, aber keine Märkte. Diese Diskrepanz zwischen kultureller Bedeutung und wirtschaftlicher Realität wurde im Laufe der Jahre immer deutlicher.

Ein entscheidender Faktor für diese Entwicklung lag außerhalb der reinen Technik. Der Amiga setzte sich nie als Büro- oder Unternehmensstandard durch. Dafür fehlte ihm weniger Leistungsfähigkeit als vielmehr eine zwingende Anwendung – eine sogenannte Killer-App. Während andere Systeme durch einzelne Programme quasi institutionalisiert wurden, blieb der Amiga in dieser Hinsicht fragmentiert. Der IBM-PC etablierte sich im Geschäftsalltag nicht primär wegen einer technischen Überlegenheit im Heimcomputer-Sinn, sondern weil Anwendungen wie Tabellenkalkulationen, Textverarbeitung und Datenbanken dort früh zu De-facto-Standards wurden. Wer im Büro arbeitete, arbeitete mit diesen Programmen – und damit zwangsläufig mit der zugrunde liegenden Plattform.

Auf dem Amiga existierten zwar leistungsfähige Alternativen, doch keine davon erreichte eine vergleichbare Marktdominanz oder institutionelle Verbindlichkeit. Selbst spezialisierte Erfolge wie Cinema 4D blieben auf klar umrissene Zielgruppen beschränkt und eigneten sich nicht als Fundament für eine allgemeine Büro-IT. Hinzu kam, dass Microsoft als zentraler Softwarelieferant kein strategisches Interesse daran hatte, eine konkurrierende Plattform zu stärken, während man parallel das eigene Betriebssystem-Ökosystem für den IBM-PC aufbaute. Der Amiga blieb dadurch ein freier, kreativer Rechner – aber ohne die softwareseitige Verankerung, die für eine nachhaltige Präsenz in Büros, Verwaltungen und Unternehmen notwendig gewesen wäre.

Wie sich diese wachsende Diskrepanz zwischen technischer Leistungsfähigkeit, kultureller Bedeutung und fehlender institutioneller Verankerung entwickelte, lässt sich gut an der zeitgenössischen Fachpresse ablesen. Magazine wie Power Play begleiteten den Amiga 500 über Jahre hinweg und stellten ihn regelmäßig in Vergleichsübersichten neuen Systemen gegenüber. Anfang der 1990er-Jahre veränderte sich der Tonfall spürbar. Der Amiga 500 wurde zunehmend als etablierter Klassiker betrachtet, dessen Stärken bekannt, dessen Grenzen aber ebenso offensichtlich geworden waren. Dieser Wandel erfolgte nicht abrupt, sondern schleichend – und gerade darin lag seine Aussagekraft.

Auch auf Hardware-Ebene spiegelte sich die besondere Entwicklerkultur wider. Auf mehreren Mainboard-Revisionen des Amiga 500 findet sich der interne Codename „Rock Lobster“ beziehungsweise „B52“ direkt auf der Leiterplatte aufgedruckt – eine Referenz an den gleichnamigen Song der B-52’s. Solche Codenamen waren Ausdruck einer informellen, kreativen Ingenieurskultur, wie sie für das Amiga-Team typisch war.

Ein weiteres stilles Detail dieser Kultur findet sich in der Workbench selbst. Das Uhr-Icon, das ab späteren Versionen verwendet wurde, zeigt eine Zeigerstellung, die in der Amiga-Community häufig als stilles Gedenken an die Challenger-Katastrophe von 1986 interpretiert wird. Dabei handelt es sich um eine verbreitete, jedoch nicht belegte Deutung, für die es keine offizielle Bestätigung gibt. Gleichwohl fügt sie sich stimmig in den zeitgeschichtlichen Kontext einer Ära ein, in der Raumfahrt, Technikoptimismus und Computerentwicklung eng miteinander verknüpft waren. Bleibt die Frage der historischen Einordnung: War der Amiga 500 noch ein Homecomputer? Nach klassischer Definition ja: ein erschwinglicher Rechner für den privaten Gebrauch, mit integrierter Tastatur, offen für Spiel, Lernen und Kreativität. War er der letzte seiner Art? Nicht absolut. Systeme wie der Atari ST oder spätere Amiga-Modelle existierten parallel. Doch der Amiga 500 markiert einen Endpunkt – einen der letzten Heimcomputer, der diese Rolle kulturell, technisch und wirtschaftlich vollständig ausfüllte, bevor sich der Markt endgültig auf PC und Konsole aufteilte.

Gerade darin liegt seine historische Bedeutung. Der Amiga 500 war kein perfektes System, aber ein offenes. Er ermöglichte eine Form von Computerkultur, die Experiment, Spiel, Kreativität und Gemeinschaft miteinander verband. Dass er wirtschaftlich nicht dauerhaft bestehen konnte, schmälert diesen Einfluss nicht – es erklärt ihn. Der Amiga 500 war ein Rechner seiner Zeit, und zugleich einer, der ihr in vielerlei Hinsicht voraus war.

MOS 6581 & 8580, Robert Yannes und die Klangarchitektur

By Taras Young - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=123635057

Als der Commodore 64 Anfang der achtziger Jahre auf den Markt kam, war Klang in Heimcomputern noch keine Selbstverständlichkeit. Zwar verfügten einige Systeme bereits über programmierbare Soundchips, die mehrstimmige Tonausgabe erlaubten – etwa der POKEY in den Rechnern der Atari-800-Reihe oder die später weit verbreiteten PSG-Chips von General Instrument –, doch blieb ihre Klanggestaltung meist auf klar definierte, digitale Strukturen beschränkt. Musik entstand hier vor allem durch geschickte Programmierung, weniger durch klangliche Formbarkeit. Piepsen, Klacken, einfache Melodien – funktional, aber ohne ausgeprägte klangliche Tiefe. Vor diesem Hintergrund war der Soundchip des Commodore 64 kein evolutionärer Zwischenschritt, sondern ein bewusster Bruch mit dem Gewohnten.

Im Inneren des Rechners arbeitete kein gewöhnlicher Tongenerator, sondern ein Baustein mit musikalischem Anspruch: der MOS Technology 6581 SID (Sound Interface Device). Er war nicht dafür gedacht, lediglich Töne auszugeben, sondern Klänge zu formen. Drei unabhängige Stimmen, Hüllkurvensteuerung, unterschiedliche Wellenformen und ein analoger Filter machten aus dem Heimcomputer ein Instrument. Nicht perfekt, nicht berechenbar – aber lebendig. Und genau darin lag seine Besonderheit.

Der SID war kein Zufallsprodukt und kein nachträglich veredelter Beeper. Er entstand aus der Idee, dass ein Computer nicht nur rechnen, sondern auch klingen sollte. Und dieser Klang war nicht neutral. Er hatte Ecken, Widerstand und Persönlichkeit. Während andere Systeme sauberer, aber austauschbar wirkten, entwickelte der Commodore 64 eine akustische Identität, die man wiedererkannte, oft schon nach wenigen Takten – und die bis heute nachhallt.

Entwickelt wurde der SID bei MOS Technology, der Halbleitersparte von Commodore. Verantwortlich war Robert Yannes, ein Ingenieur mit ungewöhnlichem Profil: Er war Musiker. Diese Perspektive prägte den Chip hörbar. Sein Ziel war kein technischer Minimalbaustein, sondern etwas, das sich spielen ließ – ein kleiner Synthesizer, eingebaut in einen Heimcomputer, bezahlbar für Millionen. Der Zeitrahmen war knapp. Der Commodore 64 entstand in etwas mehr als einem Jahr, der SID selbst in wenigen Monaten. Perfektion im industriellen Sinne war dabei nicht erreichbar. Ausdruckskraft hingegen schon.

Robert Yannes blieb auch nach seiner Zeit bei Commodore dem Thema Klang treu, ohne noch einmal öffentlich in Erscheinung zu treten. Anders als viele später gefeierte Chip-Designer suchte er nie die Rolle des Visionärs oder Branchenstars. Er arbeitete in den folgenden Jahren weiterhin im Bereich digitaler Audiotechnik, unter anderem bei Ensoniq, wo Konzepte der Synthese und Klangformung in professionellere, samplerbasierte Systeme überführt wurden. In den neunziger Jahren zog sich Yannes zunehmend aus der sichtbaren Produktentwicklung zurück. Der SID blieb sein prägendstes Werk – und zugleich sein dauerhaftes Vermächtnis.

Der erste serienmäßig eingesetzte SID, der MOS 6581, verfügt über drei unabhängige Stimmen. Man kann sie sich wie drei kleine Instrumente vorstellen, die gleichzeitig erklingen können. Jede Stimme beginnt mit einer einfachen Wellenform, die das klangliche Rohmaterial liefert: mal weich, mal scharf, mal hohl oder körnig. Musik entsteht daraus erst durch Bewegung – durch das Einsetzen eines Tons, sein Anschwellen, sein Verweilen und sein Verklingen. Genau dafür sorgt der SID mit seiner internen Hüllkurvensteuerung. Klänge konnten atmen, stehen bleiben oder langsam ausklingen. Für einen Heimcomputer zu Beginn der achtziger Jahre war das außergewöhnlich.

Das eigentliche Herz des SID liegt jedoch im Filter. Vereinfacht gesagt entscheidet er, welche Anteile eines Klangs durchgelassen werden und welche verschwinden. Er kann Töne weichzeichnen oder schärfen, sie abdunkeln oder zum Kreischen bringen. Dieser Filter arbeitet analog – und genau das macht den Unterschied. Analog bedeutet hier: Nichts ist völlig festgelegt. Werte schwanken, Übergänge sind fließend. Kein SID klingt exakt wie ein anderer. Zwei Chips aus derselben Produktionscharge können hörbar unterschiedlich reagieren. Beim einen greift der Filter früh und sanft, beim anderen später und aggressiver. Das war nie als Klangkunst gedacht. Commodore wollte funktionierende Chips. Dass gerade diese Ungenauigkeit den SID so lebendig machte, gehört zu den stillen Ironien der Technikgeschichte.

Hinzu kommen elektrische Eigenheiten, die außerhalb der ursprünglichen Spezifikation lagen. Manche Töne starten nicht ganz sauber, Lautstärken reagieren gelegentlich unvorhersehbar, und ein bestimmter Nebeneffekt erlaubt das Abspielen digitaler Samples – obwohl der SID dafür nie vorgesehen war. Sprachfetzen, Schlagzeugklänge, Geräusche entstanden aus Tricks, die diese Eigenschaften gezielt ausnutzten. Commodore hätte das vermutlich gern vermieden. Musiker und Programmierer hingegen liebten es. Der SID war kein steriler Studioklang, sondern ein Instrument mit Macken – und genau das machte ihn greifbar.

Der MOS 6581 ist der Klang, den viele untrennbar mit dem Commodore 64 verbinden. Er klingt warm, rau, manchmal fast schmutzig. Seine Filter reagieren nicht immer gleich, sie greifen mal früher, mal später, gelegentlich stärker als erwartet. Bässe können knurren, Leads leicht verzerren, Flächen wirken beinahe organisch. Der MOS 6581 ist kein berechenbarer Chip. Er lässt sich nicht vollständig kontrollieren, sondern will erlebt werden. Für Musiker bedeutete das: Jeder SID war ein kleines Unikat. Viele klassische C64-Soundtracks wurden genau für diesen Charakter geschrieben – und klingen auf anderen SID-Varianten oft spürbar anders.

Der spätere MOS 8580 SID ist technischer, kontrollierter und sauberer. Er wurde entwickelt, um stabiler zu arbeiten und sich verlässlicher gleich zu verhalten. Sein Klang ist klarer, sein Verhalten vorhersehbarer. Wo der MOS 6581 schwankt, bleibt der MOS 8580 konstant. Das schafft Sicherheit, nimmt dem Klang jedoch etwas von seiner Wildheit. Der MOS 8580 ist der erwachsene SID – korrekt, kraftvoll, präzise, aber ohne jene kleinen Unsauberkeiten, die den alten Chip für viele so reizvoll machen.

Welche dieser beiden Varianten man bevorzugt, ist weniger eine Frage der Technik als der Erinnerung. Der Klang, den man zuerst gehört hat, prägt das Empfinden bis heute. Der SID war nie ein neutraler Maßstab, sondern immer ein persönliches Instrument. Deshalb gibt es nicht den einen „richtigen“ Klang, sondern viele gültige.

So eigenwillig der SID auch war – erst durch die Menschen, die ihn verstanden und spielten, entfaltete er sein volles Potenzial. Auf dem Commodore 64 entstand eine eigenständige Form der Computermusik, die sich deutlich von anderen Plattformen abhob. Rob Hubbard erkannte früh, dass sich mit drei Stimmen weit mehr erreichen ließ, als es die Spezifikationen vermuten ließen. Seine Musik zu Monty on the Run, International Karate oder Commando ließ den C64 größer klingen, als er war. Hubbard behandelte den SID nicht als Tonquelle, sondern als Instrument, das in Echtzeit geformt werden wollte.

Martin Galway schlug einen anderen Weg ein. Seine Arbeiten für Ocean Software, etwa Arkanoid, Wizball oder Times of Lore, wirkten atmosphärisch, beinahe filmisch. Galway nutzte den SID nicht nur rhythmisch, sondern emotional. Frühe digitale Samples erweiterten den Klangraum, ohne ihn zu dominieren. Für ihn war der SID weniger Technik als Material – etwas, aus dem sich Stimmungen formen ließen.

Im deutschsprachigen Raum prägte Chris Hülsbeck das Bild des SID nachhaltig. Mit Werkzeugen wie dem Soundmonitor trug er dazu bei, die Möglichkeiten des SID systematisch zugänglich zu machen. Hülsbeck beschrieb den Commodore 64 später mehrfach als seinen ersten bezahlbaren Synthesizer – ein Instrument, das ihm eine musikalische Welt eröffnete, die außerhalb des Computers unerreichbar gewesen wäre.

Komponisten wie Jeroen Tel, Ben Daglish, David Whittaker, Tim Follin oder die Maniacs of Noise formten gemeinsam eine Klanglandschaft, die den Commodore 64 unverwechselbar machte. Ihre Musik überlebte die Spiele, für die sie geschrieben wurde, und wird bis heute gehört, aufgeführt und neu interpretiert. Der SID war kein neutraler Standard, sondern ein Instrument mit Widerstand. Er verlangte Geduld, Aufmerksamkeit und Experimentierfreude – und belohnte genau das mit individueller Handschrift.

Dass der SID bereits zu Lebzeiten mehr war als ein bloßes Bauteil, zeigt ein bemerkenswertes Experiment außerhalb der Commodore-Welt. 1989 erschien mit der Innovation SSI-2001 eine Soundkarte für IBM-PC-Kompatible, die einen originalen SID-Chip verwendete. Zu einem Zeitpunkt, als AdLib etabliert, Roland professionell positioniert und Sound Blaster auf dem Weg zum Quasi-Standard war, wirkte sie wie ein bewusstes Gegenmodell. Ihr kommerzieller Erfolg blieb gering, die Zahl der unterstützten Spiele klein, beispielsweise Ultima V: Warriors of Destiny. Doch ihre Existenz zeigt, dass der SID bereits damals als eigenständige Klangästhetik verstanden wurde – als etwas, das man bewusst in ein fremdes Umfeld tragen wollte.

Mit der SSI-2001 wurde zugleich sichtbar, dass der SID bereits einer auslaufenden Idee angehörte. Der MOS Technology 6581/8580 SID war einer der letzten frei programmierbaren Soundgeneratoren, bei denen Klang noch synthetisch erzeugt und analog geformt wurde. In den späten achtziger Jahren verlagerte sich der Markt. AdLib setzte auf FM-Synthese, Sound Blaster auf digitale Samples, der Amiga spielte Klänge ab, statt sie zu entwerfen. Musik wurde reproduzierbar – und damit auch austauschbarer.

Der SID markiert vor diesem Hintergrund keinen Rückstand, sondern einen Endpunkt. Er steht am Abschluss einer Epoche, in der Computermusik aus Parametern, Spannungen und Grenzwerten entstand. Was mit ihm verschwand, war nicht nur eine Technik, sondern eine Haltung: der Zwang zur Reduktion, zur Erfindung, zum genauen Hinhören. Spätere Systeme klangen realistischer, lauter und sauberer, doch sie verloren etwas, das sich nicht messen lässt.

Rückblickend erklärt sich die Faszination des SID weniger aus Zahlen oder Spezifikationen als aus seiner Haltung. Musik auf dem Commodore 64 war kein Abspielvorgang, sondern ein Dialog zwischen Mensch und Maschine. Der SID blieb als Erinnerung an eine Zeit, in der Beschränkung kein Mangel war, sondern Voraussetzung für Stil. Nicht weil er alles konnte – sondern weil er Widerstand leistete.

Commodore Amiga A501

Picture by: https://www.valoroso.it/en/commodore-501-battery-replacement/

Als Commodore 1987 die Speichererweiterung A501 für den Amiga 500 veröffentlichte, traf das Unternehmen einen Nerv der Zeit. Der Amiga 500 war bereits populär, doch viele Anwendungen stießen mit seinen 512 KB Chip RAM schnell an Grenzen. Mit der trapdoor-Erweiterung auf 1 MB Gesamt-RAM wurde der Rechner deutlich vielseitiger – und viele Programme erst richtig einsetzbar.

Die A501 bestand aus einer kompakten Platine mit 512 KB zusätzlichem RAM sowie einer integrierten Echtzeituhr (RTC) inklusive verlöteter Batterie. Eingesteckt wurde sie durch die Wartungsklappe an der Unterseite – ein unkompliziertes Upgrade, das ohne Kabel oder externe Module auskam. Für Heimanwender und ambitionierte Amiga-Fans war dies der klassische „Erwachsenwerden“-Moment ihres Systems.

Um den technischen Nutzen dieser Erweiterung wirklich zu verstehen, lohnt sich ein Blick auf die Speicherkategorie des Amiga-Systems. Commodore unterschied zwischen Chip RAM – vom Prozessor und den Custom Chips nutzbar – und Fast RAM, das nur der CPU zur Verfügung stand und daher echte Leistungszuwächse brachte. Zusätzlich existierte Slow RAM, technisch zwar Erweiterungsspeicher, aber über denselben Bus angeschlossen wie die Custom-Chips – und dementsprechend mit längeren Wartezyklen für die CPU verbunden.

Ein Experte brachte es einmal formvollendet auf den Punkt: „Fast memory is available exclusively for use by the CPU … the CPU is able to operate without being delayed if its instructions and data are in fast memory.“ („Fast-Speicher steht ausschließlich der CPU zur Verfügung … die CPU kann arbeiten, ohne ausgebremst zu werden, wenn ihre Anweisungen und Daten im Fast-Speicher liegen.“)

Damit wurde klar: Die A501 brachte mehr Speicher, aber nicht automatisch mehr Geschwindigkeit.

Besonders interessant ist die Einbindung der Erweiterung je nach Revision des Amiga-500-Mainboards. Frühere Revisionen (z. B. Rev. 5) nutzten die A501 standardmäßig als Slow RAM. Bei der Rev. 6A hingegen konnte die Speichererweiterung als Chip RAM erkannt werden – sofern ein kompatibler Agnus-Chip (z. B. 8372A/8375 für 1 MB Chip RAM) verbaut war und zwei Jumper angepasst wurden:

JP2 – Adress-Mapping für den Trapdoor-Speicher
JP7A – EXRAM-Signal-Routing am GARY-Chip

Ohne diese Modifikation blieb die A501 auch auf Rev. 6A weiterhin Slow RAM.
Das war ein technischer Kniff, den längst nicht jeder Amiga-Besitzer umsetzte – häufig blieb das Potenzial der A501 ungenutzt.

Ein Forumsnutzer kommentierte treffend: „On the A500, 2 MB in the trap door is not really worthwhile… the rest is Slow RAM.“ („Beim A500 lohnen sich 2 MB im Trapdoor-Slot nicht wirklich … der Rest ist Slow RAM.“)

Die A501 war somit vor allem eine Nutzbarkeitserweiterung, keine Geschwindigkeitskur. Anwendungen wie Deluxe Paint, Protracker, Textverarbeitung, komplexere Spiele oder sogar erste 3D-Experimente profitierten dennoch enorm: mehr Platz für Bitmaps, mehr Sample-Speicher, größere Buffers.

Auch die integrierte Echtzeituhr war ein Pluspunkt – besonders für professionelle Anwender. Allerdings sorgte die verlötete NiCd-Batterie dafür, dass viele A501-Module später durch auslaufende Akkus beschädigt wurden – ein heute bekanntes Restaurierungsproblem, das Retro-Techniker stets zuerst prüfen.

Heute ist die A501 nicht nur ein praktisches Upgrade, sondern ein wichtiges Kapitel Amiga-Geschichte: Sie steht für Erweiterbarkeit, für Nutzerfreundlichkeit – und für die besondere technische Raffinesse der Amiga-Architektur, in der Speicherdetails großen Unterschied machten.

Während andere Systeme in MB prahlten, zeigte die A501, dass 0,5 MB zur richtigen Zeit ganze Welten öffnen konnten. Sie war keine Speerspitze der Performance – aber ein Schlüssel zu mehr Kreativität, mehr Software und einem längeren Leben des Amiga 500.