PRINT ohne Schreiben in den Farbspeicher

Zitat von will

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?

Zitat von -trb-

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.

Zitat von Mac Bacon

Genauso. Beide Wege benutzen (natürlich!) ein- und dieselbe Routine

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

Zitat von -trb-

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.

Zitat von will

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.

Hallo, Will,

Die Änderung des Maschinencodes wäre ein Fall für ROM-RAM.

probier mal

poke1,51:print"[rot]hallo":poke1,55

Schönen Gruß.

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ß.

Theoretisch bliebe dann noch die Frage, wieviel an Zeitersparnis das Ausschalten des Interupts bei dem Trick bringt?

Das wäre dann wohl eine Frage an die Assembler-Profis.

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.