Cracking-Trivia: Von Kopierschutz-Battles und Demo-Kunst

~22 Min. Lesezeit24. Okt. 2026

Cracking-Trivia: Von Kopierschutz-Battles und Demo-Kunst

Lesehinweis: Diese Trivia ist zum gezielten Nachlesen und Stöbern gedacht. Alle Abschnitte sind unabhängig voneinander lesbar.

Auf manchen Originaldisketten steckten absichtlich fehlerhafte Bits. Andere Spiele verlangten ein Wort aus dem Handbuch oder verhinderten erst Stunden nach dem Start das Weiterspielen. Im ersten Teil geht es um diese Schutzverfahren und darum, wie Cracker sie umgingen.

Der zweite Teil beschäftigt sich mit der praktischen Arbeit an einem Crack. Ein Intro musste vor das Spiel gesetzt werden, ohne dessen Start zu beeinträchtigen. Auf C64 und Atari ST waren dafür andere Eingriffe nötig als unter DOS. Bei Konsolen mit Steckmodulen kamen weitere technische Hürden hinzu.

Hinter den Cracks und Intros standen Gruppen, deren Namen viele Heimcomputerbesitzer kannten. Fairlight, Triad und Razor 1911 gehörten dazu. Manche dieser Gruppen veröffentlichten neben Cracks auch Demos; andere widmeten sich später ganz der Demoszene.

Zum Schluss geht es um die Tricks der Demoszene. Programmierer fanden Wege, alte Grafikchips für Effekte zu nutzen, die in den üblichen Grafikmodi nicht vorgesehen waren.

Kopierschutz: Hersteller vs. Cracker

Einige Kopierschutzverfahren nutzten ungewöhnliche Eigenschaften der Diskette. Andere überprüften Daten im Programmcode oder verlangten Informationen aus einem beigelegten Handbuch.

Die Cracker mussten herausfinden, welche Prüfung den Spielstart oder das Weiterspielen verhinderte. Je nach Verfahren suchten sie nach einer Abfrage im Programm oder nach einem Erkennungsmerkmal auf dem Datenträger.

1. Dungeon Master – Bits, die sich nicht entscheiden konnten

System: Atari ST
Der Schutz: Fuzzy Bits

Auf der Originaldiskette von Dungeon Master befand sich ein Bereich mit sogenannten Fuzzy oder Weak Bits. Sie waren so aufgezeichnet, dass das Laufwerk beim wiederholten Lesen unterschiedliche Werte zurücklieferte. Solche Schwankungen galten sonst als Hinweis auf eine beschädigte Diskette. Hier waren sie beabsichtigt.

Warum normales Kopieren scheiterte: Ein gewöhnliches Laufwerk schrieb eindeutige Nullen und Einsen auf die Diskette. Beim Kopieren verschwanden dadurch die schwankenden Werte des Originals. Die neue Diskette ließ sich anschließend zuverlässig lesen, und ausgerechnet das verriet sie als Kopie.

Was der Cracker tun musste: Die besondere Magnetisierung ließ sich mit einem normalen Laufwerk nicht nachbilden. Der Cracker musste daher herausfinden, an welcher Stelle das Spiel die wechselnden Werte überprüfte, und diese Kontrolle umgehen.

Warum das bemerkenswert war: Der Schutz beruhte auf einer Eigenschaft des Datenträgers, die beim gewöhnlichen Kopieren verloren ging. Ein scheinbarer Fehler wurde zum Echtheitsmerkmal.

2. Rob Northen Copylock – Lesbar, aber nicht schreibbar

System: Atari ST und Amiga
Der Schutz: Copylock

Rob Northens Copylock verwendete speziell gemasterte Diskettenbereiche. Die Abstände zwischen den magnetischen Bitzellen waren so angelegt, dass gewöhnliche Laufwerke die Daten noch lesen, beim Schreiben aber nicht reproduzieren konnten.

Hinzu kamen verschlüsselter Programmcode und Schutzmaßnahmen gegen die Analyse. Rund 500 kommerzielle Amiga-Spiele sollen zwischen 1988 und 1996 mit Copylock ausgeliefert worden sein.

Warum normales Kopieren scheiterte: Das Laufwerk erkannte die ungewöhnlichen Daten auf dem Original. Beim erneuten Schreiben erzeugte es sein normales Timing. Die Daten blieben lesbar, doch das physische Erkennungsmerkmal des Originals fehlte.

Was der Cracker tun musste: Er konnte versuchen, die geschützten Bereiche mit geeigneter Spezialhardware zu kopieren. Für einen Crack musste er jedoch die verschlüsselte Prüfroutine analysieren und so verändern, dass das Spiel auch ohne gültige Copylock-Diskette startete.

Warum das bemerkenswert war: Copylock verband einen schwer reproduzierbaren Datenträger mit verschleiertem Maschinencode. Selbst nachdem die Prüfung auf der Diskette verstanden war, musste der Cracker noch herausfinden, wie die Software das Ergebnis verarbeitete.

3. Hook – Der Kopierschutz schlägt später zu

System: Amiga
Der Schutz: Versteckte Folgeprüfung

Hook verwendete ebenfalls Rob Northens Copylock. Eine zweite Kontrolle lief erst während des Spiels. Schlug sie fehl, entfernte das Programm einen Gegenstand, den der Spieler später zum Weiterkommen brauchte. Eine frühe gecrackte Fassung soll diese zweite Prüfung übersehen haben.

Warum ein erster Crack unvollständig blieb: Nach dem Ausschalten des Startschutzes ließ sich das Spiel zunächst problemlos spielen. Die Folgen der übersehenen Prüfung zeigten sich erst später und wirkten zunächst wie ein gewöhnlicher Spielfehler.

Was der Cracker tun musste: Das erfolgreiche Starten reichte als Funktionsnachweis nicht aus. Auch die später ausgeführten Prüfungen mussten aufgespürt und ihre Auswirkungen auf den Spielablauf untersucht werden.

Warum das bemerkenswert war: Ein Crack konnte technisch funktionieren und das Spiel trotzdem unspielbar machen. Solche verzögerten Kontrollen verlangten gründliche Tests über den Programmstart hinaus.

4. Electronic Arts – Die zu breite Spur

System: Commodore 64
Der Schutz: Fat Tracks

Electronic Arts verwendete bei verschiedenen C64-Veröffentlichungen sogenannte Fat oder Wide Tracks. Professionelle Duplizieranlagen konnten einen Bereich der Diskette so breit beschreiben, dass sich dieselben Daten auch an benachbarten Kopfpositionen lesen ließen. Ein gewöhnliches 1541-Laufwerk schrieb dagegen nur eine schmale Spur.

Warum normales Kopieren scheiterte: Die gespeicherten Daten ließen sich übernehmen. Ihre ungewöhnliche Verteilung auf der Diskette ging dabei verloren. Das Spiel konnte diesen Unterschied durch gezielte Zugriffe auf benachbarte Spurpositionen erkennen.

Was der Cracker tun musste: Er musste die Abfrage der breiten Spur finden und ausschalten oder dafür sorgen, dass die Prüfroutine das erwartete Ergebnis erhielt.

Warum das bemerkenswert war: Zwei Disketten konnten denselben Dateninhalt besitzen und sich beim Lesen trotzdem unterschiedlich verhalten. Der Kopierschutz steckte hier in der räumlichen Anordnung der Magnetisierung.

5. V-MAX! – Eine Diskette außerhalb der Regeln

System: Commodore 64
Der Schutz: V-MAX!

V-MAX! kam bei verschiedenen Publishern zum Einsatz und wurde über mehrere Versionen weiterentwickelt. Das System verwendete ungewöhnlich lange Tracks, abweichende Datenformate und besondere Synchronisationsmuster. Einige Varianten stellten selbst spezialisierte Kopierprogramme vor Schwierigkeiten, weil sich die ursprüngliche Aufzeichnung mit einem gewöhnlichen Laufwerk nicht zuverlässig reproduzieren ließ.

Warum normales Kopieren scheiterte: Standardkopierprogramme waren auf bekannte Diskettenstrukturen ausgelegt. V-MAX! verwendete eigene Formate, die sich mit diesen Werkzeugen nicht vollständig erfassen ließen. Bei manchen Varianten reichte bereits das gewöhnliche Diskettenabbild nicht aus, um alle benötigten Informationen zu speichern.

Was der Cracker tun musste: Abhängig von der Version konnte er versuchen, die Rohstruktur mit spezialisierten Kopierprogrammen zu übernehmen. Alternativ musste der eigene Loader analysiert und die Schutzprüfung aus dem Spiel entfernt werden.

Warum das bemerkenswert war: V-MAX! kombinierte mehrere Schutzmechanismen, die sich von Version zu Version unterscheiden konnten. Ein Crack für eine Fassung half bei der nächsten nicht zwangsläufig weiter.

6. Vorpal – Timing als Fingerabdruck

System: Commodore 64
Beispiel: Summer Games II
Der Schutz: Vorpal

Epyx setzte Vorpal bei verschiedenen Veröffentlichungen ein. Frühe Fassungen überprüften unter anderem die Anzahl und Position bestimmter Synchronisationsmarken auf einer Diskette.

Spätere Varianten bezogen auch ungewöhnliche zeitliche Abstände und speziell gemasterte Tracks ein. Mit Vorpal geschützte Fassungen von Summer Games II sind dokumentiert.

Warum normales Kopieren scheiterte: Ein Kopierprogramm konnte den Dateninhalt übernehmen, ohne die ursprünglichen zeitlichen Abstände zu erhalten. Das Laufwerk schrieb die Informationen in einer regulären Struktur zurück. Die Schutzroutine erkannte das veränderte Timing.

Was der Cracker tun musste: Er musste untersuchen, welche Synchronisationsmuster und Zeitabstände der Loader überprüfte. Anschließend ließ sich die Kontrolle verändern oder umgehen.

Warum das bemerkenswert war: Vorpal bezog auch die Abstände und Positionen bestimmter Synchronisationsmarken in die Prüfung ein. Eine Kopie mit denselben Nutzdaten konnte daran scheitern, dass diese Anordnung beim Schreiben verändert worden war.

7. Speedlock – Der Kopierschutz war schon im Geräusch zu hören

System: ZX Spectrum
Der Schutz: Speedlock

Beim ZX Spectrum wurden Programme häufig von Kassette geladen. Speedlock verwendete dafür einen eigenen schnellen Loader, dessen Aufzeichnung vom üblichen Sinclair-Kassettenformat abwich.

Zum Verfahren gehörten spezielle Pilot- und Synchronisationssignale. Die Programmdaten konnten verschlüsselt sein, und weitere Schutzmechanismen erschwerten die Untersuchung des Ladevorgangs. Im Lauf der Jahre entstanden mehrere Generationen von Speedlock.

Warum normales Kopieren scheiterte: Die Informationen lagen in einem Format vor, das gewöhnliche Kopierprogramme nicht ohne Weiteres verarbeiten konnten. Selbst die Abfolge von Tönen und Pausen konnte für den Loader eine Bedeutung haben.

Was der Cracker tun musste: Der Cracker musste den Loader und seine Entschlüsselung untersuchen. Danach konnte er das geladene Programm in eine leichter nutzbare Form bringen. Zeitgenössische Hacking-Anleitungen beschrieben ausführlich, wie sich die unterschiedlichen Speedlock-Versionen zerlegen ließen.

Warum das bemerkenswert war: Bei einem Kassettenprogramm waren die Ladesignale als Pfeifen und Rauschen hörbar. Speedlock nutzte ein eigenes Signalformat, das auch Kopierprogramme vor Probleme stellte. Das Geräusch allein verriet allerdings nicht, ob ein Kopierschutz vorhanden war.

8. Apple II – Daten zwischen den Spuren

System: Apple II
Der Schutz: Half Tracks und Nibble Count

Beim Apple II ließ sich die Diskettenhardware direkt und flexibel ansteuern. Entwickler nutzten diese Freiheit für Schutzverfahren außerhalb der normalen Datenstrukturen.

Manche Spiele speicherten Informationen zwischen den regulären Spuren. Andere überprüften die Länge eines Tracks anhand seiner Rohdaten und verglichen sie mit einem vorgegebenen Wert.

Warum normales Kopieren scheiterte: Ein Standardkopierer bearbeitete die erwarteten Spuren und ihre üblichen Datenformate. Eine Spur an der Position 1,5 passte ebenso wenig in dieses Schema wie eine absichtlich veränderte Tracklänge.

Was der Cracker tun musste: Spezialisierte Nibble-Kopierprogramme konnten auch ungewöhnliche Track- und Sektorstrukturen erfassen. Für Half Tracks musste das Programm außerdem die betreffende Kopfposition ansteuern können; das gelang nicht mit jeder Laufwerkskombination. Als anderer Weg blieb die Änderung der Schutzroutine im Spiel. Das moderne Werkzeug Passport automatisiert zahlreiche solcher Eingriffe.

Warum das bemerkenswert war: Das Betriebssystem ging von einem festgelegten Diskettenformat aus. Die Hardware konnte Spuren und Rohdaten lesen, die in diesem Schema gar nicht vorkamen.

9. Lenslok – Das Prisma als Kopierschutz

Systeme: Unter anderem ZX Spectrum und C64
Bekanntes Beispiel: Elite
Der Schutz: Lenslok

Lenslok war ein kleines Prisma aus Kunststoff, das dem Originalspiel beilag. Auf dem Bildschirm erschien ein verzerrter Code, der sich erst durch das Prisma lesen ließ. Zuvor musste die Darstellung an die Bildschirmgröße angepasst werden.

Warum die Kopie allein nicht genügte: Die Programmdaten ließen sich kopieren, aber ohne das beigelegte Prisma konnte der Spieler den verzerrten Code nicht lesen.

Was der Cracker tun musste: Er konnte die Codeabfrage aus dem Programm entfernen oder dafür sorgen, dass jede Eingabe akzeptiert wurde.

Warum das bemerkenswert war: Lenslok machte aus dem Kopierschutz eine Geduldsprobe für Käufer des Originals. Zuerst musste die Darstellung an die Bildschirmgröße angepasst werden, dann das Prisma in der richtigen Position vor den Monitor gehalten werden, um den verzerrten Code lesen zu können. Das war umständlich und fehleranfällig. Ein Crack ersparte dem Spieler diese Prozedur.

10. Handbuch und Codewheel – Ohne Papier kein Spiel

Systeme: Heimcomputer und PCs
Beispiele: Pirates! und The Secret of Monkey Island

Viele Spiele verlangten Informationen aus dem mitgelieferten Handbuch oder von einer Codescheibe. Gesucht wurde etwa ein Wort aus einer bestimmten Zeile oder eine Zahl, die sich durch das Einstellen einer Scheibe ergab.

The Secret of Monkey Island verwendete dafür sein bekanntes „Dial-A-Pirate“. Auf dem Bildschirm erschien ein Piratengesicht, zu dem der Spieler mithilfe der Codescheibe die passende Jahreszahl finden musste.

Pirates! kombinierte in seiner C64-Fassung zwei Schutzverfahren. Die Diskette war mit RapidLok geschützt. Zusätzlich fragte das Spiel Informationen aus der Dokumentation ab. Auch nach einer erfolgreichen Diskettenkopie blieb diese Abfrage bestehen.

Warum die Kopie allein nicht genügte: Auf der Kopie lief dieselbe Abfrage wie auf dem Original. Ohne Handbuch oder Codescheibe fehlte die verlangte Antwort.

Was der Cracker tun musste: Er konnte die Abfrage entfernen, jede Antwort akzeptieren lassen oder eine Tabelle mit den benötigten Codes beilegen.

Warum das bemerkenswert war: Der Schutz machte das Spielen von Zubehör abhängig, das bei einer kopierten Fassung häufig fehlte. Eine gecrackte Version ersparte die wiederkehrende Suche nach Wörtern oder das Einstellen der Codescheibe.

Der eigentliche Wettstreit

Mal musste ein Cracker das Timing eines Laufwerks verstehen, mal verschlüsselten Maschinencode untersuchen. Bei einer Handbuchabfrage reichte dagegen mitunter eine kleine Änderung im Programm.

Für den Spieler zählte, dass sich das Spiel ohne die ursprünglichen Prüfungen durchspielen ließ. Wie viel Arbeit dahintersteckte, war am fertigen Release selten zu erkennen. Die Cracker mussten dafür die wirksamen Kontrollen im Spiel finden und umgehen, gelegentlich auch solche, die erst spät im Spielverlauf ausgeführt wurden.

Cracks und Cracktros: Wie sie entstanden

Ein Cracktro gehörte ursprünglich nicht zum Spiel. Es wurde von der Szene nachträglich programmiert und mit eigenen Grafiken versehen. Häufig kam eine eigens komponierte Musik hinzu.

Je nach Plattform stellten sich dabei andere Probleme. Auf dem C64 mussten Intro und Spiel mit demselben knappen Arbeitsspeicher auskommen, während DOS eigenständige Startprogramme erlaubte. Bei den Konsolen bestimmten ROM-Speicherzuordnung und CD-Formate, wo sich zusätzlicher Code unterbringen ließ.

1. C64 – Intro davor, Spiel dahinter

Auf dem C64 konnten sogenannte Linker ein fertiges Intro vor das Hauptprogramm setzen. Beim Start erschien zunächst das Cracktro. Nach einem Tastendruck oder Druck auf den Feuerknopf übergab es die Kontrolle an das Spiel.

Bei späteren Cracktros wurde das Spiel schon im Hintergrund geladen, während Logo und Scrolltext noch über den Bildschirm liefen. Dafür musste der Speicher sorgfältig aufgeteilt werden.

Packer und Cruncher komprimierten den Maschinencode und schufen Platz für das Intro. Bei einem sogenannten One-Filer bestand das fertige Paket aus einer einzigen Datei. Einige Packprogramme entwickelten die Cracker eigens für ihre Arbeit.

Das Handwerk: Bei einem One-Filer musste der Entpacker die Spieldaten wieder an ihre ursprünglichen Speicheradressen schreiben. Dabei durfte er weder seinen eigenen Code noch die noch nicht entpackten Daten überschreiben. Für Cracktros, die während des Nachladens Musik und Animation zeigten, kam ein weiteres Problem hinzu: Viele schnelle Diskettenloader unterbrachen dafür die Interrupts. Die Szene entwickelte deshalb auch Laderoutinen, bei denen Musik und Bildschirmeffekte weiterlaufen konnten.

2. C64 – Einfrieren, sichern und analysieren

Für die Untersuchung von Spielen standen Maschinensprache-Monitore und sogenannte Freezer-Module zur Verfügung. Mit ihnen ließ sich ein laufendes Programm anhalten und sein Speicherinhalt untersuchen oder auf Diskette sichern. Je nach Speicherbelegung und Schutzmechanismus funktionierte das allerdings nicht bei jedem Spiel.

So konnten Cracker auch Maschinencode untersuchen, der erst während der Ausführung entschlüsselt worden war. Im ursprünglichen Programm auf der Diskette lag dieser Code noch verschlüsselt vor.

Das Handwerk: Ein Freezer konnte den Arbeitsspeicher sichern, aber nicht jeden Zustand der Hardware erfassen. Bestimmte Register von VIC-II, SID und CIA ließen sich nicht vollständig zurücklesen. Auch der Speicher des Diskettenlaufwerks 1541 gehörte nicht zum Abbild. Lief dort ein eigener Schnelllader, konnte das Fortsetzen scheitern, obwohl der RAM-Inhalt des C64 gesichert worden war.

3. Atari ST – Manchmal war das Intro schwieriger als der Crack

In erhaltenen Scrolltexten berichten Cracker selbst vom Aufwand ihrer Arbeit. Sie beschreiben dort auch Schwierigkeiten beim Einbauen und Packen ihrer Intros.

Beim Crack von Colonel’s Bequest schrieb ein Cracker 1990, dass für das Umgehen des eigentlichen Schutzes nur ein einzelnes Bit unter mehreren Megabyte Daten verändert werden musste. Das anschließende Einbauen und Packen des Intros habe erheblich mehr Arbeit verursacht.

Bei Starglider II musste der Cracker für die fertige Version mit Intro und gepacktem Hauptprogramm ein eigenes Packprogramm entwickeln. Allein daran habe er rund zwölf Stunden gearbeitet.

Das Handwerk: Beim Start einer gepackten Fassung mussten Intro, komprimierte Spieldaten und Entpacker zunächst im selben Arbeitsspeicher Platz finden. Während des Entpackens wurde aus den gespeicherten Daten ein größeres Programm. Dessen Zielbereich durfte weder den noch benötigten Datenstrom noch den Entpacker selbst überschreiben. Diese Speicheraufteilung musste zum Aufbau des jeweiligen Spiels passen; ein vorhandener Packer eignete sich deshalb nicht für jede Fassung.

4. DOS-PC – Das Intro musste nicht einmal im Spiel stecken

Auf DOS-PCs konnte ein Cracktro als eigenständige ausführbare Datei vorliegen und vor dem Spiel gestartet werden. Das erhaltene DOS-Release von Rock’n Roll enthält etwa eine INTRO.EXE und daneben ein kleines RUNME.COM.

Zum Komprimieren wurden unter DOS auch Programme wie PKLITE und LZEXE verwendet. Bei verschiedenen archivierten Cracktros lassen sich diese EXE-Packer heute noch nachweisen.

Das Handwerk: DOS gab den belegten Arbeitsspeicher eines regulär beendeten Programms wieder frei. Ein eigenständiges Cracktro konnte daher vollständig aus dem Speicher verschwinden, bevor das Spiel geladen wurde. Der Coder musste seine Grafik- und Musikroutinen nicht in die Speicherbelegung des fremden Spiels einpassen – ein Vorteil bei PCs mit knappem konventionellem Arbeitsspeicher.

5. SNES – Das Spiel als ROM-Datei

Bei Modul-Konsolen steckte der Programmcode in einem ROM-Baustein innerhalb des Spielmoduls. Für Änderungen musste er zuerst ausgelesen werden.

Geräte wie Super Magicom oder Super Wild Card ermöglichten das beim Super Nintendo. Sie konnten ein Modul als ROM-Datei sichern und veränderte Dateien anschließend wieder laden. Gegenüber der Konsole verhielten sie sich dabei wie ein eingestecktes Spielmodul.

Cracktros und Trainer wurden direkt in die ROMs eingebaut. Bei Earthbound Crack +3 von Nightfall wurde beispielsweise ein IPS-Patch veröffentlicht. Erst durch das Anwenden dieses Patches auf das passende Spiel-ROM entstand die Fassung mit den zusätzlichen Szene-Funktionen.

Das Handwerk: SNES-Spiele verwendeten unterschiedliche ROM-Speicherzuordnungen: Bei LoROM waren die Daten in 32-Kilobyte-Bereichen erreichbar, bei HiROM in 64-Kilobyte-Bereichen. Für zusätzliche Routinen musste der Coder die Dateipositionen den richtigen Prozessoradressen zuordnen; auch die Position des Reset-Vektors im ROM hing vom Format ab. Eine weitere Falle waren zusätzliche 512-Byte-Header mancher Kopiergeräte. Ein IPS-Patch für eine ROM-Datei ohne diesen Vorspann veränderte bei einer Datei mit Header die falschen Bytes.

6. Game Boy und GBA – Ein Intro wird Teil des ROMs

Beim Game Boy Color und später beim Game Boy Advance wurden Cracktros und Trainer ebenfalls direkt in die ROMs eingebaut. Viele dieser Intros sind deshalb nur zusammen mit dem veränderten Spiel erhalten. Demozoo kennzeichnet solche Produktionen teilweise ausdrücklich als Cracktros, die für eine getrennte Archivierung erst aus dem ROM herausgelöst werden müssten.

In den Credits erscheinen unterschiedliche Namen für Code, Grafik und Musik. An einem Intro arbeiteten häufig mehrere Mitglieder einer Gruppe.

Das Handwerk: Bei Game-Boy-Color-Spielen mit Speicherbankumschaltung war oft nur eine von mehreren 16-Kilobyte-ROM-Bänken gleichzeitig in einem bestimmten Adressbereich sichtbar. Zusätzlicher Intro-Code in einer anderen Bank erforderte deshalb die passende Bankumschaltung. Beim Game Boy Advance lag der Startbefehl dagegen am Anfang des ROMs. Im anschließenden Header standen die Nintendo-Logo-Daten und eine Prüfsumme, die beim Start geprüft wurden. Änderungen an diesen Feldern konnten verhindern, dass das Spiel überhaupt anlief.

7. PlayStation – Cracktros im CD-Image

Mit der PlayStation verlagerte sich die Arbeit auf CD-Images. Szenegruppen verbreiteten häufig kleine Patches, die auf eine vorhandene Kopie der Spiel-CD angewendet wurden.

Diese Änderungen konnten Kopierschutz-Fixes enthalten. Auch PAL-/NTSC-Auswahlmenüs oder Trainer ließen sich auf diesem Weg einbauen. Bei manchen Veröffentlichungen wurde zusätzlich ein Cracktro integriert.

Paradox veröffentlichte zahlreiche Kombinationen aus Intro und Patch. Bei manchen Releases schrieb ein Coder das Intro, ein anderer veränderte das Spiel.

Später kamen standardisierte PPF-Patches zum Einsatz, die sich mit Werkzeugen wie PPF-O-Matic anwenden ließen. Daneben existierten Veröffentlichungen, bei denen das Cracktro bereits in einem veränderten CD-Abbild enthalten war.

Das Handwerk: PPF-Patches beschrieben Änderungen an festen Bytepositionen im CD-Abbild. Auf PlayStation-CDs lagen die Daten in CD-XA-Sektoren; ein Rohabbild enthielt üblicherweise 2352 Byte pro Sektor, während ein gewöhnlicher Form-1-Datensektor davon 2048 Nutzdatenbytes bereitstellte. Wer einen Patch auf ein anders aufgebautes Image oder eine abweichende Spielfassung anwendete, konnte daher die falschen Daten überschreiben. Die genaue Abbildform gehörte zum Patch dazu.

Ein Cracktro war selbst ein kleines Softwareprojekt

In vielen Gruppen übernahmen die Mitglieder feste Aufgaben. Auf dem C64 entfernten Cracker den Kopierschutz; andere programmierten Cracktros oder Trainer. Fixer übernahmen unter anderem Anpassungen zwischen PAL und NTSC. Swapper und Trader kümmerten sich um die Verbreitung.

Ein Coder setzte das Intro um, ein Grafiker zeichnete das Logo und die Musik kam häufig von einem weiteren Mitglied. Auch das Originalspiel musste jemand erst einmal beschaffen.

Der Spieler bekam von dieser Arbeit wenig mit. Er sah das Cracktro, drückte eine Taste und landete im Spiel.

Die Szene: Die Gruppen hinter Cracktros und Demos

Auf vielen Cracktros standen Gruppennamen, die zahlreiche Heimcomputerbesitzer kannten. Hinter Fairlight, Triad oder Razor 1911 steckten Programmierer und andere Computerbegeisterte, die sich unter einem gemeinsamen Namen organisierten.

Die Mitglieder verwendeten Pseudonyme, die in den Intros auftauchten. Manche Gruppen entwickelten über Jahre ihren eigenen Stil.

Dabei waren Cracking- und Demoszene zunächst eng miteinander verbunden. Einige Gruppen beschäftigten sich mit beiden Bereichen, andere konzentrierten sich im Lauf der Zeit vollständig auf die Entwicklung von Demos.

1. Commodore 64 – Die frühen Namen

Triad entstand im Juli 1986 aus drei schwedischen Gruppen. Deren Mitglieder kamen aus Stockholm, Göteborg und Västerås. Die geografische Anordnung der Städte bildete ein Dreieck und lieferte die Idee für den Namen. Triad gehörte zu den frühen C64-Cracking-Gruppen und veröffentlichte auch Demos.

Fairlight wurde im April 1987 von ehemaligen Mitgliedern der West Coast Crackers gegründet. Zu den Gründern gehörten Strider und Black Shadow. Die Gruppe veröffentlichte später auch auf Amiga, PC und verschiedenen Konsolen und war daneben mit eigenen Demos aktiv.

Crest kam 1988 hinzu. Die deutsche Gruppe war zunächst im Cracking aktiv und verlagerte ihren Schwerpunkt auf C64-Demos. Auch Jahrzehnte nach ihrer Gründung veröffentlichte Crest neue Produktionen für den Rechner.

2. Atari ST – Cracker werden zu Demo-Pionieren

The Exceptions, meist TEX genannt, gehörten zu den frühen Cracking- und Demogruppen auf dem Atari ST. Die Gruppe wurde 1986 gegründet und veröffentlichte im März 1987 mit READ_ME.PRG eine der ersten eigenständigen Szenedemos für diesen Rechner.

Automation vereinte mehrere Cracking-Gruppen. Bekannt wurde der Zusammenschluss durch umfangreiche Compilation-Disketten mit mehreren Spielen und einem gemeinsamen Startmenü. Die nummerierte Serie erreichte schließlich die Ausgabe 512.

The Union schloss ab 1988 mehrere Atari-ST-Gruppen zusammen. Im Verbund arbeiteten unter anderem The Exceptions, Delta Force und The Carebears. Der Schwerpunkt verlagerte sich vom Cracking auf eigene Produktionen. Die Union Demo von 1989 wurde in der ST-Szene bekannt; aus dem Umfeld des Zusammenschlusses ging später das Spieleentwicklungsstudio Thalion hervor.

3. Amiga – Zwischen Cracktro und eigenständiger Demo

Razor 1911 hatte seine Wurzeln auf dem C64. Die norwegische Gruppe entstand 1985 und wurde später durch Veröffentlichungen auf dem Amiga und dem PC bekannt.

Paradox entstand Ende 1989 aus Mitgliedern anderer europäischer Gruppen. Der Zusammenschluss wurde auf dem Amiga durch seine Cracks bekannt. Später war Paradox auch auf Konsolen aktiv, wo unter anderem PlayStation-Patches und dazugehörige Intros erschienen.

Spaceballs wurde 1988 in Norwegen gegründet. Die Gruppe widmete sich vor allem eigenen Demos. Ihre Produktion State of the Art gewann im Dezember 1992 den Amiga-Demowettbewerb der Veranstaltung The Party. Die Demo zeigte tanzende Figuren, deren Animationen eng auf die Musik abgestimmt waren.

The Black Lotus, kurz TBL, entstand 1989 in Schweden. Die Gruppe begann auf dem Amiga und war später auf weiteren Plattformen aktiv. Zu ihren Produktionen gehören Captured Dreams und Silkcut.

4. DOS-PC – Eine eigene Demoszene entsteht

Die finnische Future Crew veröffentlichte bereits 1988 erste PC-Demos. Aus ihrem Umfeld stammte das Musikprogramm Scream Tracker, das zur Entwicklung der PC-Trackermusik beitrug.

1993 gewann Future Crew mit Second Reality den Demowettbewerb der Assembly. Die Produktion zeigte unter DOS aufwendige Grafikeffekte, deren Wechsel auf die Musik abgestimmt waren.

Neben Cracking-Gruppen wie Razor 1911 entstand auf dem PC eine Demoszene mit eigenständigen Produktionen. Die deutsche Gruppe Farbrausch veröffentlichte im Jahr 2000 fr-08: .the .product und zeigte damit aufwendige Grafik in einem Programm von nur 64 Kilobyte. Sogenannte 64K-Intros bildeten zu diesem Zeitpunkt bereits eine eigene Wettbewerbsdisziplin.

5. Konsolen – Bekannte Namen auf neuer Hardware

Quartex, ursprünglich eine Amiga-Cracking-Gruppe aus dem Jahr 1988, veröffentlichte in den frühen Zweitausenderjahren auch Releases für Game Boy Color und Game Boy Advance.

Paradox setzte seine Arbeit unter anderem auf der PlayStation fort. Dort wurden Intros mit Patches verbunden, die zusätzliche Funktionen oder Anpassungen am Spiel enthielten. Auch auf einer Konsole konnte vor dem eigentlichen Spiel das Logo einer Szenegruppe erscheinen.

Demo-Tricks: Die Grenzen der Hardware ausreizen

Ein Video zeigt den Effekt einer alten Demo, aber nicht die technischen Grenzen des damaligen Rechners. Die Wirkung erschließt sich erst mit dem Wissen, welche Einschränkungen die Hardware hatte.

Ein Scrolltext im Bildschirmrahmen war auf einem C64 keine gewöhnliche Darstellung. Pixelweiches Scrolling auf einem Atari ST erforderte andere Tricks als auf einem Amiga.

1. Commodore 64 – Grafik dort, wo sonst nur der Rahmen war

Die Grenze: Der VIC-II-Grafikchip des C64 stellte den Bildbereich innerhalb eines festen Rahmens dar. Für bewegte Objekte standen außerdem acht Hardware-Sprites zur Verfügung.

Der Trick: Mit exakt getimten Registeränderungen konnten Programmierer verhindern, dass der VIC-II den normalen Bildschirmrahmen einschaltete. Dadurch ließen sich auch außerhalb der gewohnten Bildfläche Grafikelemente darstellen.

Beim Sprite-Multiplexing verwendeten die Coder die acht vorhandenen Sprites während eines Bildschirmdurchlaufs mehrfach. So konnten zusätzliche Objekte erscheinen, obwohl der Chip weiterhin nur acht Sprites besaß.

FLI veränderte, wie oft der Grafikchip Farbinformationen aus dem Speicher einlas. Die Farbzuweisungen konnten dadurch feiner gesteuert werden.

Der Effekt: Scrolltexte und Sprites erschienen im Bildschirmrahmen. Sprite-Multiplexing erlaubte zusätzliche bewegte Objekte, während FLI die Farbdarstellung verfeinerte.

Warum das damals beeindruckte: Jeder C64-Besitzer kannte den breiten Rahmen um das eigentliche Bild. Bei diesen Demos erschienen dort Sprites und Grafikelemente, wo er sonst nur die Rahmenfarbe sah.

Rezeption: Bereits 1987 berichtete ZZAP!64 über Scroller mit Sprites im Bildschirmrahmen. Spieleentwickler Andrew Braybrook äußerte damals Zweifel, ob dabei möglicherweise ein Fehler des Grafikchips ausgenutzt wurde und ob die Technik auf allen Rechnern zuverlässig funktionieren würde.

2. ZX Spectrum – Mehr Farbe trotz Attribute Clash

Die Grenze: Beim ZX Spectrum wurde die Farbe nicht für jeden Pixel einzeln gespeichert. Jeweils ein Block von 8 mal 8 Pixeln teilte sich eine Vordergrund- und eine Hintergrundfarbe.

Bewegten sich unterschiedlich gefärbte Objekte durch denselben Block, entstanden die bekannten Farbkonflikte. Dieser sogenannte Attribute Clash prägte das Erscheinungsbild vieler Spectrum-Spiele.

Der Trick: Democoder veränderten die Farbattribute während des laufenden Bildaufbaus. Statt die Farbwerte eines 8-mal-8-Blocks für das gesamte Bild unverändert zu lassen, konnten sie zwischen einzelnen Bildschirmzeilen ausgetauscht werden.

Solche Multicolor-Verfahren erhöhten die vertikale Farbauflösung über das übliche 8-Pixel-Raster hinaus.

Der Effekt: Mit Multicolor-Techniken konnten Farben innerhalb eines acht Pixel hohen Blocks zwischen den Bildschirmzeilen wechseln.

Auf dem Spectrum entstanden außerdem ganz andere Demo-Effekte: rotierende 3D-Objekte mit Texture Mapping, Phong-artige Beleuchtung, Voxellandschaften und Wolfenstein-ähnliche 3D-Darstellungen. Diese beruhen auf eigenen Grafik- und Rechenverfahren und sind keine Folge des Multicolor-Tricks.

Warum das damals beeindruckte: Der Attribute Clash prägte viele Spectrum-Spiele. Die neuen Farbverfahren umgingen einen Teil dieser sichtbaren Einschränkung. Auch die 3D-Darstellungen reizten die Möglichkeiten des 3,5-MHz-Z80 weit über die gewohnten Spielgrafiken hinaus aus.

Rezeption: In einer Befragung von Spectrum-Democodern wurde Refresh als einschneidende Produktion beschrieben. Vergleichbare 3D-Darstellungen waren zuvor auf dem Spectrum nur selten zu sehen gewesen. Ein anderer Coder berichtete über seinen Unglauben angesichts der Texturen mit Phong-artiger Beleuchtung in Napalm.

3. Amstrad CPC – Der Bildschirm wird größer und bunter

Die Grenze: Der Amstrad CPC bot mehrere Grafikmodi mit unterschiedlichen Auflösungen und Farbzahlen. Im farbenreichsten Standardmodus konnten 16 Farben gleichzeitig dargestellt werden.

Der normale Bildaufbau begrenzte außerdem die sichtbare Grafikfläche. Der Bereich außerhalb des eigentlichen Bildes blieb ungenutzt.

Der Trick: Der CRTC steuerte beim CPC den Bildaufbau. Durch Veränderungen seiner Register während der Darstellung konnten Programmierer den Bildschirm aufteilen oder einzelne Bereiche verschieben.

Overscan erweiterte die sichtbare Bildfläche über die üblichen Grenzen hinaus. Mit Raster-Splits ließ sich außerdem die Farbpalette während des Bildaufbaus verändern. So konnten innerhalb desselben Bildes zusätzliche Farben erscheinen, obwohl der jeweilige Grafikmodus weiterhin seine feste Anzahl gleichzeitig verfügbarer Farbwerte besaß.

Der Effekt: Demos nutzten Overscan zusammen mit Hardware-Scrolling und mehreren Grafikmodi auf demselben Bildschirm. Die KKB First Demo zeigte Farbwechsel und mehrere gleichzeitig laufende Scrolltexte.

Warum das damals beeindruckte: Im normalen CPC-Bildschirm waren Größe und Farben der Grafik fest begrenzt. Overscan und Palettenwechsel erweiterten die Bildfläche und zeigten zusätzliche Farben.

Rezeption: Ein Rückblick von 1993 beschreibt frühe Rastereffekte, durch die Logos zusätzliche Farben zeigten. Revolog von Longshot verband horizontales und vertikales Hardware-Scrolling mit Rastereffekten und Musik.

4. Atari ST – Scrolling ohne Scrolling-Hardware

Die Grenze: Der normale Farbmodus des Atari ST bot eine Auflösung von 320 mal 200 Pixeln bei 16 gleichzeitig sichtbaren Farben. Der ursprüngliche ST hatte keine Hardwarefunktion für pixelweiches Scrolling. Bewegte Bildinhalte mussten über den Speicher realisiert werden.

Der Trick: Programmierer fanden heraus, dass sich durch exakt getimte Wechsel zwischen 50 und 60 Hertz Teile des Bildschirmrahmens öffnen ließen. Zuerst gelang das beim unteren Rand. Weitere Verfahren erschlossen die übrigen Seiten, bis schließlich Fullscreen-Darstellungen möglich wurden.

Aus der genauen Steuerung des Bildaufbaus entstand später das Sync-Scrolling. Dabei wurden unterschiedlich lange Bildschirmzeilen kombiniert, um dem Grafikchip eine feinere Verschiebung des Bildspeichers vorzutäuschen.

So entstand eine Art Hardware-Scrolling, obwohl der ursprüngliche ST die dafür vorgesehenen Register nicht besaß.

Der Effekt: Fullscreen-Demos konnten statt der üblichen 320 mal 200 Pixel ungefähr 413 mal 276 Pixel darstellen. Scrolltexte und Grafiken bewegten sich weich über den Bildschirm. Palettenwechsel während des Bildaufbaus ermöglichten zugleich die Darstellung zusätzlicher Farben, die über die üblichen 16 hinausgingen.

Warum das damals beeindruckte: Die Demos griffen gleich zwei vertraute Einschränkungen des ST auf. Einige öffneten die bisher festen Bildschirmränder, andere ermöglichten weiches Scrolling ohne eine dafür vorgesehene Hardwarefunktion.

Rezeption: Das erste Öffnen des unteren Bildschirmrandes im Jahr 1987 sorgte innerhalb der ST-Szene für Diskussionen darüber, wie dieser Effekt zustande kam. Die spätere Entfernung aller Ränder galt lange als unerreichbares Ziel. Auch das 1989 entwickelte Sync-Scrolling wird in Rückblicken als einer der wichtigen technischen Durchbrüche der ST-Demoszene beschrieben.

5. Amiga – Zwei Spezialisten namens Copper und Blitter

Die Grenze: Der Amiga besaß Spezialchips für Grafik und Sound. Rechenleistung und Speicherbandbreite blieben trotzdem begrenzt. Die planare Organisation der Grafikdaten machte bestimmte Darstellungen zusätzlich aufwendig.

Der Trick: Der Copper konnte während des laufenden Bildaufbaus Register verändern, ohne dass der Hauptprozessor jeden Schritt selbst ausführen musste. So wechselte er an festgelegten Bildschirmzeilen Farben oder Scrollpositionen.

Der Blitter übernahm andere Aufgaben. Er konnte Speicherbereiche kopieren und grafische Operationen wie Linienzeichnen oder Flächenfüllen ausführen. Währenddessen stand dem 68000-Prozessor Rechenzeit für weitere Arbeiten zur Verfügung, wobei sich die Komponenten die verfügbare Speicherbandbreite teilen mussten.

Der Effekt: Mit dem Copper entstanden die bekannten Copperbars und Farbverläufe. Auch gesplittete Bildbereiche ließen sich damit realisieren.

Der Blitter unterstützte insbesondere das Zeichnen und Füllen von Grafikobjekten. Rotozoomer, Dot-Tunnel und Voxel-Landschaften kamen in späteren Demos hinzu. Dafür waren weitere Rechenverfahren nötig, bei denen je nach Effekt Hauptprozessor und Grafikchips zusammenarbeiteten.

Warum das damals beeindruckte: Der Amiga war bereits für seine Grafik- und Soundmöglichkeiten bekannt. Ein einfacher Farbbalken reichte innerhalb der Szene bald nicht mehr aus, um Aufmerksamkeit zu erregen. Coder arbeiteten daran, größere und aufwendigere Effekte flüssig darzustellen.

Rezeption: Die Anzahl der Polygone, die bei stabilen 50 Bildern pro Sekunde dargestellt werden konnten, diente in der Amiga-Szene als technischer Maßstab. Demos wie Enigma und Hardwired zeigten, wie gefüllte Vektorobjekte mit Musik zu eigenen Produktionen verbunden wurden. Desert Dream setzte diese Entwicklung mit einer aufwendigen audiovisuellen Inszenierung fort.

Der gemeinsame Trick hinter den Tricks

Auf dem C64 und Atari ST nutzten die Programmierer exakt getimte Registerzugriffe während des Bildaufbaus. Beim Amiga konnte der Copper solche Änderungen übernehmen, während der Blitter bei anderen Grafikaufgaben half.

Die Hardware lief mit unverändertem Tempo, wurde aber anders angesteuert. Beim Betrachten einer Videoaufnahme bleibt dieser Teil der Arbeit unsichtbar.

Ein Scrolltext im Rahmen sieht heute wie ein gewöhnlicher Grafikeffekt aus. Für den damaligen C64-Besitzer erschien er an einer Stelle, an der sein Rechner sonst nur eine feste Rahmenfarbe zeigte.

Wie haben die das auf dieser Hardware bloß hinbekommen?

Zur Entstehung dieser Trivia

Die Hintergründe zu Kopierschutz, Cracktros und Demos finden sich in zahlreichen Szene-Archiven und historischen Veröffentlichungen. Ich wollte diese Suche nicht jedem Leser selbst überlassen, sondern die verstreuten Informationen in einer zusammenhängenden Trivia zugänglich machen.

Da auch bei einem Hobby Zeit und Aufwand eine Rolle spielen, habe ich für die Recherche und strukturelle Aufbereitung künstliche Intelligenz zur Unterstützung genutzt. So ließ sich aus der ursprünglichen Idee eine umfangreiche Sammlung machen, die zum Nachlesen und Stöbern einlädt.

Quellen und weiterführende Links

Kopierschutz und Cracking

Cracktros und Entstehung der Demoszene

Technische Tricks der Demoszene

Bekannte Szene-Gruppen

Commodore 64

Atari ST

Amiga

Konsolen

Nachhall

Ihr seid herzlich eingeladen in unserem Forum und auf Discord eure Gedanken zu teilen und euch mit unserer Community auszutauschen.

Ich freue mich auch über Feedback. Falls ihr mir lieber ohne Anmeldung etwas schreiben möchtet, könnt ihr mir gerne direkt eine Nachricht senden.