Der 6502 Mikroprozessor gilt als eine der bedeutendsten CPUs der frühen Heimcomputer-Ära. Bekannt für seine Einfachheit, Leistung und günstige Herstellung, wurde er vielfach in Geräten von Commodore, Apple, Atari und vielen anderen eingesetzt. Dabei fanden sich im Laufe der Zeit auch sogenannte „illegale“ oder „unstable“ Opcodes, also Befehle, die von der offiziellen Dokumentation der Hersteller nie offiziell unterstützt wurden, aber durch Besonderheiten der Hardware dennoch ausführbar waren. Diese geheimen Befehle erregten großes Interesse bei Programmierern und Hobbybastlern, da sie teils spezielle Funktionen ermöglichten, die über das übliche Repertoire hinausgingen. Was jedoch kaum jemand erwartet hätte: Das Siemens PC 100 Assembly Handbuch von 1980 enthält tatsächlich eine bizarre und ausführliche Beschreibung dieser illegalen Opcodes – eine Seltenheit bei einem großen Elektronikkonzern wie Siemens. Die Hintergründe des Siemens PC 100 Systems sind dabei besonders spannend.
Es handelt sich um ein in den frühen 1980er Jahren erschienenes Einplatinencomputer-System, das sich am Rockwell AIM-65 orientierte, aber mit einem eigenen Gehäuse, integrierter Tastatur, LED-Anzeige und einem Thermodrucker ausgestattet war. Ziel war eine Kombination aus Lernplattform und Entwicklungsumgebung, für die Siemens umfangreiche, in leicht verständlichem Deutsch abgefasste Dokumentationen bereitstellte. Interessanterweise war das Handbuch weitgehend auf Rockwell-Originale zurückgeführt, wenn auch mit eigener inhaltlicher Anordnung und Ergänzungen. Besonders aufschlussreich ist der Assembly-Teil, in dem auf den letzten Seiten ein Abschnitt zu sogenannten „Sonderbefehlen“ auftaucht, eben jene illegalen Opcodes, die sonst nirgends offiziell erwähnt wurden. Diese „Sonderbefehle“ sind im Handbuch als spezielle Mikroprozessor-Anweisungen beschrieben, die im 6502 eigentlich nicht vorgesehen sind, aber je nach Implementierung mitunter beobachtet oder verwendet werden konnten.
Siemens schreibt ausdrücklich, dass diese Befehle nicht Teil der offiziellen Spezifikation seien und jederzeit ohne Vorwarnung geändert werden könnten. Zudem wies Siemens darauf hin, dass der hauseigene Assembler diese „Special Instructions“ nicht dekodieren kann – sie müssen per . BYT-Direktive programmiert werden, also als rohe Bytes eingefügt werden. Das unterstreicht den experimentellen Charakter der Opcodes und die mangelnde Stabilität ihrer Verwendung. Zu den im Handbuch genannten Befehlen gehört etwa der AAX-Befehl, welcher eine logische UND-Verknüpfung zwischen dem Akkumulator und dem X-Register ausführt, deren Ergebnis in den Speicher geschrieben wird. Dabei wird differenziert zwischen den Adressierungsmodi Zero Page, Zero Page,Y sowie absolut, wobei im letzten Fall ein konstanter Wert ($02) als Maske angewandt wird. Ebenso wird der DCM-Befehl erläutert, der eine Speicherzelle um eins dekrementiert und das Ergebnis anschließend mit dem Akkumulator vergleicht.
Dieses Verhalten ist für die Entwicklung von Programmen durchaus nützlich, zeigt aber im Kontext der nicht standardisierten Opcodes auch Flag-Veränderungen, die von der Standardpraxis abweichen können. Ein weiterer beachtenswerter Befehl ist LAX, der sowohl den Akkumulator als auch das X-Register gleichzeitig lädt. Das Besondere ist, dass der Programmierer hier zwei Register in einem Befehl befüllt, was sonst nur unter hohem Aufwand realisierbar ist. Siemens gibt für verschiedene Adressierungsarten sowohl den Opcode als auch den erwarteten Maschinencode an. Jedoch bemerkt das Handbuch, dass der LAX-Befehl nicht immer korrekt ausgeführt wird, was auf hardwarebedingte Unstabilitäten zurückgeführt werden kann. Auch der ISB-Befehl wird beschrieben, der eine Speicherzelle um eins inkrementiert und dann den neuen Wert vom Akkumulator subtrahiert.
Dieses Verhalten führt zu einer kombinierten Effektivität, die gerade in Schleifen oder Konditionstest-Strukturen in Assemblerprogrammen interessant sein kann. Die sich daraus ändernden Prozessorflags weisen erneut auf eine leichte Abweichung von der Standardfunktionalität hin. Die Dokumentation durch Siemens umfasst nicht nur die Beschreibung der Opcode-Befehle, sondern auch eine Aufstellung, welche Flags bei der Ausführung verändert werden. Für den unbedarften Anwender mag dies komplex wirken, doch gerade für versierte Programmierer bietet diese Information wertvolle Hilfestellungen bei der Nutzung und Einordnung dieser unüblichen Befehle. Wichtig ist zu betonen, dass Siemens bei dieser Dokumentation keinesfalls komplett war. So fehlen im Handbuch viele weitere bekannte illegale Opcodes und Adressierungsmodi, die in späteren Analysen und Magazinen der 1980er Jahre offengelegt wurden.
Dies legt nahe, dass die Siemens-Autoren entweder eigene Experimente durchführten oder Informationen von externen Quellen zusammengetragen haben, ohne dabei den gesamten Umfang der illegalen Opcodes zu kennen oder zu testen. Besonders auffällig ist der Umgang mit den Opcodes 9E und 9F, welche im Siemens-Handbuch als AAX Befehle mit absoluter Adressierung und konstantem Wert ($02) gekennzeichnet sind. Tatsächlich stellte sich später heraus, dass diese Angaben nicht zutreffend sind: Diese Opcodes funktionieren zumindest nicht in dieser Form und wurden wahrscheinlich falsch verstanden oder fehlinterpretiert. Siemens bezeichnet sie selbst als instabil und rät explizit dazu, sie eher nicht zu verwenden. Diese kritische Einschätzung ist bemerkenswert, da offizielle Dokumentationen selten solche Warnungen enthielten. Im Kontext historischer Computerarchäologie und der Erforschung alter Hard- und Software ist die Siemens-Dokumentation daher ein wertvolles Zeitdokument.
Sie zeigt zum einen, wie in den frühen 80er Jahren der Zugang und die Nutzung von Mikroprozessorfunktionen auch außerhalb offizieller Spezifikationen stattfand. Zum anderen erlaubt sie Rückschlüsse auf den damaligen Stand der Forschung, den Stand der technischen Analysen und die besonderen Herausforderungen bei der Arbeit mit 8-Bit-Prozessoren wie dem 6502. Die Illegalen Opcodes boten damals oftmals Wege, den ohnehin begrenzten Ressourcenbeständen des Systems mehr Leistung abzuringen. Manchmal dienten sie auch als Hack, um Funktionen zu realisieren, die mit den regulären Befehlen nicht oder nur umständlich möglich waren. Doch die Instabilität und die fehlende Dokumentation bedeuteten auch erhebliche Risiken: Programme, die illegale Opcodes verwendeten, konnten auf anderen 6502-Systemen anders oder gar nicht funktionieren.
Im Fall des Siemens PC 100 war die bisherige Forschung und dokumentierte Analyse allerdings relativ lückenhaft, sodass das Auffinden und Medialisieren des Siemens Assembly Handbuchs mit seinen „Sonderbefehlen“ eine kleine Sensation darstellt. Die heutigen Informatik- und Computerarchäologisch interessierten Kreise profitieren enorm davon, dass solche Quellen digital konserviert und interpretiert werden – sie ermöglichen ein besseres Verständnis des ursprünglichen Mikroprozessordesigns und dessen Nutzung in der Historie. Zusammenfassend lässt sich sagen, dass das Siemens PC 100 Assembly Handbuch aus dem Jahr 1980 eine seltene, wertvolle Quelle für die Dokumentation der 6502 illegalen Opcodes darstellt. Es spiegelt sowohl den Pioniergeist als auch die Risiken wider, die mit nicht standardisierten Prozessorbefehlen verbunden waren.
Die technische Beschreibung, die Warnhinweise und die originale Einordnung im Handbuch geben heute Programmierern und Historikern wertvolle Einblicke in die Welt des frühen Computings. Für alle, die sich mit dem 6502 Prozessor, der Geschichte der Mikroprozessortechnik oder der Assemblersprache auseinandersetzen, bietet das Handbuch von Siemens eine einzigartige Perspektive, die sowohl technische Details als auch historischen Tiefgang vereint. Es zeigt, dass selbst große Industrieunternehmen wie Siemens sich mit den „Ecken und Kanten“ der damals eingesetzten Technologie auseinandersetzten und dieses Wissen ihren Kunden nicht vorenthielten – auch wenn gewisse Aspekte als experimentell und nicht stabil eingestuft wurden. Das Interesse an den 6502 illegalen Opcodes lebt heute in Retro-Computing-Kreisen und in der Programmierung von Emulatoren weiter.
Diese Befehle sind ein faszinierendes Beispiel dafür, wie weit sich das Verständnis und die Nutzung von Hardware jenseits der standardmäßigen Spezifikationen ausdehnen können – und wie wichtig die Dokumentation solcher Phänomene für das historische Verständnis von Technik ist.
