letzter Beitrag von Gold Beaver am
1 - irq wird getriggert, aktueller befehl wird zuende ausgeführt
2 - programmcounter lowbyte auf den stack schreiben
3 - programmcounter highbyte auf den stack schreiben
4 - status auf den stack schreiben
5 - programmcounter lowbyte vom irq vektor lesen
6 - programmcounter highbyte vom irq vektor lesen
?
k.A. wo der bleibt, ich weiss nur, dass man bis zur ersten Instruktion im Interrupthandler mindestens 9 Zyklen verbraucht (inkl. mindestens 1 Nop). Vielleicht holt die CPU ja einfach nur mal kurz Luft, in Erwartung atemberaubender Rastertricks...
was hast du eigentlich immer mit den NOPs ? wo kommt der her? 
Das wäre doch mal wieder was für ne eBay Auktion.... 10 ungebrauchte NOPs zu verkaufen 
Wenn die unter 10 Euro kosten schlag ich zu
Äh, ok, ich meinte jetzt den 2. der Doppelinterrupts, das Nop kommt dann noch aus der Nop-Sequenz des 1. Interrupts. Das wär dann der aktuelle Befehl, der noch zu Ende gemacht wird, wenn der IRQ getriggert wird.
Hehe... Na die Diskussion hier beruhigt mich 
....meine Timingroutinen alle furchtbar falsch, funktionieren aber trotzdem...
Da kannste mal sehen, was der C64 für ein Trecker ist, der alles platt macht und alles schluckt.
1 Takt, da sch.e.i.s.s.t er drauf.
mfg
Mh... Nur so wie ich es bislang verstanden habe, funktioniert der ganze Trick ja eben nur deshalb, wenn diese "CMP $D012, BEQ"-Geschichte exakt an der "richtigen Stelle" kommt. Wenn man das "zu früh" ausführt, würde das doch zwangsläufig dazu führen, dass der zusätzliche BEQ-Zyklus immer ausgeführt wird, oder nicht?
jo, das stimmt
Da kannste mal sehen, was der C64 für ein Trecker ist, der alles platt macht und alles schluckt.
Hehe, sowas wird ja heute leider gar nicht mehr gebaut
Gut.
Jetzt fehlt mir zu meinem Glück ja eigentlich nur noch das Verständnis, wie man Bad Lines richtig auszählt.
So wie ich das verstanden habe, so hat man in Bad Lines mindestens 20 Zyklen zur Verfügung (11 am Anfang und 9 am Ende). Aber was ist nun mit diesen 3 ominösen Zyklen (12,13,14), welche angeblich noch ausgeführt werden, falls es sich um Schreibzugriffe handelt?
Wenn ich jetzt z.B. so'n STA Befehl habe, wieviele Taktzyklen davon sind denn nun "Schreibzugriffe"? Also 4 können es ja nicht sein, da der Prozessor ja maximal 3 Schreibzugriffe hintereinander ausführt.
Und dann ist da natürlich noch die Frage: Wenn ich eine Bad Line unterdrücken will [soweit ich das bisher kapiert habe untere drei Bits von $d011 <> untere drei Bits von $d012] muss ich $d011 dann schon am Ende der vorherigen Rasterzeile "präparieren" oder reicht es, wenn ich das direkt am Anfang einer Bad Line mache, weil die erste 9 Zyklen ja eh noch im Border sind?
Wenn ich jetzt z.B. so'n STA Befehl habe, wieviele Taktzyklen davon sind denn nun "Schreibzugriffe"? Also 4 können es ja nicht sein, da der Prozessor ja maximal 3 Schreibzugriffe hintereinander ausführt.
STA $1234 = $8D $34 $12
Das wären schonmal 3 Lesezyklen. Und jetzt mal scharf überlegen, wieviele der 4 Taktzyklen nun Schreibzyklen sein könnten
Okay ...
Hab mir jetzt dazu nochmal sämtliche Befehle und Abläufe überflogen [in "Alles über den C64" von M&T]. Allerdings ist mir nun nicht klar, wann es überhaupt zu mehr als einem Schreibzugriff in Folge kommt.
Bei RMW-Befehlen (RMW = Read-Modify-Write) wird in den letzten beiden Zyklen erst der alte Wert zurückgeschrieben und dann der geänderte. Nur deswegen kann man Raster-IRQs mit DEC $D019 bestätigen, normalerweise müsste es LDA $D019 STA $D019 sein.
Und dann sind da noch die Stack-Befehle wie JSR und BRK, die mehr als 1 Schreibzyklus hintereinander haben.
Bei so Befehlen wie INC, ASL, ROL etc., wo der Wert einer Speicherstelle direkt ohne Umweg über den Akku oder X-, Y-Register verändert werden, sind so Kandidaten. Die schreiben im vorletzten Takt noch mal den ursprünglichen Wert zurück, bevor sie dann den geänderten Wert schreiben.
Deswegen kann man auch mit z.B. INC $d019 VIC-Interrupts "abhaken", und spart sogar noch 2 Zyklen gegenüber LDA $d019 STA $d019.
Deswegen kann man auch mit z.B. INC $d019 VIC-Interrupts "abhaken", und spart sogar noch 2 Zyklen gegenüber LDA $d019 STA $d019.
Spart aber 0 Zyklen gegenüber LDA #$01 STA $D019 und -2 Zyklen wenn man STA $D019 einfach so machen kann weil ein voriger Akku-Wert schon Bit 0 gesetzt hatte.
Spart aber 0 Zyklen gegenüber LDA #$01 STA $D019
Ok, spart dafür aber noch zusätzlich 2 Byte Und wenn man zusätzlich zum RasterIRQ noch andere Interrupts aktiv hat (kommt zwar selten vor, aber man weiss ja nie), hilft das auch nicht viel.
Zitat
und -2 Zyklen wenn man STA $D019 einfach so machen kann weil ein voriger Akku-Wert schon Bit 0 gesetzt hatte.
Gibt es dafür n Anwendungsbeispiel, wo das Sinn macht? Dafür scheint man ja auf "freilaufenden Code" ausserhalb des Interrupts weitestgehend verzichten zu müssen, um diesen Zustand herbeizuführen (oder zumindest darf dort eines der A/X/Y-Register nicht benutzt werden).
ZitatGibt es dafür n Anwendungsbeispiel, wo das Sinn macht? Dafür scheint man ja auf "freilaufenden Code" ausserhalb des Interrupts weitestgehend verzichten zu müssen, um diesen Zustand herbeizuführen (oder zumindest darf dort eines der A/X/Y-Register nicht benutzt werden).
Du mußt ja den $d019 nur bestätigen, bevor du den IRQ wieder freigibst (mit cli oder rti). Das kann auch am Ende des IRQs sein.
Gibt es dafür n Anwendungsbeispiel, wo das Sinn macht? Dafür scheint man ja auf "freilaufenden Code" ausserhalb des Interrupts weitestgehend verzichten zu müssen, um diesen Zustand herbeizuführen (oder zumindest darf dort eines der A/X/Y-Register nicht benutzt werden).
LDA #$3B
STA $D011
STA $D019
Du mußt ja den $d019 nur bestätigen, bevor du den IRQ wieder freigibst (mit cli oder rti). Das kann auch am Ende des IRQs sein.
Oh, ja klar! Daran hatte ich gar nicht gedacht. 
