Hello, Guest the thread was called701 times and contains 11 replays

last post from Hoogo at the

PRINT ohne Schreiben in den Farbspeicher

  • Gibt es eine Möglichkeit dem PRINT - Befehl das gleichzeitige Schreiben in den Farbspeicher abzugewöhnen?


    PRINT schreibt ja jeweils gelichzeitig Zeichen in den Bildschirmspeicher (1024-2023) und die eingestellte Farbe in den Farbspeicher (55296-56295). Würde letzteres nicht passieren wäre PRINT schneller und die Zeichen würden in der Farbe erscheinen die zuvor im Farbspeicher steht (das wird zum Beispiel beim Löschen des Bildschirms initialisiert).


    Ich weiß dass ich den Effekt mit POKEs in 1024-2023 erreichen kann, aber das ist deutlich langsamer als das normale PRINT. Ich denke vielmehr an Tricks wie das Verbiegen von Vektoren oder die Verwendung von PRINT#...


    Hat jemand eine Idee dazu?

  • Gibt es eine Möglichkeit dem PRINT - Befehl das gleichzeitige Schreiben in den Farbspeicher abzugewöhnen?

    Nein. Man kann natürlich den $ffd2-Zeiger verbiegen (liegt bei $0326, zeigt auf $f1ca), aber dann müsste man die komplette Ausgabefunktion neu schreiben - wer das kann, braucht kein PRINT mehr.

  • Wie sieht es aus, wenn man den Bildschirm als Device öffnet, um per PRINT# eine Ausgabe zu machen?

    Genauso. Beide Wege benutzen (natürlich!) ein- und dieselbe Routine: jedes Byte wird einzeln per Kernalfunktion $ffd2 ausgegeben. PRINT# ruft nur vorher $ffc9 und ganz zum Schluss $ffcc auf, um den Ausgabekanal vorher umzudefinieren und am Ende wieder auf den Standardwert zu setzen.

  • Ich sehe jetzt nur nicht, wie das Farbram bei PRINT# ins Spiel kommt.

    PRINT# weiß nichts vom FarbRAM - aber das "normale" PRINT auch nicht: Beide Anweisungen wandeln ihre Argumente in Textform um und schicken diesen Text via $ffd2 an das aktuelle Ausgabegerät. Wenn das der Bildschirm ist, kommen die aktuelle Cursorposition und das Farb-RAM ins Spiel - und wenn nicht, dann nicht.

  • PRINT schreibt ja jeweils gelichzeitig Zeichen in den Bildschirmspeicher (1024-2023) und die eingestellte Farbe in den Farbspeicher (55296-56295). Würde letzteres nicht passieren wäre PRINT schneller

    Nein, PRINT wäre nicht nennenswert schneller, dazu gibt es noch viel zu viel anderen Overhead. Man kann natürlich das Kernal ins RAM kopieren und den fraglichen STA-Befehl lahmlegen... den tieferen Sinn sehe ich aber nicht.

  • BIF meint glaub ich, an Stelle von I/O das Char-ROM einzublenden.
    Damit ist das Farbram weg, und das Schreiben nach dort landet im RAM.
    Vorher aber noch IRQs abschalten und hinterher wieder einschalten.


    Poke 56333,1: Poke 1,51
    ...Print-Befehle...
    Poke 1,55: Poke 56333,129

  • Jo, Hogo hat es kappiert.


    Wenn das Char-Rom eingeblendet ist, landen alle Pokes oder Prints im RAM dadrunter.
    Also in diesem Fall nicht im Farbram. Daher bleibt die Farbe unsichtbar.


    Wenn man ROM/RAM vorher aktiviert hat kann man übrigens den Speicherbreich unter dem Farbram sogar wieder lesen mit Konfig 1,48.



    QUELLCODE:

    • 150 :rem--rom/ram,bild:52224,satz:53248
    • 151 poke56334,0:poke1,51:fori=88to91:pokei,0:next:poke781,97:poke782,.:sys41971
    • 152 :poke53248+32*8+6,16:rem---zeichen-poke
    • 153 poke1,53:poke56334,1:poke648,204:sys58692:poke53272,52:poke56576,196:return

    Schönen Gruß.

  • Mir ging es nicht um die Zeitersparnis.


    Auch wenn I/O abgeschaltet und an dessen Stelle der Zeichensatz verfügbar ist: Interrupte werden weiterhin ausgelöst, und die IRQ-Routine im Kernal läuft los. Die ist aber nur auf die Standard-Konfiguration eingerichtet und kommt weder mit fremden IRQ-Quellen noch mit einer nicht erreichbaren CIA klar. Passt eines davon nicht, dann gerät sie in eine Endlosschleife.


    Poke 53274,1 schaltet z.B: Raster-IRQs ein, aber die Standard-IRQ-Routine kann den nicht quittieren. Außer cbm+shift gibt es dann nicht mehr viel zu sehen.