Hello, Guest the thread was called864 times and contains 26 replays

last post from DivZero at the

Stabiler Rasterzeileninterrupt - Linie über gesamte Breite

  • Hi,


    ich versuche mich gerade daran einen stabilen Rastenzeileninterrupt hinzubekommen. Soweit so gut, nun wollte ich damit eine wirklich komplett durch gezogene einzelne Rasterbar von exakt ganz links nach genau ganz rechts programmieren und bekomme das nicht hin. Immer ragt eine Stückchen in einen andere Zeile. Bei dem Beispiel hier ist sogar ein einzelner Punkt ganz links zu sehen. Ich dachte immer so ein Umschalten der Farbe geht nur Taktweise und ein Takt entspricht 8 Pixel?


    Könnte da jemand bitte Licht in mein dunkles kaputtes Hirn bringen?


    double-stable-irq.prg

  • Könnte da jemand bitte Licht in mein dunkles kaputtes Hirn bringen?

    Habe hier noch ein altes, isoliertes Programmierfragment aus dem Jahr 1985 ... lässt sich mit SYS50891 starten. Vielleicht hilft es dir zu Analysezwecken ... ich finde den sich bewegenden Regenbogen heute noch *ganz schick* ... aber sicherlich nicht perfekt.


    Vielleicht kommt der ja noch mal zu einer sinnvollen Verwendung ... ;).

  • Ich habe es hinbekommen, scheint wirklich "nur" Takte zählen zu sein.

    Nur eins macht mich noch stutzig. Was macht dieser eine Pixel ganz am linken Rand im Debug Border von VICE? Ist das ein Übertrag von rechten Rand? Ist das auf einem echten C64 auch? Kann man soweit überhaupt sehen auf einem am C64 angeschlossenen Monitor?


    Hier auf jeden Fall mal ein Bild des Pixels was ich meine und der jetzt funktionierende Code, falls den jemand braucht.

    double-stable-irq-test.prg

  • Kann man soweit überhaupt sehen auf einem am C64 angeschlossenen Monitor?

    Nein, der Debug Rand zeigt ALLES an, was der VIC ausgibt, davon ist auf einem echten CRT ein großer Teil in der horizontalen Austastlücke verborgen. Der normale Vice-Rand gibt wieder, wie es normalerweise auf einem echten CRT sichtbar ist (wenn da nicht sogar noch mehr abgeschnitten wird).


    EDIT: aber fehlt da nicht noch etwas zum stabilen IRQ in Deinem Code? Normalerweise löst man doch einen IRQ in einem NOP aus, um den Jitter auf 1 Zyklus zu reduzieren und entfernt dann den letzten Jitterzyklus mit einem Branch am Ende der Rasterzeile, oder?

  • Erweitere mal den – JMP – um ein NOP.


    Wie Claus es schon angedeutet hat, fehlt noch was, damit dein IRQ stabil wird.

    Es gibt im zweiten IRQ eine Ungenauigkeit von 1 Takt, um diesen einen Takt zu entfernen, wird am Ende der Rasterzeile ein Vergleich benötigt.

    Code
    1. LDA $D012 ; Aktuelle Rasterzeile auslesen (Taktzyklus 59/60)
    2. CMP $D012 ; Vergleich der beiden Rastzeilen ausführen.
    3. BNE STABIL ; Die Rasterzeile wurde bei Taktzyklus 59+4=63 ausgelesen.
    4. STABIL ...
  • So hier mal die wirklich stabile Version, jedenfalls für die normalen Lines. Wenn der VIC-II seinen Cache vollhauen muss in den Badlines, dann sieht da Sache natürlich anders aus. Aber Schritt für Schritt. Danke euch nochmal für die Hilfe hier. Das ist wirklich eine tolle Community.


    double-stable-irq.prg

  • Weiß jemand warum es diesen einen Zyklus Versatz beim Auslösen in einem NOP gibt?

    Ein Befehl wird immer komplett ausgeführt, bevor ein IRQ bedient wird.


    Nun braucht NOP 2 Takte.

    Der IRQ kann während des ersten Taktes passieren, dann muss der IRQ muss halt 1 Takt später ausgeführt werden und kommt zu spät.

    Oder der IRQ passiert während des zweiten Taktes, weil der NOP bis zum Zeilenende reichte. Dann kommt der IRQ sofort dran und passt genau.


    Das ist zumindest das Prinzip.

    Kann sein, dass der IRQ schon beim letzten Takt des vorigen Befehls anliegen muss,

    Irgendwas war da mit Branches, aber das weiß ich nicht mehr genau.

  • Danke für die Erklärung, Mir ist das halt ein Rätsel wie der IRQ dann mal mitten im NOP und erst am Ende des NOP kommen kann, da ja bis hier nichts anderes passiert außer die paar Befehlen vom Setzen des 2.IRQ Vector und dem Rest dazwischen bis zu den NOPs. Warum also löst der IRQ mal im NOP aus und mal am Ende und nicht immer im NOP oder immer am Ende? Vielleicht habe ich aber auch nur Knoten im Kopf bei den Temperaturen heute.

  • Post by DivZero ().

    This post was deleted by syshack: Auf Wunsch des Autors gelöscht ().
  • Guck doch mal, ob Du nicht im IRQ vorne noch ein INC $d021 reinbekommst, und ganz am Ende ein passendes DEC dazu. (Evtl. kommst Du ohne das $ffff aus, wenn das Timing knapp wird).

    Dann siehst Du, mit welcher Verzögerung aus gleichen Gründen der erste IRQ eigentlich kommt.

    Vielleicht löst das den Knoten

  • Ist das vielleicht ein Weiterschleifen des ersten Jitters das jetzt nur durch die NOPs aufs Minimum reduziert wird? Also in Line0 wird der große Jitter, der bis zu 7 Cycles groß sein kann, durch den Sprung in der NOP Region auf 1 Cycle in Line 1 reduziert, was dann zum Ende der Line2 durch den Compare Trick ausgeglichen wird und wir in Line3 dann eine stabile Situation haben.

  • Ich nochmal, nun bin ich stutzig geworden wegen meines einen Pixels am linken Rand im Debug Border Mode von VICE. Ich hielt das für einen Fehler vom Emulator, also dass das eine Pixel da irgendwie ein Übertrag ist oder so was. Mittlerweile habe ich aber mal wieder gelernt, dass der Fehler oft vor dem Emulator sitzt.


    Ins Grübeln gebracht hat mich diese Demo hier: https://csdb.dk/release/download.php?id=234994

    Die ist extra für den Debug Border Mode von VICE geschrieben worden, da man soweit ja eh nicht auf einem normalen C64 in die Ecke schauen kann. Bei dieser Demo gibt es auch Linien die über die gesamte Breite gehen, aber hier ist kein extra Pixel zu sehen. Also frage ich mich, wo kommt dieses komische Pixel bei mir her?