letzter Beitrag von Sokrates am
Ein PAL-C64 läuft mit 985248Hz, wobei das wohl nur mit "VIC off" ausschöpfbar ist. Wieviele Cycles/s stehen denn "normal" zur Verfügung, also mit eingeschaltetem Bild? Und wieviel mit Sprites? Hat die Anzahl der Sprites einen Einfluss? Ein ungefährer Richtwert würde reichen...
Die Badlines klauen 40*42=1680 Zyklen pro Frame, also 84000 Zyklen pro Sekunde bei PAL. Das mit den Sprites muss jemand anderes beantworten...
Die 25 Badlines in den Standardbildschirmmodi klauen 1000 - 1075 Zyklen pro Frame, bei Sprites hängt das sehr stark davon ab, welche aktiv sind und wie sie angeordnet sind. Bei 8 Sprites auf einer Höhe wären es 339 Zyklen, bei 8 Sprites untereinander dagegen schon 840.
Du hast 25 badlines pro Frame. Jede davon ist zwischen 40 und 43 Zyklen lang. Wie lang hängt ab von der Anzahl der Schreibzyklen die beim Stoppen der CPU noch anliegen. Sind beim 6502 maximal 3 am Stück.
Also 25 x 43 x 50 = 53750 Zyklen die man dafür abziehen muss. Jedes Sprite braucht pro Zeile 3 Zyklen und ist 21 Zeilen hoch, ergibt 63 Zyklen. Wobei vor dem Fetch eines jeden Sprites (bzw. einer Zeile davon) auch wieder 3 Zyklen zu warten sind wenn vorher nicht schon ein direkt davorliegendes Sprite geholt wurde.
Grob gesagt: Sprite 0 und Sprite 2 zu verwenden kostet mehr Zyklen als Sprite 0 und Sprite 1.
Ich hoffe ich habe mich nicht verrechnet.
Ach verflixt, Zeilen und Spaltenzahl verwechselt. Claude und Gerrit haben natürlich recht!
Jedes Sprite braucht pro Zeile 3 Zyklen
Meines Wissens pro Zeile vier Zyklen. Der Spritepointer wird in jeder Zeile neu geholt, bevor die eigentlichen Daten gelesen werden.
Es geht doch aber nicht speziell um die Badlines. Dass die CPU noch irgendwas abarbeitet, ändert doch nichts an Takten, die verbraucht werden können. Es bleiben doch 19.656.
Also klauen die Badlines doch immer nur 40/1.000 Takte, oder nicht?
Zu den Sprites: Hier gibt es eine einleuchtende Erklärung, dass die nur 2 Takte pro Sprite benötigen: http://csdb.dk/forums/index.ph…icid=24716&showallposts=1
Leuchtet ja auch ein. Bei drei oder vier Takten wäre eine Darstellung von acht Sprites auf einer Badline gar nicht möglich.
Siehe auch hier: http://www.zimmers.net/anonftp…ments/chipdata/pal.timing
Also dürften für die Sprites 2 * 8 *21 = 336 Takte drauf gehen. Im csdb-Link steht noch was von einem eingesparten Takt. Egal.
19.656 ./. 1.000 ./. 336 = 18.320 x 50(.12) = 918.198 Hz (~93%)
Leuchtet ja auch ein. Bei drei oder vier Takten wäre eine Darstellung von acht Sprites auf einer Badline gar nicht möglich.
Es sind 4 Speicherzugriffe, aber der VIC kann ja 2 Speicherzugriffe pro Takt machen wenn er die CPU anhält.
Trotzdem muss man aufpassen welche Sprites man benutzt weil bei schlechter Verteilung die CPU wieder angehalten werden muss. Oder hält der VIC einfach die CPU an bis er die Daten des letzten aktiven Sprites geladen hat? (Also Sprite 0 und Sprite 5, CPU würde angehalten bis Sprite 5 geladen ist) Aber selbst dann wäre es eine gute Idee die Sprites passend zu benutzen.
Ich kann da nicht mitreden, aber warum sollte die Spritenummer einen Unterschied machen ? Ob die "hintereinander" liegen oder nicht ist der einzelnen Abfrage derer doch egal ? Naja ihr werdet es schon wissen, genauer.
Könnte man meinen, wenn doch auch nur die aktiviert sind die auch benutzt werden.
--
"(Also Sprite 0 und Sprite 5, CPU würde angehalten bis Sprite 5 geladen ist)"
Warum nicht Sprite 0 bis Sprite 7. Ich denke der C64 hat 8 Sprites und nicht sechs. 
Du kannst der CPU nicht zwischendrin 2 Takte erlauben. Kommt genau dann ein IRQ rein braucht die 3 Takte um Kram auf den Stack zu schreiben und Schreibzyklen sind beim 6502 nicht unterbrechbar.
Also müsstest du die CPU entweder für alle Sprites anhalten, egal wieviele davon aktiv sind, oder eben bis zum letzten aktiven Sprite. In meinem Beispiel Sprite 5, 6 und 7 wären abgeschaltet, deren Zyklen könnte die CPU also nutzen.
Ich dachte man kann eine beliebige Kombination und -en an Spritenummern aktivieren (und deaktivieren). Also auch Sprite 0 + Sprite 4 only, der Rest aus. Als ein Beispiel nur. Und das würde dann zeitkostend genau das gleiche bedeuten wie Sprite 0 + Sprite 1 zu benutzen.
Weil zwischen Sprite 1 bis 3 dann nicht "gerödelt" wird und somit eben auch keine Takte draufgehen ;), umgangssprachlich ausgedrückt. Naja, auch egal jetzt.
Ich dachte man kann eine beliebige Kombination und -en an Spritenummern aktivieren (und deaktivieren). Also auch Sprite 0 + Sprite 4 only, der Rest aus. Als ein Beispiel nur. Und das würde dann zeitkostend genau das gleiche bedeuten wie Sprite 0 + Sprite 1 zu benutzen.
Ist ja auch richtig. Nur die Sprite-Zugriffe sind quasi in den Border verfrachtet. Sprite 0-2 in den rechten Border eine Zeile VOR der eigentlichen Sprite-Zeile; 3-7 in den linken Border der 'richtigen' Zeile. So sind alle rechtzeitig da.
Wenn man der CPU sagt dass sie die Füsse still halten soll, tut sie das nicht immer sofort: wenn gerade geschrieben wird, wird das nicht unterbrochen und es kann max. 3 schreibzugriffe am stück geben (nur bei interrupts, sonst max. 2).
Darum teilt der VIC der CPU jeweils drei takte bevor der bus genutzt wird mit dass er nix mehr tuen soll.
Alleine dadurch gehen 0-3 takte verloren, je nach dem ob geschrieben wird oder nicht, da mehr gelesen als geschrieben wird durchschnittlich bestimmt über 2.
Um ein Sprite anzuzeigen werden vier lesezugriffe benötigt. Einen um den body zu lesen (letzten 8 bytes des screens) und drei um die eigentlichen sprite daten zu lesen. Da vorher die CPU angehalten wurde wird das in zwei takten erledigt.
Und auch bei den Sprites wird drei takte bevor ein sprite gelesen wird (nur wenn angeschaltet) die CPU angehalten. Wenn die zeit nicht benötigt wird kann die CPU arbeiten.
Es macht also sehr wohl einen unterschied ob man benachbarte Sprites oder entfernte nutzt.
geklaute takte:
- in badline: 40 + 3 (0-3 schreibtakte werden ausgeführt)
- bei 8 sprites: 16 + 3 (0-3 schreibtakte werden ausgeführt)
bei allen sprites bleibt in einer badline also 1 "garantierter" takt und 0-3 schreibzugriffe (PAL; bei NTSC/65: 3 "garantierte" und 2 * 0-3 schreibzugriffe)
bei offenem border gehen auch noch sprite zugriffe im border flöten.
bei FLI ist jede zeile eine bad-line.
Danke für die klasse Erklärung! Hättest Du nicht mal Lust das für die Nachwelt im C64 Wiki festzuhalten in einer etwas ausführlicheren Form und unter Berücksichtigung der möglichen Varianten (mit/ohne Interrupt, Border etc)? Ist natürlich Arbeit, wäre aber hilfreich für viele!
