letzter Beitrag von Vernunftmensch am
ZitatOriginally posted by Roland
Ehm...sind 6 PLAs (wenn der IRQ über $0314/0315 - also dem Kernal - geht).
Kernal? Wer benutzt denn sowas?
ZitatOriginally posted by Oliver_A
Wobei ich sagen würde, dass die CIA Methode leichter als die Lightpen methode ist. Frage ist auch: welcher Anfänger möchte die X-Position auslesen.
Beide Methoden sind aber nichts für Anfänger. Die Doppel-IRQ-Methode ist eigentlich die einfachste.
Hallo zusammen,
erstmal sorry, dass ich den Thread nochmal aufwärme... :rotwerd:
Ich hab' mich endlich mal in Ruhe mit dem Beispiel von Roland beschäftigen können, und hab' mir das mal ein bisschen angepasst, klappt soweit auch wunderbar. So sieht das jetzt mal aus...
Jetzt wollte ich aber im unter "STABLE" nicht nur das Low-Byte für den nächsten Interrupt "INTMAIN1" setzen, sondern auch das High-Byte, da mein Code ja durchaus auch einmal an einer Pagegrenze liegen kann und sich das High-Byte dann ändert.
Ich habe dann die zwei NOP's und das ASL $D019 (zusammen 10 Zyklen) durch Befehle mit dem gleichen Zyklenverbrauch ersetzt, etwa so...
Sind also an der Stelle ebenfalls 10 Zyklen, aber mein IRQ flattert dann um 1 Zyklus. O.k., die Befehle haben zwar genau 1 Byte mehr, aber das kann doch net angehen, oder? Ich dachte, es kommt nur auf die verbrauchten Zyklen an, damit das stabil wird und bleibt...?!? 
Ich bin jetzt echt ein bisschen ratlos. Hat da jemand noch ein paar Tips für mich? Ich hab' beide Beispiele mal mit angehängt.
Gruß,
Mnemonic
Eventuell war das vorher auch gar nicht richtig stabil. Ersetze doch mal deine "SCHLEIFE" durch eine Abfolge von Befehlen mit möglichst unterschiedlicher Ausführungszeit, statt nur dem einen JMP. Es kann sein, dass sich das vorher so ergeben hat, dass es stabil erschien. Absolut wichtig ist, dass das Timing des Vergleichs für "NEXT" genau stimmt (hab ich jetzt nicht nachgeguckt). Zähl doch nochmal die Zyklen nach.
am besten beim austimen von sowas im hauptprogram immer was "richtiges" laufen lassen.... musikroutine oder sowas, völlig egal
nein... das problem ist, dass der neue IRQ einfach zu spät mit dem CLI wieder freigegeben wird.
Der erste IRQ verbraucht ja durch die Kernal-Routine auf $FF48 bis er dann über ($0314) auf den ersten IRQ Teil springt einiges an Zyklen.
Wenn du dann noch 6 weitere Zyklen für das LDA #$xx STA $0315 vor dem ASL $D019 CLI einbaust, hat die neue Rasterzeile in der
der zweite IRQ starten soll evtl. schon angefangen.
Das bringt natürlich das Timing durcheinander....
...d.h. dass die erste Routine aber wohl auch nicht ganz korrekt ist (mit den 2 NOPs und dem ASL $D019...) ... da ist wenn du mit dem Kernal IRQ über $0314 arbeitest wirklich sehr wenig Zeit...für das umsetzen von $0314 UND $0315 reichts glaube ich nicht.
....müsste aber um ganz sicher zu sein das nochmal ganz genau anschauen...
Und die Moral von der Geschicht', benutze den Kernal nicht. 
@sauhund: Hm, also in den angehängten Beispielen läuft ja 'ne Musikroutine, und die ist echt nicht grade "rund".
Beim ersten Beispiel ist es damit wirklich absolut stabil, hatte auch noch andere Sachen in den Beispielen drin vorher, so dass die sich wirklich nur in den 2 NOP's + ASL $D019 bzw. LDA #>INTMAIN1 + STA $0315 + STA $D019 unterschieden haben. Das zweite "flattert" halt um einen Zyklus.
Roland: Die NOP's in der ersten Routine sind nur da um zu testen, wieviel "Overhead" ich da noch habe, sind wohl genau diese vier Zyklen. Damit bzw. weniger ist es auch komplett stabil.
Ich wollte halt jetzt diese vier "freien" Zyklen zusammen mit den 6 Zyklen vom ASL $D019 (10 insgesamt) dafür verwenden, um auch das High-Byte zu setzen, d.h. 2 Zyklen für das LDA #>INTMAIN1, 4 für das STA $D015 und 4 für das STA $D019 als Ersatz für das ASL $D019 mit 6 Zyklen. Meine Idee ist halt, das ASL $D019 durch ein STA $D019 zu ersetzen, um zwei Zyklen freizukriegen für das Setzen des High-Byte.
Sind in beiden Varianten exakt 10 Zyklen, hab' ich auch im Monitor vom CCS64 verfolgen können. Deshalb verstehe ich halt nicht wirklich, wieso es im zweiten Beispiel flattert, trotz der exakt gleichen Anzahl an Taktzyklen.
Ratloser Gruß,
Mnemonic
Du solltest die Musikroutine aber außerhalb des IRQ einbinden (also innerhalb der SCHLEIFE im Hauptprogramm), um eventuelle Unstimmigkeiten beim IRQ-Timing zu entdecken. Das klingt dann zwar nicht mehr so schön, aber das ist ja beim Debuggen erstmal egal 
also... wenn du bei deiner ersten Routine anstelle von NOP NOP ASL $D019 ein NOP NOP NOP STA $D019 machst, flackert es auch!!!
entscheident ist wohl, WANN der $D019 Befehl den VIC IRQ wieder freigibt...und das passiert beim ASL $D019 eben zu einem anderen Zeitpunkt als beim STA $D019.
Hm, aber der Schreibzugriff auf das VIC-Register ist in beiden Fällen im gleichen Zyklus. Natürlich kommt's drauf an, was man da so in das Register schreibt. 
Bei ASL wird Bit 0 immer cleared, und dieses Bit ist ja für den Raster-IRQ zuständig.
Kann man denn überhaupt den Rasterlatch löschen, wenn man da einfach irgendwas reinschreibt wie in obigem Programm? Ich hab bisher immer gedacht, man muss wenigstens die Bits für den IRQ-Auslöser zurückschreiben (sprich Bit#0).
Ein kurzer Test mit CCS64 scheint zu bestätigen, dass n Wert wie $20 nicht geht, aber aufm echten Cevi hab ich bisher immer nur entweder den Registerinhalt zurückgeschrieben oder LSR oder ähnliche RMW-Befehle probiert (und bin auch jetzt zu faul das auszuprobieren...)
Roland: Ja, hab' ich mir eben auch nochmal so angeschaut... wenn das so ist, dann war's wohl nix mit meiner Idee, einfach den Inhalt des Akkus, wo ja ohnehin was drinsteht, in $D019 zu pusten, um beim Löschen des IRQ-Latch zwei Zyklen zu sparen. 
Auf die Idee, dass der STA-Befehl auf $D019 den VIC evtl. erst zu 'nem anderen Zeitpunkt wieder freigibt als der ASL, wär' ich wohl im Leben net gekommen...
Dann werd' ich mal versuchen, mir das mit den IRQ's ohne Kernel draufzuschaffen und probier's dann mal damit... obwohl's mir da jetzt auch schon wieder vor dem austimen graut. 
Aber was hilft's, da muss ich dann jetzt halt auch durch.
Danke für Eure Mühe und ein schönes Wochenende,
Mnemonic
Zitat
Bei ASL wird Bit 0 immer cleared, und dieses Bit ist ja für den Raster-IRQ zuständig.
aber vorher kommt noch der dummy write der den original wert zurückschreibt.... wenn das nicht so wäre würde das garnicht funktionieren
Damit dürfte dann auch klar sein warum das 2. Programmbeispiel nicht geht: Der Interrupt-Latch wird nicht richtig geklärt und der 2. Irq springt sofort nach dem CLI an, egal ob nu Rasterzeile 3c oder 3d ist...
@sauhund,
OK, dann macht auch die Registerbeschreibung aus AAY64/Mapping the 64 wieder Sinn... (Bits auf 1 setzen, um zu schreiben). Wann passiert denn dieser Write bei ASL & Co?
Ehm....pass mal auf. Kleiner Trick
Dreh einfach mal das LDA #$45 STA $0314 LDA #$20 STA $0315 um.... also: LDA #$20 STA $0315 LDA #$45 STA $0314 ....
wichtig ist halt, dass BIT 0 geschrieben wird.
Oder du setzt das LDA #$3D STA $D012 nach hinten (direkt vor den STA $D019).
Ob bei ganz ungünstiger Zyklenverteilung der neue IRQ allerdings noch rechtzeitig freigegeben wird bin ich mir nicht sicher...
Zitat
OK, dann macht auch die Registerbeschreibung aus AAY64/Mapping the 64 wieder Sinn... (Bits auf 1 setzen, um zu schreiben). Wann passiert denn dieser Write bei ASL & Co?
die RMW befehle sind eigentlich alle RWMW (vereinfacht, passt aber in der praxis eigentlich immer =P)
Du kannst ja n "Hybrid"-IRQ, d.h. den ersten mit und den zweiten ohne Kernal machen, der sich vom Timing her vom ersten Programmbeispiel nicht unterscheiden sollte, aber evtl. Murks produziert, wenn der stabilisierende IRQ über die Nop-schleife hinausgeht:
Wenn ich mich da nicht irgendwo furchtbar vertan hab (was nicht ungewöhlich wär) sollte das eigentlich so gehen.
Hi...ich hab hier eine Variante, die GANZ OHNE Umsetzen der $0314 / $0315 Adressen auskommt
