Unterbrechungsroutinen C64

Es gibt 134 Antworten in diesem Thema, welches 16.929 mal aufgerufen wurde. Der letzte Beitrag (7. April 2013 um 15:24) ist von sauhund.

  • zu 1. Nein, der Rasterstrahl läuft durch, du kannst nur reagieren, nicht kontrollieren

    zu 2. und 3. Nur ein IRQ kann zu einer Zeit bedient werden, Es ist Aufgabe des Handlers festzustellen wer der Auslöser des IRQs war und dessen Handling entsprechend zu schedulen und natürlich auch wieder rechtzeitig rti zu machen damit das eigene Programm bzw. dessen IRQs sinnvoll weiterlaufen können.

    Aber ganz ehrlich, ich glaube du gehst die Sache mit ein paar Knoten zuviel im Kopf an. Wenn du das Basic-Programm verstanden hast, dann bau daraus mal eine Assembler-Version. Wenn das tut, dann versuch mal die Schleife zu einem RasterIRQ-Handler umzuschreiben.

  • Wenn du das Basic-Programm verstanden hast, dann bau daraus mal eine Assembler-Version. Wenn das tut, dann versuch mal die Schleife zu einem RasterIRQ-Handler umzuschreiben.

    Und es gibt sogar noch einen Zwischenschritt: sobald du die Assemblerversion hast kannst du den delayloop des Basic-Programms durch eine Abfrage von $d012 ersetzen und dort auf das Erreichen einer bestimmten Rasterzeile warten. Damit wäre das Sternchendemo sofort sauber und butterweich.

    Also so etwa:

    Code
    lda #$fa
    .l0 cmp $d012
        bne .l0


    Das Basic-Pedant dazu sähe dann so aus:

    Das ist nur das Konzept in Basic gegossen, in der Praxis sieht das nicht sauber aus, weil Basic einfach zu langsam ist um einen Schleifendurchlauf binnen eines vblanks zu erledigen. Wird das so 1:1 nach Assembler übertragen solltest du aber ein mit 50fps butterweich scrollendes Sternenfeld haben :smile:

  • Die oberen fünf Zeilen eilen voraus. Warum?

  • Du wartest bis Rasterzeile 255 und kopierst dann den ganzen Screen. Das geht sich vermutlich nicht ganz aus, bevor der neue Screen angezeigt wird. Da siehst du dann einen Sprung.

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Zitat

    Du wartest bis Rasterzeile 255 und kopierst dann den ganzen Screen. Das geht sich vermutlich nicht ganz aus, bevor der neue Screen angezeigt wird. Da siehst du dann einen Sprung.


    wenn der screen mal überhaupt kopiert würde, dann wäre das noch das geringste problem =P

    Vernunftmensch: ich hab echt noch niemanden gesehen der so konsequent jeden tip ignoriert und sich dann die denkbar schlechteste aller möglichkeiten aussucht. du solltest wirklich mal vergessen das sowas wie inline-assembler existiert - das ist ein werkzeug für leute die wirklich *sehr genau* wissen was sie tun, und selbst die schiessen sich damit oftmals selbst in den fuss. versuch doch mal das obige basic program zeile für zeile 1:1 in ein reines assemblerprogramm zu übersetzen. wenn das dann läuft sollte es ein leichtes sein selbiges so zu ändern das es in eine andre richtung scrollt.

  • Problem elemeniert. Jetzt geht der wirklich nur einmal in die Schleife rein pro Frame.

    Trotzdem eilen die ersten fünf Zeilen voraus :?:

    Ich erlaube mir eine kleine Abweichung.... :whistling:
    D.h. Sterne3.prg scrollt in die andere Richtung. :smile: @sauhund

  • Wah, bring mal deinen Assemblercode in lesbare Form und lass diese __asm__ makros weg...
    Also grundsätzlich solltest du deine Sternchen nur einmal zeichnen und dann in der Schleife nur noch $d016 beackern.
    Außerdem ist die letzte sichtbare Zeile bei PAL-Geräten 250, nicht 255.

    Hier das ganze mal kommentiert, und mit dämlicher Sternchenfüllroutine:

  • Vernunftmensch: ich hab echt noch niemanden gesehen der so konsequent jeden tip ignoriert und sich dann die denkbar schlechteste aller möglichkeiten aussucht.

    Vernunftmensch: Hör da mal auf Sauhund, dir helfen zu wollen ist eine echt nervenaufreibende Sache: man erzählt dir was und öffnet dir einen Weg und du fängst an irgendwelchen Unfug zu treiben auf den man im Leben nicht kommen würde und man fragt sich, ob man sich selbst wirklich so unverständlich ausdrückt oder ob Missverständnisse so eine Art persönliches Hobby von dir sind. :smile:

  • Hai.

    Ich habe Deine Assemblerroutine in eine Assemblerdatei reinkopiert (bei heap am Ende fehlte noch ein Doppelpunkt), selbiges Problem. Die ersten vier Zeilen eilen dem Rest voraus.

    :motz:

    ((auf dem vice x64 unter ubuntu))

    Läuft die untere Prg bei Dir vielleicht sogar reibungsfrei?

  • Also hier unter WinVICE 2.2 auf WinXP läufts flüssig (zwischendurch mal kleine Ruckler, aber alle Zeilen gleichmäßig).

  • Hai.

    Ich habe Deine Assemblerroutine in eine Assemblerdatei reinkopiert (bei heap am Ende fehlte noch ein Doppelpunkt), selbiges Problem. Die ersten vier Zeilen eilen dem Rest voraus.

    :motz:

    ((auf dem vice x64 unter ubuntu))

    Läuft die untere Prg bei Dir vielleicht sogar reibungsfrei?

    Kein Grund zu Motzen, den Doppelpunkt habe ich mal nachgetragen. Dein problem.prg ist 45k groß, was hast du denn da alles drin? Meine Routine oben passt zumindest in 1k...

  • Läuft die untere Prg bei Dir vielleicht sogar reibungsfrei?

    Also ich hab jetzt mal das 180-Block-Sternchendemo (Rekord?) in vice geladen und es zeigt tatsächlich ein anderes Timingverhalten als mein acme-binary hier. Den Blick in den Disassmbler spare ich mir angesichts dieser Größe dann doch.

    Allerdings sehe ich auch da kein Tearing, nur das übliche Emulatorgeruckel. Hast du schonmal Uridium bei dir im Emulator laufen lassen? Gibts da Tearing? Ich würde vermuten, dass dein Emulator ein Tearingproblem hat. Damit eigenet er sich natürlich nicht zur RasterIRQ-Entwicklung :smile:

  • Dein problem.prg ist 45k groß, was hast du denn da alles drin?


    Das ist eins seiner verblüffenden Geheimnisse, wie er sowas hinbekommt. :smile:

    Trotzdem: auch hier mit Vice/Linux scrollt alles butterweich.

  • SUPER :)

    Da bin ich aber froh.

    (Die 64kEngine unseres Videospiels einfach um eine Startroutine erweitert. War das schnellste, was ich ´mal eben so machen konnte, weil ich da auch eine Assemblerdatei für Hochgeschwindigkeitsroutinen nebenher laufen lasse.)

    :party::biglach::chuck:

  • Jetzt hat mich das Thema doch nicht losgelassen und ich habe wegen des Ruckeln das ganze nochmal überdacht und am echten C64 probiert.

    Mein Vorschlag auf die Rasterzeile zu warten ist so in der Tat ungenau und wackelig, weil ich zum einen die exakte Rasterzeile verpassen kann oder -- wenn ich zu schnell bin -- eine Rasterzeile mehrmals bearbeite, weil beim erneuten Auslesen zuwenig Zeit vergangen ist.

    Ich muss also in zwei Stufen warten, erstens solange bis der Rasterstrahl kleiner als die Wunschposition ist und zeitens solange bis der Rasterstrahl größer gleich meiner Wunschposition ist. So ist gewährleistet, dass ich nur einmal pro Bilddurchlauf in die Scrollroutine reinlaufe und ich zum anderen eine Toleranz habe, falls ich mal die exakte Zeile verpassen sollte.

    Und mit diesem überarbeiteten Code habe ich dann tatsächlich butterweiches 50fps-Scrolling: