Raster-IRQ: PAL oder NTSC

Für diesen Beitrag wurde das CBM prg Studio verwendet.
weitersagen ...
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn

CBM prg StudioDer kleine Unterschied

Lasst uns mal kurz klären, wieviele Rasterzeilen wir überhaupt haben und wieviel Zeit uns (zumindest auf den ersten Blick) je Zeile zur Verfügung steht. Dabei kommen wir notgedrungen auch auf die Hauptunterschiede zwischen PAL und NTSC zu sprechen.
Ich möchte euch noch warnen, dieser Beitrag ist zwar kurz, aber auch relativ trocken, es wird gleich sehr theoretisch. Aber ohne Fleiß kein Preis, da muss man auf dem Weg zum Rasterzeilen-Profi einfach durch!  :mrgreen:

 

Wie immer ist das PAL-System unser Ausgangspunkt!

 

Wieviele Rasterzeilen gibt es überhaupt?
Da die Auflösung des C64 320 * 200 Pixel beträgt, könnte man nun dem Irrtum unterliegen, es gebe max. 200 Rasterzeilen. Aber zwei (euch eigentlich bereits bekannte) Punkte sprechen dagegen. Zum einen gibt es den „tollen“ Rahmen, der ja auch gezeichnet werden muss und das höchste BIT für die Rasterzeile in $D011 wäre ja nicht nötig, wenn es max. 256 Rasterzeilen gäbe.

Da wir gerne wissen möchten, wieviele Rasterzeilen es denn nun tatsächlich gibt, überlegen wir doch mal, wie wir diese ermitteln können. Ihr habt hoffentlich bereits den einleitenden Beitrag „Der Rasterzeileninterrupt“ studiert, dann sollte euch direkt das Register $D012 einfallen.

Wir wissen bereits, dass der VIC die aktuelle Rasterzeile in $D012 mitzählt. Also können wir einfach schauen, was der höchste Wert in $D012 ist. Dabei ist es natürlich wichtig, darauf zu achten, dass auch das höchste BIT für die Rasterzeile in $D011 gesetzt ist, damit wir wirklich die max. Anzahl der Rasterzeilen zählen. Das folgende Programm ermittelt die Rasterzeilen und gibt diese als Hex-Wert oben links aus.

Wer möchte, kann zur absoluten Sicherheit noch die Zählroutine in einen sei / cli-Block verpacken, um Einflüsse von Außen zu vermeiden, eigentlich ist dass aber nicht notwendig.

Wenn ihr das Programm auf einem PAL-System startet, dann sollte links oben 38 stehen. Jetzt kennen wir die max. Anzahl der Rasterzeilen. Da das höchste BIT in $D011 gesetzt ist, müssen wir also einfach $0138 umrechen und kommen somit auf 312 Rasterzeilen. Beachtet, dass die Zählung bei 0 beginnt, die möglichen Zeilen reichen somit von 0 bis 311 ($0137)!

Testen könnt ihr unser Ergebnis einfach mit einem kleinen Rasterzeileninterrupt:

So, wie das Programm hier vorliegt, sollte erstmal nichts passieren! Es hängt einfach in einer Endlosschleife fest, da auf die nicht vorhandene Zeile $0138 gewartet wird! Nochmal zur Erinnerung: Die Zählung beginnt mit 0!! Sobald ihr aber die gewünschte Zeile für den Raster-IRQ um eins verringert (also #$37 nach $D012 schreibt), sollte der Rahmen (wie schon so oft) blinken.

 

Anzahl der Taktzyklen je Rasterzeile
Für einige Raster-Effekte ist es wichtig, Taktzyklen genau vorzugehen. Dazu müssen wir dann wissen, wieviele Zyklen in einer Rasterzeile verarbeitet werden. Dies läßt sich relativ einfach ausrechnen. Wie wir bereits wissen wird der 6510 in einem PAL C64 mit 985248 Hz getaktet und pro Takt kann ein Befehl verarbeitet werden. Die Bildwiederholrate beträgt, wie uns ebenfalls bekannt ist, ~50 Hz. Da bei jedem Bildaufbau die 312 Rasterzeilen abgearbeitet werden, kommen wir auf 985248 / 50 / 312 = 63 (gerundet) Taktzyklen je Zeile. In einem der nächsten Beiträge werden wir sehen, dass es auch hier mal wieder einen Haken gibt, die 63 Taktzyklen stehen uns nämlich nicht immer zur Verfügung!

 

Und wie sieht es bei NTSC aus?

Sofern ihr WinVICE verwendet, können wir jetzt ganz einfach testen, wie das unter NTSC aussieht. Klick dazu im Menü auf Einstellungen -> C64 Modell Einstellungen... und stellt den Dialog, wie hier zusehen, ein:

NTSC-Einstellungen
NTSC-Einstellungen

Speichert anschließend eure Einstellungen und startet nochmal unser Testprogramm, das den Rahmen blinken läßt, mit dem höchst möglichen Wert für PAL-Systeme #$37. Wie ihr seht, seht ihr nichts 😉 . Werft jetzt das Programm zum Zählen der Zeilen an und ihr solltet oben links eine 07 entdecken. Auf diesem NTSC-System haben wir also nur $0107 = 263 Rasterzeilen! Wie wichtig es ist, die Anzahl der Zeilen zu kennen, habt ihr eben ja schon selbst bemerkt. Würde euer Programm z. B. auf die Rasterzeile 300 warten, dann ist dies auf PAL-Systemen kein Problem. Wird es aber auf einem NTSC-System gestartet, läuft es nicht korrekt! Dort ist die Zeile unbekannt und es wird nie ein IRQ für die gewünschte Zeile ausgelöst.
Das es weniger Rasterzeilen sind, sollte keinen überraschen, die physikalische Auflösung ist auf NTSC-Systemen schließlich geringer, die Bildwiederholfrequenz dafür mit ~60Hz um 20% höher.

Wie sieht es denn mit den Taktzyklen je Zeile aus?
Bei einem NTSC C64 ist der Prozessor bekanntlich schneller getaktet. Also rechnen wir dieses Mal 1022727 Hz / 60 Hz / 263 gerundet erhalten wir 65 Taktzyklen je Zeile. Wir haben also zwei Zyklen je Rasterzeile mehr zur Verfügung, hier gilt aber natürlich ebenfalls, dass diese nicht immer voll von uns ausgeschöpft werden können.

Ich hoffe euch ist aufgefallen, dass ich bei der Berechnung der Taktzyklen, sowohl unter PAL als, auch unter NTSC, jeweils gerundet habe. Das liegt daran, dass wir bei unseren Berechnungen von einem falschen Wert ausgegangen sind. Der VIC-II liefert nicht exakt die von uns erwartete Bildwiederholrate! Diese ergibt sich aus den von uns ermittelten Werten. Wenn ihr nun die Bildwiederholfrequenz zurückrechnet, werdet ihr auf 50,124542 Hz bei PAL und 59,8260895 Hz bei NTSC kommen.

 

Zwei Sonderfälle
Um die Sache noch komplizierter zu gestalten, gibt es eine weitere NTSC-Version. In den ersten NTSC-Modellen war ein VIC-II mit recht verschrobenen Timing verbaut. Schaltet WinVICE doch mal auf die „alte NTSC“ Version um:

2. NTSC Version
2. NTSC-Version

Startet ihr jetzt das Programm, um die Rasterzeilen zu zählen, seht ihr oben links eine 06. Bei den alten NTSC-Systemen, gibt es also nur $0106 = 262 Rasterzeilen. Wer jetzt wieder unsere obige Rechnung durchführt, kommt aber aufs falsche Ergebnis! Obwohl hier eine Rasterzeile weniger, als beim ‘standard‚ NTSC-Modell, vorhanden ist, erhöht sich die Zahl der Zyklen je Zeile nicht! Sie liegt mit 64 Taktzyklen sogar um eins niedriger!! Dies ist dem wohl nicht so optimalem Timing der ersten C64-Modelle geschuldet.

Als letztes möchte ich, nur der Vollständigkeit wegen, noch ganz kurz PAL-N erwähnen. Diese VICs wurden in den sog. „Drean Commodore 64“ verbaut. Drean war eine argentinische Firma, die schon 1983 (ganz offiziell) einen C64 unter eigenem Label auf den Markt bringen durfte. Die Geräte wurden von Commodore gefertigt und dann mit dem Drean Logo versehen.

Logo des Drean C64 aus Argentinien.
Logo des Drean C64 aus Argentinien.

WinVICE kann übrigens auch PAL-N emulieren, schaut ruhig mal nach. Unter PAL-N gibt es, wie beim ‘normalen‚ PAL-System, auch 312 Rasterzeilen, aber hier stehen uns je Zeile sogar 65 Taktzyklen (wie unter NTSC) zur Verfügung. Diese C64-Modelle haben somit einen Prozessortakt von ~1.01 MHz.

 

Was bedeutet dies alles jetzt für unsere Programmentwicklung?
Bei der Programmierung von Rasterzeilen-Effekten müssen wir evtl. auf die verschiedenen C64 Versionen Rücksicht nehmen. Wie man drei dieser Versionen erkennt, wisst ihr jetzt auch schon, jede hat ihre eigene Anzahl an maximalen Rasterzeilen, einzige Ausnahme ist PAL-N. Die Anzahl der Rasterzeilen läßt sich nicht nur so aufwendig, wie oben beschrieben ermitteln, sondern auch als kurzer Vier-Zeiler.

Dieser kleine Abschnitt liefert euch im Akku die höchste Rasterzeile zurück. Man muss also nur eins hinzuaddieren und erhält die gleichen Ergebnisse wie bei unserer längeren Version von oben, die ja die max. Anzahl der Rasterzeilen geliefert hat. Probiert es ruhig mal aus…

Es kann durchaus sein, dass euch nicht direkt klar ist, wie und warum das hier funktioniert, schließlich beachten wir $D011 überhaupt nicht. Schaut euch dann einfach nochmal an, wie die Vergleichsbefehle arbeiten, spielt etwas damit herum und ihr werdet es verstehen.

Außerdem ist es evtl. wichtig, daran zu denken, dass die Bildwiederholfrequenzen unterschiedlich sind. Synchronisiert ihr etwas über den Raster-IRQ, dann wird dies bei NTSC (~60Hz) schneller vonstatten gehen, als unter PAL (~50 Hz). Häufig mag das kein großes Problem sein, man sollte es aber dennoch im Hinterkopf behalten.

 

Warum nicht $02A6 verwenden?
Wer sich bereits mit der Erkennung von PAL und NTSC-Systemen auseinandergesetzt hat, der ist evlt. schon über die Adresse $02A6 gestolpert. Bei NTSC sollte dort $00, bei PAL $01 stehen. ABER, der Wert wird nur durch die Reset-Routine gesetzt, da er sich im RAM befindet, kann er verändert werden. Bei einem RESET, während eine SuperCPU im 20MHz-Modus läuft, steht dort außerdem immer $00! Auch dies könnt ihr mit der WinVICE SuperCPU-Version testen. Laßt euch einfach mit ?PEEK(678) den Inhalt der Speicherstelle anzeigen, einmal nach einem RESET im normalen Modus und einmal nach einem RESET im 20MHz-Modus. Daher ist es sicherer, über die Anzahl der Rasterzeilen das vorliegende System zu erkennen. Der Grund, warum  $02A6  hier falsch gesetzt wird, liegt ganz einfach daran, dass die SuperCPU, die ROM-Routine, die  $02A6  füllt, viel zu schnell abarbeitet. Diese Routine versucht (ähnlich wie wir) die Fernsehnorm über die Rasterzeilenanzahl zu ermitteln. Sie geht aber davon aus, dass ein bestimmter Codeabschnitt länger als ein kompletter Bildschirmaufbau dauert (was bei einem normalen C64 auch der Fall ist). Aber diese Annahme führt dann, bei einer sehr viel schnelleren SuperCPU, zum falschen Wert, mit 20MHz ist der ROM-Abschnitt schon erledigt, bevor die „PAL-Rasterzeile“ erreicht wird.

Wo wir gerade bei der SuperCPU sind, da die SuperCPU im 20MHz Modus Befehle schneller als der 6510 verarbeitet, können zyklengenaue Routinen dann natürlich aus dem Tritt kommen und der Effekt ist im Eimer.


Hier nun das Ergebnis unserer Arbeit.
Eine Tabelle, mit den wichtigsten Werten für PAL- und NTSC-Systeme.

Ich habe die Tabelle noch um die Anzahl der sichtbaren Zeilen und Pixel je Zeile ergänzt. Für uns sind die ersten beiden Eintragungen in der Liste sehr wichtig, diese Systeme werdet ihr ‚draußen‚ häufig antreffen. Die letzten beiden (gelb markierten) sind wirklich sehr speziell, ob ihr eure Programme auch daran anpassen wollt???

Evtl. habt ihr den C64 DTV vermisst. Da dies kein echter C64 ist, habe ich ihn hier ausgelassen. Sein Timing ist außerdem sehr speziell 😉 . Wer möchte, kann es ja mal mit dem entsprechenden VICE-Programm (x64dtv.exe) untersuchen. Ich gehe evtl. später (VIEL SPÄTER) mal an gesonderter Stelle auf die DVT-Programmierung ein.

Da wir jetzt im Besitz des nötigen Wissens sind, werden wir uns im nächsten Beitrag eine recht simple Aufgabe stellen und tiefer in die Raster-Geheimnisse vordringen.



Schrott!!Naja...Geht so...Ganz gut...SUPER! (4 Bewertungen | Ø 5,00 von 5 | 100,00%)

Loading...


 

<<< zurück | weiter >>>

weitersagen ...
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn

5 Gedanken zu „Raster-IRQ: PAL oder NTSC“

  1. Zweite Frage:
    Das wir in diesem Beispiel alle Timer-IRQs deaktivieren, wäre es hier auch ok die irq: Routine mit „jmp $ea31“ zu verlassen anstatt „pla, tay, …. , rti“ , oder ist das eher nicht zu empfehlen?

    1. Der Sprung nach $EA31 ist durchaus möglich, da hier noch das ROM aktiv ist. Allerdings springt man in diesem Fall eher nach $EA81, um auf den PLA ... RTI-Block zu verzichten. Schau dir diese Adresse einfach mal mit dem VICE-Monitor an.

    1. Hi.
      Ich nehme an, du meinst das Bestätigen während der Initialisierung.
      Es dient nur der Sicherheit, damit gleich der erste Raster-IRQ auf alle Fälle korrekt ausgeführt wird. Wirklich notwendig ist das hier aber nicht. Ich habe mir allerdings angewöhnt $D019 auch bei der Einrichtung eines Raster-IRQs zu bestätigen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Protected by WP Anti Spam