Upside Down (64er 11/1995)

Es gibt 49 Antworten in diesem Thema, welches 6.276 mal aufgerufen wurde. Der letzte Beitrag (15. Juni 2023 um 23:20) ist von Unseen.

  • Beim Raster-IRQ ist das ein Problem, in das man häufig läuft, wenn man ein scrollendes Spiel schreibt. Daher weiß ich, wie es mit der zur Verfügung stehenden Zeit da aussieht. Wie oben angemerkt, wird der normale IRQ sogar etwas häufiger aufgerufen. Dies erlaubt einen Rückschluss auf die Tatsache, dass auch dort die Zeit nicht ausreichen wird. Sorry, dass ich es vielleicht ein wenig unklar ausgedrückt habe.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Die beim Raster-IRQ zur Verfügung stehende Rasterzeit/Taktzyklen um $DINGE zu machen. (und gesperrt ist der nicht)

    Einen Raster-IRQ benutzt das Programm doch überhaupt nicht.

    Es ist doch absolut unerheblich, ob es ein Raster-IRQ ist oder mittels System-Timer ein IRQ ausgelöst wird: Während des IRQs ist zuwenig Zeit um $DINGE zu tun.

  • Es ist doch absolut unerheblich, ob es ein Raster-IRQ ist oder mittels System-Timer ein IRQ ausgelöst wird: Während des IRQs ist zuwenig Zeit um $DINGE zu tun.

    Sehe ich ähnlich wie rayden. Und deshalb frage ich mich, ob es nicht einfacher wäre, den Kernal ins RAM zu kopieren und dann derart anzupassen, das dieser den Screen- und Farb-RAM in entgegengesetzter Richtung beschreibt. Der Effekt bliebe derselbe und keine zusätzlichen IRQ's. Um alles würde sich der Kernal kümmern. Okay, wäre aber eine Lösung, die nichts mehr mit dem ursprünglichen Programm zu tun hätte...

    Gruß

    Thomas

    PS: Wenn ich komplett falsch liegen sollte, dann schiebe ich meine wirren Gedanken einfach auf die sommerlichen Temperaturen... :smile:

    Meine Projekte:
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Man könnte vermutlich den System-IRQ mit halber Geschwindigkeit triggern lassen und in der aufgerufenen eigenen Routine dann eben zweimal EA31 (zum Aktualisieren von TI etc.) aufrufen (wegen des RTI am Schluss davon muss man das dann vermutlich per PHP JSR EA31 aufrufen? Hab's nicht ausprobiert). Bringt Zeit für die eigene IRQ-Routine, aber macht evtl. die Tastaturabfrage weniger zackig und ändert natürlich nichts daran, dass recht wenig Zeit für das eigentlich laufende Programm bleibt.

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

  • Es ist doch absolut unerheblich, ob es ein Raster-IRQ ist oder mittels System-Timer ein IRQ ausgelöst wird: Während des IRQs ist zuwenig Zeit um $DINGE zu tun.

    Sehe ich ähnlich wie rayden. Und deshalb frage ich mich, ob es nicht einfacher wäre, den Kernal ins RAM zu kopieren und dann derart anzupassen, das dieser den Screen- und Farb-RAM in entgegengesetzter Richtung beschreibt. Der Effekt bliebe derselbe und keine zusätzlichen IRQ's. Um alles würde sich der Kernal kümmern. Okay, wäre aber eine Lösung, die nichts mehr mit dem ursprünglichen Programm zu tun hätte...

    Gruß

    Thomas

    PS: Wenn ich komplett falsch liegen sollte, dann schiebe ich meine wirren Gedanken einfach auf die sommerlichen Temperaturen... :smile:

    Bei $326 liegt ja der CHROUT-Vektor, den man umbiegen kann. Da braucht man den Kernal gar nicht ins RAM kopieren.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Wie oben angemerkt, wird der normale IRQ sogar etwas häufiger aufgerufen.

    Solange er gesperrt ist, wird er überhaupt nicht aufgerufen!

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • Jetzt verstehe ich Dich nicht ^^. Die ganze Funktionalität ist doch im Interrupt, wieso sollte man den sperren? Oder meinst Du, dass der IRQ nicht während seiner Bearbeitung neu aufgerufen wird? Das stimmt natürlich, aber er würde wenn er länger als 1/60 Sekunde braucht sofort danach wieder aufgerufen werden, so dass keine Rechenzeit für irgendetwas anderes übrigbliebe.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Und wenn Du bei jedem IRQ nur einen Teil des Farbrams checkt? Also einmal z.B. die obere Hälfte, beim nächsten Aufruf die untere. Bekommst halt bisserl Latenz, aber das wäre doch nicht sooo schlimm?

  • Es ist doch absolut unerheblich, ob es ein Raster-IRQ ist oder mittels System-Timer ein IRQ ausgelöst wird: Während des IRQs ist zuwenig Zeit um $DINGE zu tun.

    Na dann.

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • Das stimmt natürlich, aber er würde wenn er länger als 1/60 Sekunde braucht sofort danach wieder aufgerufen werden, so dass keine Rechenzeit für irgendetwas anderes übrigbliebe.

    Also, jetzt mal Butter bei die Fische. Dieses kleine Testprogramm kopiert bei jedem 16. IRQ-Aufruf 4 (!) Kilobyte an Daten. Dazu braucht es laut VICE Monitor ca. 70 Tausend Taktzyklen. Ja, das verlangsamt den Rechner natürlich spürbar, aber das war es dann auch. Wo soll denn nun bitte das grundsätzliche Problem sein?

    Dateien

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • Und wenn Du bei jedem IRQ nur einen Teil des Farbrams checkt? Also einmal z.B. die obere Hälfte, beim nächsten Aufruf die untere. Bekommst halt bisserl Latenz, aber das wäre doch nicht sooo schlimm?

    Das ist grundsätzlich eine gute Idee!

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • [...] Dazu braucht es laut VICE Monitor ca. 70 Tausend Taktzyklen. Ja, das verlangsamt den Rechner natürlich spürbar, aber das war es dann auch. Wo soll denn nun bitte das grundsätzliche Problem sein?

    Genau da liegt das grundsätzliche Problem: Auf einem PAL-C64 hast Du in der Theorie 19656 CPU cycles (Theorie deswegen, weil noch badlines, System-IRQ, etc. abgezogen werden müssen). Wenn Deine Kopier-Routine ca. 70000 cycles zum Kopieren von 4 KB benötigt, sind das etwas mehr als 4 frames (eigentlich eher 5), welche dafür benötigt werden. D.h. der eigentliche System-IRQ wird für diese Anzahl an frames nicht aufgerufen, weil Deine Kopier-Routine noch beschäftigt ist. Somit wären wir wieder bei meiner ursprünglichen Aussage, dass während des IRQs zuwenig Zeit ist, um $DINGE zu tun. Auch wenn Du das Kopieren aufteilst in chunks, also in mehrere IRQs, so wird dieses nacheinander Kopieren optisch zu erkennen sein.

  • Das stimmt natürlich, aber er würde wenn er länger als 1/60 Sekunde braucht sofort danach wieder aufgerufen werden, so dass keine Rechenzeit für irgendetwas anderes übrigbliebe.

    Also, jetzt mal Butter bei die Fische. Dieses kleine Testprogramm kopiert bei jedem 16. IRQ-Aufruf 4 (!) Kilobyte an Daten. Dazu braucht es laut VICE Monitor ca. 70 Tausend Taktzyklen. Ja, das verlangsamt den Rechner natürlich spürbar, aber das war es dann auch. Wo soll denn nun bitte das grundsätzliche Problem sein?

    Ah, jetzt klärt sich die Lage langsam :)! Dass es nur noch jeden 16. IRQ aufgerufen wird hatte ich verpasst. Ein IRQ hat maximal knapp 17000 Zyklen Zeit zur Verfügung. So verpasst Du 3 Stück oder so, was in der Tat vermutlich kein Drama wäre. Etwas chicer wäre es vermutlich, die Last auf mehrere IRQs zu verteilen, dann hinkt die Uhr nicht hinterher usw.


    EDIT: zu langsam :sleeping:

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Übrigens möchte ich an dieser Stelle mal meiner Begeisterung dafür Luft machen, dass Du ältere Programme so liebevoll technisch überholst! Ich hoffe Du verstehst meine Posts nicht als Kritik oder demotivierend, ich möchte nämlich eigentlich nur helfen, Ideen für die bestmöglichen Lösungen zu finden. Hut ab, weiter so, Respekt usw. :thumbup:!

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Übrigens möchte ich an dieser Stelle mal meiner Begeisterung dafür Luft machen, dass Du ältere Programme so liebevoll technisch überholst! Ich hoffe Du verstehst meine Posts nicht als Kritik oder demotivierend, ich möchte nämlich eigentlich nur helfen, Ideen für die bestmöglichen Lösungen zu finden. Hut ab, weiter so, Respekt usw. :thumbup:!

    Bin immer froh über dein Feedback und habe auch schon einiges dadurch gelernt! :emojiSmiley-106:

    Zum Programm selbst: Es ist etwas kniffliger als gedacht. Denn das Farb-RAM besteht ja, wenn es sich verändert, aus einer Mischung von bereits korrigierten Farben und Farben, die man jetzt noch verschieben muss. Es bringt also nichts, einfach das Farb-RAM zu spiegeln. Man muss die konkreten Stellen herauspflücken, die sich verändert haben, sie an die richtige Stelle schieben und die an unerwünschter Stelle veränderten Farben aus der Kopie, die man vorher angelegt hat, wiederherstellen. Zumindest ist mir bisher kein besserer Ansatz eingefallen...

    Ich bin dran. :)

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • Wird nicht so klappen, weil z.B. beim im Direktmodus scrollen ja auch aus dem Farbram gelesen wird...

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

  • Wird nicht so klappen, weil z.B. beim im Direktmodus scrollen ja auch aus dem Farbram gelesen wird...

    Und? Ist das schlimmer als irgendeine andere "Quelle" für die Farb-RAM-Werte? Sehe den prinzipiellen Unterschied nicht.

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • Du kannst zwar in der IRQ-Routine erkennen, welche Stellen im Farb-RAM vom KERNAL verändert wurden, aber weil der KERNAL insbesondere beim Scrolling evtl. "falsche" (bereits gespiegelte) Werte aus dem Farb-RAM gelesen hat, sind die von ihm veränderten Stellen evtl. auch mit falschen Werten beschrieben. Schwer zu erklären. Überleg Dir, wie Textmodus-Scrolling umgesetzt wird.

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

  • Verflixt, da hat 1570 recht. Denn der IRQ geht davon aus, dass die richtigen Werte an der falschen Stelle im Farb-RAM gesetzt werden. Beim Scrolling werden aber leider Werte aus der Nachbarzeile gelesen (die ja durch die Spiegelung ganz woanders ist), so dass falsche Werte an der falschen Stelle geschrieben werden.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Da im bisherigen Ansatz das original Screen-RAM beibehalten wird (quasi als Buffer) und von dort gelesen wird, um es "invertiert" woanders hinzuschreiben, müsste man das Color-RAM ebenfalls vorab "woanders" buffern um es dann "invertiert" zu schreiben.

    Pointer für die aktuelle Position des Cursors "im" Color-Ram findet sich in der zeropage in $F3 und $F4. Gesetzt wird es im KERNAL ab $EA24. Mit einem "Umbiegen" des Color-RAM-Pointers hätte man zumindest User-/Cursor- edit abgedeckt, aber POKEs ins Color-RAM gehen natürlich weiterhin ins Color-RAM.

    Oder Du fährst einen ganz anderen Ansatz und stellst von Charcater-Mode auf HiRes-Bitmap-Mode um: Dann kannst Du das reguläre Color-RAM als Buffer nutzen, das gesamte Color-RAM "invertiert" in Dein Screen-RAM schreiben und die Farben passen. Zwar benötigt die Transkodierung der Chars in Bitmap ein wenig mehr Zyklen, aber da die Anzahl an Zyklen anscheinend kein Problem darstellt, wäre das eventuell ein Lösungsansatz.