Hallo Programmierer,

ich möchte in einem TBXL-Programm die Rechengeschwindigkeit erhöhen, aber den Bildschirm nicht komplett per POKE 559,0 abschalten, sondern eine Statuszeile einblenden, dass etwas geschieht.

Ich könnte zwar die GR0-DL auch ganz kurz gestalten, also nur die drei üblichen 112er Leerzeilen, dann eine einzige LMS-GR0-Zeile mit der Meldung und Rücksprung.

Wenn ich jetzt aber die Statusmeldung z.B. in der 24. Zeile ausgeben möchte, müsste ich ja vorher 23x Leerzeilen (112) in die DL einfügen.

Wie wirken sich in diesem Zusammenhang Leerzeilen in der Display List auf die Geschwindigkeit aus? Ein Grafikspeicherzugriff dürfte ja in einer Leerzeile nicht auftreten.

Gruß,

Michael

Uuuh,

DL ist nicht mein Thema .

Aber alle Programme, die das so machen, geben immer eine Statuszeile ganz oben aus.
Muss einen Grund haben, denke ich ...

Hallo Michael,

ich meine mich zu erinnern das auch die Leerzeilen CPU Zeit sparen, aber nicht soviel wie eine ganz kurze DL. Einfach mal ausprobieren und messen.

Ciao

Carsten

Falls es nicht stört das die Statuszeile blinkt könnte man immer wenn keine Anzeige ist die ANTIC-Zeit für den Bildschirm einsparen.

Hallo Walter

GoodByteXL hat geschrieben:Aber alle Programme, die das so machen, geben immer eine Statuszeile ganz oben aus.

Bei Super(Un)Arc ist die Zeile schön in der Mitte.

Tschüß

Mathy

Hallo Michael,

um die Funktionsweise des Antic zu verstehen gehört ein kleiner Einblick in die Hardware mit dazu. Der Antic hat wie der 6502 15 Adressleitungen womit er jede einzelne Speicheradresse ansprechen kann. Er ist ein eigenständiger Prozessor mit einem eigenen Befehlssatz. Über zwei Register gibt man ihm eine Startadresse vor. Von dort aus erfolgt das Abarbeiten des individuellen Bildschirmaufbaues. Ist das Ende erreicht gibt es einen Sprung zum Anfang zurück. Jeder Befehl, auch der für einen "Blank", benötigt seine Zeit. Je größer die Anzahl der Bildpunkte auf dem Bildschirm dargestellt werden soll, umso mehr Zyklen vom 6502 werden reserviert und vom Antic zum auslesen belegt. Einfach ist dabei der Zeichensatz Mode. Hier holt sich der Antic über das angegebene Byte die Grafikmatrix aus dem Zeichensatz heraus - was sicherlich am schnellsten gehen sollte.

Bernd

PS: Der Antic hat intern auch den festen Refresh Zyklus für die DRams.
Leider kann man diesen nicht deaktivieren - was beim Austausch auf SRam Speicher einen schönen Geschwindigkeitsschub bringen würde.

ANTIC-Leerzeilen kosten fast nichts: $70 braucht gerademal 1 Takt (für den ANTIC, um die $70 aus dem Speicher zu lesen).

Im Vergleich am teuersten ist $02 (Graphics 0): 361 Takte, davon 40 für die Screencodes der 40 Zeichen und weitere 8*40 Bytes für die Zugriffe auf den Zeichensatz (8 Byte pro Zeichen).

Ein 24 Zeilen langer Gr.0-Bildschirm bremst die CPU auf 1,1 Mhz herunter. Mit nur 1 Gr.0-Zeile kommt die CPU auf 1,6 Mhz (gemeint sind freie nicht vom ANTIC verbrauchte CPU-Takte pro Sekunde).

Ein weiterer Trick, um ANTIC-DMA zu sparen: Setze den ANTIC-DMA auf "narrow playfield", d.h. 32 Zeichen/Zeile: Z.B. in Basic: POKE 559, 33. Bringt bei nur 1 darzustellenden Zeile aber nur wenig.

Gruß Dietrich

Dietrich hat geschrieben: >Im Vergleich am teuersten ist $02 (Graphics 0): 721 Takte, davon 40 für die Screencodes der 40 Zeichen und weitere 8*40 Bytes für die Zugriffe auf den Zeichensatz (8 Byte pro Zeichen)
Gruß Dietrich

Hallo Dietrich,
damit habe ich nicht gerechnet, da lag ich vollkommen verkehrt. Danke für die Info.
Könnte man den Text nicht in einem oder mehreren Playern verstecken?

Bernd

Hi,

wie ist denn das mit dem "warten auf Synchronisation"?
Das muss m.E. auch eine zeitliche Rolle spielen. Wenn gar kein Bild ausgegeben wird ist es egal, aber wenn auch nur ein Zeichen/ Pixel dargestellt wird, mus doch der Prozessor (CPU ./. Antic) warten bis das Bild/ die Zeit vorbei ist *vsynch*.

Da ich leider davon zu wenig Ahnung habe, soll es nur ein Dankanstoß sein, glaube aber mal im Zusammen mit den DLI' Interrupts gelesen zu haben: Kurze DLI=mehr Zeit für die DLI' Interrupts

Bernd hat geschrieben:damit habe ich nicht gerechnet, da lag ich vollkommen verkehrt. Danke für die Info.

Wieso? Deine Erklärung ist doch ganz OK. Für das Auslesen des Speichers (zur Darstellung von Bildschirmpunkten durch den GTIA) braucht der ANTIC Taktzyklen. Wenn der ANTIC nix aus dem Speicher liest, macht er auch kein DMA (außer für den Refresh).

Bernd hat geschrieben:Könnte man den Text nicht in einem oder mehreren Playern verstecken?

Das bringt nichts - da die Playerdaten ja auch aus dem Speicher gelesen werden müssen. Mit ANTIC-DMA kostet das genauso viel Zeit wie Graphics 8:
Wenn man den Text als Grafik im Speicher ablegt, braucht der ANTIC im Vergleich mit Graphics 0 die Screencodes der Zeichen nicht zu lesen. Mit Graphics 8 steht also etwas mehr CPU Zeit zur Verfügung, aber natürlich braucht man mehr RAM als mit Graphics 0.

dl7ukk hat geschrieben:wenn auch nur ein Zeichen/ Pixel dargestellt wird, mus doch der Prozessor (CPU ./. Antic) warten bis das Bild/ die Zeit vorbei ist *vsynch*.

Nein, der $41-ANTIC-Befehl sagt dem ANTIC nur, dass er keine Daten mehr aus dem Speicher lesen soll, bis der nächste Vertical Blank kommt. Auf die CPU hat das keine Auswirkungen. Anders verhält es sich mit dem WSYNC-Register des ANTIC. Schreibt die CPU in dieses Register, hält der ANTIC die CPU für bis zu eine Bildschirmzeile an - das wird für DLIs benötigt, die sauber eine Farbe ändern wollen.

Gruß Dietrich

Mathy hat geschrieben:Hallo Walter

GoodByteXL hat geschrieben:Aber alle Programme, die das so machen, geben immer eine Statuszeile ganz oben aus.

Bei Super(Un)Arc ist die Zeile schön in der Mitte.

Tschüß

Mathy

Hi Mathy,

Das habe ich SpartaDOS X User natürlich nicht drauf, wo ARC UNARC in der Cart drin ist. Danke für die Ergänzung.

Hi!

Wer's genauer wissen will, kann mal einen Blick auf http://www.beipmu.com/Antic_Timings.txt werfen.

In der Tabelle ist verzeichnet, zu welchem Zeitpunkt der ANTIC was macht (Display List Instruktion holen, RAM Refresh, etc.).

so long,

Hias

Hallo @alle,

vielen Dank für Eure Tipps und Hinweise!! Ich habe mich dadurch angespornt mal soweit eingelesen, dass ich es unter Turbo Basic ausprobieren konnte. Folgende Zeiten für die Abarbeitung von "FOR I=1 TO 50000:NEXT I" habe ich unter Turbo Basic XL ermittelt:

Code: Alles auswählen

Normale Display List
====================
24 Zeilen / DMA ON      : 35,76 s    ; der normale GR.0-Bildschirm
24 Zeilen / DMA OFF     : 26,26 s    ; DMA AUS

Geänderte DL
============
 1 Zeile GR.0           : 26,58 s    ; "Statuszeile" ganz oben
23 Leerz + 1 Zeile GR.0 : 26,60 s    ; "Statuszeile" ganz unten


-> Man gewinnt 25-30% an Geschwindigkeit, wenn man den Bildschirm ganz abschaltet.

-> 1-2 Statuszeilen kann man sich locker leisten und Leerzeilen fallen praktisch kaum ins Gewicht.

Dass viele Programme die Statuszeile ganz oben ausgeben, könnte damit zu tun haben, dass man die Original-GR.0-Display List dafür nur in 3 Bytes abändern muss. Man fügt direkt nach der ersten GR.0-Zeile (ab DL+6) den Rücksprungbefehl und die Rücksprungadresse (LOW/HIGH) ein. Ein PRINT in die erste (nullte) Zeile funktioniert weiterhin und man kann die 3 Bytes auch schnell wieder restaurieren. Bei der Statuszeile weiter unten muss man etwas mehr Aufwand treiben, nämlich die ganzen Leerzeilen und die Sprunganweisung setzen.

Gruß,

Michael

da ich mich auch grade an ner DL betätige, hab ich es mal ausprobiert:

es geht doch, antic abzuschalten und den/die Player als Infoteil darzustellen!
denn die player werden vom GTIA und nicht von der ANTIC erzeugt.
Es ist nur etwas mühsam Texte darzustellen da man ja PMBASE $D407 erstmal als "Muster" definieren muss, dort kann man dann mit den
Daten des Zeichensatzes experimentieren...
Etwas mühsamer, aber es geht!

mega-hz hat geschrieben:denn die player werden vom GTIA und nicht von der ANTIC erzeugt.
Es ist nur etwas mühsam Texte darzustellen da man ja PMBASE $D407 erstmal als "Muster" definieren muss, dort kann man dann mit den
Daten des Zeichensatzes experimentieren...

Jein. Üblicherweise schaltet man PM DMA im Antic ein (via $D400), dann kannst Du PMBASE setzen etc. Die Daten holt sich der Antic aus dem Speicher, Darstellung (wie in den anderen Grafikmodi) übernimmt der GTIA.

Man kann natürlich sowohl Screen als auch PM DMA komplett abschalten, dann kann man per GRAFPx bzw. GRAFM direkt die PM Daten in den GTIA schreiben - um damit was vernünftiges darzustellen, müsste man aber jede Bildschirmzeile die Daten ändern.

Komfortabler ist da schon der DMA durch den ANTIC.

so long,

Hias

Was ist eigentlich mit den Displaylist Interrupts, werden die bei DMA OFF (POKE 559,0) auch abgeschaltet oder werkeln sie weiter?

Wenn keine DisplayList per DMA vom ANTIC gelesen wird ("DMA OFF"), werden auch keine DLIs ausgeführt, da diese ja durch Bit 7 der ANTIC-Befehle ausgelöst werden.
Beachte aber, dass POKE 559,0 den ANTIC-DMA erst beim nächsten VBI abschaltet (max. 20ms später) - erst dann werden die Schattenregister in die Hardwareregister übertragen.

Zu dem Thema noch gefunden in ANALOG 2 (1981)

"Unleash the power of Ataris CPU"
http://atariwiki.strotmann.de/xwiki/bin ... Ataris+CPU