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.
Upside Down (64er 11/1995)
-
goloMAK -
9. Juni 2023 um 18:40 -
Erledigt
Es gibt 49 Antworten in diesem Thema, welches 6.278 mal aufgerufen wurde. Der letzte Beitrag (
-
-
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...

-
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.
-
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...

Bei $326 liegt ja der CHROUT-Vektor, den man umbiegen kann. Da braucht man den Kernal gar nicht ins RAM kopieren.
-
Wie oben angemerkt, wird der normale IRQ sogar etwas häufiger aufgerufen.
Solange er gesperrt ist, wird er überhaupt nicht aufgerufen!
-
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. -
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.
-
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?
Code
Alles anzeigen*=$c000 ; +++ IRQ-Test +++ switch = $02 src = $fa;$fb dst = $fc;$fd BASIC = $a000 ; INIT sei lda #<newirq sta $0314 lda #>newirq sta $0315 cli rts ; ------------------------- newirq inc switch lda switch and #$0f ; Ausführung bei jedem sta switch ; 16. IRQ-Aufruf bne .skip ; Kopierroutine lda #<BASIC sta src sta dst lda #>BASIC sta src+1 sta dst+1 ldx #$10 ; 16 Pages = 4 KB ldy #$00 -- lda (src),y sta (dst),y dey bne -- inc src+1 inc dst+1 dex bne -- .skip jmp $ea31 -
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!
-
[...] 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?
Code
Alles anzeigen*=$c000 ; +++ IRQ-Test +++ switch = $02 src = $fa;$fb dst = $fc;$fd BASIC = $a000 ; INIT sei lda #<newirq sta $0314 lda #>newirq sta $0315 cli rts ; ------------------------- newirq inc switch lda switch and #$0f ; Ausführung bei jedem sta switch ; 16. IRQ-Aufruf bne .skip ; Kopierroutine lda #<BASIC sta src sta dst lda #>BASIC sta src+1 sta dst+1 ldx #$10 ; 16 Pages = 4 KB ldy #$00 -- lda (src),y sta (dst),y dey bne -- inc src+1 inc dst+1 dex bne -- .skip jmp $ea31Ah, 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
-
- Interessanter Beitrag
Ü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.
! -
Ü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.
!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.

-
Wird nicht so klappen, weil z.B. beim im Direktmodus scrollen ja auch aus dem Farbram gelesen wird...
-
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.
-
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.
-
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.
-
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.
-