Fixer

Unter dem Wort Fixer muss man sich im Zusammenhang mit der Cracker-Szene auf dem C64 eine Person vorstellen, die ein Spiel auf eine bestimmte Version des C64 - NTSC- oder PAL-Version - anpasst. Man spricht hier von einem PAL-Fix bzw. NTSC-Fix, wobei Fix vom englischen Wort to fix, also reparieren abgeleitet ist.

Warum Anpassungen nötig sind

Vom C64 gibt es (abgesehen von Platinen- und Gehäusevarianten) zwei grundverschiedene Versionen, eine für den amerikanischen Markt zum Betrieb an NTSC-basierten Fernsehern sowie einen für den europäischen Markt, wo die PAL-Norm für Fernseher üblich ist. Die beiden Fernsehnormen PAL und NTSC unterscheiden sich in vielen Punkten, für den C64 relevant sind jedoch primär die Bildwiederholraten (NTSC 60 Hz und PAL 50 Hz) sowie die Menge der Rasterzeilen (auf PAL gibt es mehr als auf NTSC, weshalb der Border des PAL-C64 vertikal mehr Zeilen abdeckt). Deshalb steckt im PAL-C64 (6569) auch ein anderer VIC als im NTSC-C64 (6567).

Was hat sich Commodore dabei gedacht?

Obwohl bis heute die C64-Welt durch die PAL/NTSC-Unterschiede bis zu einem gewissen Grad "gespalten" ist, ist sehr wenig über die Vorgänge bei der Entwicklung und Entscheidungsfindung diesbezüglich bekannt. Bei der Entwicklung des C64 erschien es den Leuten bei Commodore wahrscheinlich als nicht so schlimm, zwei unterschiedliche VICs einzubauen. Es erschien vielmehr logisch, denn der C64 sollte ja an handelsüblichen TVs betrieben werden können. Hätte man nur die NTSC-Version des C64 auf den Markt gebracht, wäre in Europa der Betrieb nur mit einem Monitor oder Fernseher möglich gewesen, der das 60 Hz Videosignal verarbeiten konnte. Interressanterweise ist dies bei IBM-kompatiblen PCs in gewissem Sinne ja der Fall: PC-Monitore sind weltweit gleich, was die Bildwiederholraten betrifft. Von PCs gab es deshalb nie PAL/NTSC-Versionen und die damit einhergehenden Kompatibilitätsprobleme.

Zunächst wurde wahrscheinlich der NTSC-VIC entwickelt und später etwas angepasst, um daraus den PAL-VIC zu machen. Dass damit zwei nur begrenzt kompatible Versionen des C64 entstanden, war wahrscheinlich den Entwicklern nicht 100% bewusst. Die Menge der Rasterzeilen war nur für den Rahmen - in dem wurde ja damals nichts weiter dargestellt - relevant und die Bildwiederholrate war für die damaligen, meist eher ruckeligen Spiele auch nicht wirklich wichtig. Nimmt man die reine Rechenzeit pro Sekunde, so "nehmen sich die Varianten nicht viel". Beim Ausführen von BASIC-Programmen ist ja auch kein Unterschied zu sehen. Im Laufe der 1980er Jahre aber entwickelte sich die Spielebranche rasant, die Spiele wurden technisch immer anspruchsvoller. Dadurch enstanden einige gravierende Probleme.

Geschwindigkeit

Spiele sind fast ausschließlich Frame-basiert programmiert, d.h. das Scrolling und die Bewegungen der Objekte wird komplett oder zumindest teilweise gekoppelt an die Bildwiederholrate. Die Folgen:

• Spiele für NTSC-C64 laufen auf PAL-C64 langsamer aufgrund der geringeren Bildwiederholfrequenz
• umgekehrt laufen Spiele für den PAL-C64 auf einem NTSC-Gerät schneller

Ebenso wird die Musikroutine fast immer einmal pro Bildaufbau aufgerufen, wodurch sie ebenfalls schneller bzw. langsamer wird.

Rechenzeit und Timing

• Spiele für den PAL-C64 treffen auf NTSC-Systemen auf weniger Rasterzeit pro Frame, da weniger Rasterzeilen vorhanden sind. Dies kann eine Anpassung eines PAL-Spiels auf NTSC unmöglich machen, wenn die gesamte Rasterzeit eines Frames auf dem PAL-C64 genutzt wird.
• Eine normale Rasterzeile hat auf einem NTSC-C64 65 Taktzyklen, auf einem PAL-C64 lediglich 63. Dadurch wird der Nachteil der weniger vorhandenen Rasterzeilen aber nur begrenzt ausgeglichen, zusätzlich bringt der Unterschied Timing-Probleme, die z.B. Sprite-Multiplexer stören können

Wie ein Fix entsteht

Bei einem Spiel, das für einen PAL-C64 geschrieben wurde, muss der Fixer nun, um einen NTSC-Fix zu implementieren, auf einem NTSC-C64 das gesamte Spiel nach Problemen absuchen, die durch die geringere Menge Rasterzeit verursacht werden. Diese Probleme gilt es dann zu beheben (zu fixen), was ggf. eine große Herausforderung sein kann. Es müssen z.B. Teile des Spiels optimiert werden, damit weniger Rasterzeit verbraucht wird. Im schlimmsten Fall muss auf Features verzichtet werden, z.B. die Musik. Bei Timing-Problemen, die sich oft durch Flackern zeigen, müssen die betroffenen Routinen gepatcht werden, um zwei Taktzyklen mehr zu verbrauchen.

Bei einem Spiel, das für einen NTSC-C64 geschrieben wurde, ist meist weniger zu tun, um es auf einem PAL-C64 zum Laufen zu bringen. Es ist pro Frame mehr Rasterzeit vorhanden, so dass meist lediglich Timing-Probleme angegangen werden müssen. Beispiel: In einem Spiel wird oben Grafik angezeigt, unten Text. Am Übergang ist ein leichtes Flackern zu sehen. Der Fixer passt das Timing der Routine an. Er baut ferner eine Überprüfung ein, die beim Spielstart überprüft, ob ein PAL- oder ein NTSC-C64 vorliegt und lässt daraufhin die betroffene Routine automatisch passend patchen.

Der unterschiedlich schnelle Spielablauf, und damit auch die veränderte Geschwindigkeit und Klangfarbe der Musik, wird in der Regel nicht gefixt. Wer in einem SID-Player für Windows mal die Musik von z.B. Test Drive anhört, wird deshalb feststellen, dass sie schneller als "gewohnt" ist (und in ihrer Geschwindigkeit auch eher der Amiga-Version entspricht), weil Test Drive eben für NTSC-C64 entwickelt wurde.

Stellenwert des NTSC-Fixings in der Crackerszene

Beim Cracken muss am Spiel selbst meist nichts verändert werden, selbst die komplexen Schutzmechanismen machen es selten nötig, den Code des Spiels komplett zu verstehen. Ganz anders beim Fixen: Je nach Spiel müssen elementare Teile des Codes vollständig verstanden und dann noch optimiert oder zumindest umgeschrieben werden. Da dies über das "gewöhnliche" Cracken manchmal weit hinaus geht, stellten sich NTSC-Fixer in der Crackerszene teils stark überhöht dar oder wurden durch andere Gruppenmitglieder als große Genies dargestellt. Ende der 1980er Jahre war es außerdem gar nicht so einfach, überhaupt einen NTSC-C64 zu erstehen, wenn man in einem europäischen Land wohnte - internationale Kontakte waren nötig.

Bis heute nicht völlig geklärt sind die Gründe, aus denen die Spieleentwickler oder Publisher nicht selbst schon dafür sorgten, dass ihre Spiele auf PAL- und NTSC-Maschinen gleichermaßen liefen. Eine Ursache dürfte beschränktes lokales Denken sein, d.h. der Markt auf dem anderen Kontinent wurde nicht als relevant genug betrachtet und/oder es existierten gar keine Vertriebkanäle dort. Falls doch, erschien ggf. eine separate Version mit einigen Anpassungen, z.B. wurden Out Run und Space Harrier für PAL entwickelt und in den USA kam eine für NTSC angepasste Variante heraus. Die Crackerszene war hier mit automatisiertem Abfragen und Anwenden der vorher erarbeiteten Anpassungen der Zeit voraus.

Running Gag

In Cracker-Intros zu Spielen, die gefixt worden waren, konnte man oft lesen: "PAL/NTSC-fixed by..." und dann den Namen des Fixers. Da "PAL" aber auch eine bekannte Marke für Hundefutter war (heute "Pedigree"), war manchmal zu lesen: "PAL/Frolic-fixed by...".

PAL/NTSC-Fix für Demos?

Für Demos gibt es nur sehr selten einen NTSC-(oder PAL-)Fix, da er meist technisch nicht oder nur mit sehr großem Aufwand möglich wäre. Demos sind meist extrem Timing-empfindlich und genau auf die vorhandene Rechenzeit abgestimmt. Sieht der Demo-Entwickler selbst nicht bereits Varianten für beide C64-Versionen vor, kann man nachträglich nicht mehr viel tun.

Die in Europa extrem starke Demo-Szene gelangte deshalb in den USA zu keiner großen Bedeutung, da die Demos auf NTSC-Geräten schlichtweg nicht oder nur sehr begrenzt liefen. All die fantastischen Werke, welche bis heute viele User für den C64 begeistern, blieben den Amerikanern lange völlig verschlossen. Erst mit dem Aufkommen von C64-Emulatoren, die den (PAL-)C64 taktzyklengenau nachbilden können, wurde es für die "NTSC-Welt" möglich, die Demos zu sehen. Eingefleischte C64-Fans aus Nordamerika haben sich mittlerweile auch oft ein PAL-Gerät besorgt, da neuere Fernseher beide Normen beherrschen.