Hallo zusammen,
ist der Wert mit dem der Bildschirm beim Drücken der [clr/home] gefüllt wird fest? Also 32 / $20
Oder kann der irgendwo in der Zeropage beliebig eingetragen werden?
LG
Christian
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von Wurzelzwerg am
Hallo zusammen,
ist der Wert mit dem der Bildschirm beim Drücken der [clr/home] gefüllt wird fest? Also 32 / $20
Oder kann der irgendwo in der Zeropage beliebig eingetragen werden?
LG
Christian
Das geht leider nicht. Wäre eine wirklich schöne Funktion gewesen. Ich hatte auch schon mal im ROM geguckt, ob man da mit einem anderen Wert irgendwo reingrätschen kann: Geht aber auch nicht (warum, weiß ich grad nicht mehr).
EDIT:
Daran lag's:
i. V. m.
Das LDA #$20 ist mitten in den beiden Schleifen 'gefangen'.
EDIT2: Da hatte man schön eine der freien Adressen von $02-$04 z. B. für nehmen können.
Man kann aber $E560 bzw. $EA01 mit anderen X/Y-Werten anspringen und ein paar witzige Lösch-Effekte in BASIC (oder ASM) damit machen. Hatte ich mal mit rumgespielt.
Oder das komplette ROM ins RAM kopieren, $01 auf RAM umbiegen und dann in CLRSCR rum wuseln, bis es geht... ROMRAM-Trick... (C) BIF
Schade,
aber vielen Dank für Eure Mühe!
Oder das komplette ROM ins RAM kopieren, $01 auf RAM umbiegen und dann in CLRSCR rum wuseln, bis es geht... ROMRAM-Trick... (C) BIF
Aber auch nur, wenn man ordentlich RUM intus hat....
Oder das Rom modifizieren, in der Resetroute den Wert $20 in die ZP und dann mit LDA $ZP den Wert laden. Dann mußt du nur den Wert in der ZP ändern.
Alternative eine Maschinenroute zum Bildschirm füllen schreiben.
Die ROM/RAM-Kopiererei kostet wohl knapp <60 Bytes (wenn ich grad nicht zu blöd war...). Eine eigene Füll-Routine ist da wohl wirklich kürzer.
Die ROM/RAM-Kopiererei kostet wohl knapp <60 Bytes (wenn ich grad nicht zu blöd war...). Eine eigene Füll-Routine ist da wohl wirklich kürzer.
Yo,
vor allem hat der Bilschirmspeicher 1000 Zeichen und das Rom 8192
Bis ich das kopiert habe habe ich den Bildschirm 8 mal überschrieben
Aber auch nur, wenn man ordentlich RUM intus hat....
OOODER wenn man genug ROM intus hat
Alternative eine Maschinenroute zum Bildschirm füllen schreiben
Ja, nein,
ich hätte wohl vorher sagen sollen worum es geht.
Ich doktor gerade ein wenig an einem 10 Zeiler Basic Spiel.
Als ich @Telespielator den ersten fertigen Entwurf zeigte und stolz wie Oskar war, dass ich nur 8 Zeilen brauchte
sagte er, dass er schon auch etwas mit Sprites erwartet hätte.
Ich hatte gehofft über die [clr/home] Funktion den Speicher sehr schnell löschen zu können um
anschliessend Spritedaten rein zu kopieren.
So muss der Speicher nun also per Basic gelöscht werden
Man kann auch mit DIM herumfrickeln, um hinter dem Programm (und den Variablen) Bereiche zu nullen.
Die Idee ist genial. Die Frage wäre wie zuverlässig das ist. Ich müsste ja mit DIM zuerst einen Speicher für Variablen reservieren und anschliessend in der ZeroPage den Speicher für Basicvariablen sperren, damit mir die Variablen des Programms nicht die Sprites überschreiben.
Ob der Interpreter damit klar kommt?
Nein. Was Du tun mußt ist, *alle* einfachen Variablen vorab zu "deklarieren", damit das dahinter gelegene (Dummy-)Array nicht durch die Neuanlage von noch weiteren Variablen *verschoben* wird nachdem Du bereits die Spritedaten reingeschrieben hast.
Das machst Du am einfachsten mit: DIM A,B,...,Z,A(999) - wobei am Anfang der Liste alle einfachen Variablen (auch Strings!) stehen - idealerweise die am häufigsten gebrauchten zuerst, so kann der Interpreter schneller auf diese zugreifen. Und mit A(...) wird halt der Bereich dahinter (aber noch vor dem String-Heap) genullt.
Dem Interpreter ist es ansonsten weitgehend egal, daß da in dem Dummy-Array anschließend keine Float- oder Integer-Werte sondern Binärdaten aus einer anderen Quelle drinstehen. Würde man die betroffenen Index-Werte auslesen, könnte sich der Interpreter immer noch einen Wert daraus drehen, würde also nicht etwa abstürzen.
Ich hatte gehofft über die [clr/home] Funktion den Speicher sehr schnell löschen zu können um
anschliessend Spritedaten rein zu kopieren.
So muss der Speicher nun also per Basic gelöscht werden
Ich versteht nicht ganz. Was willst du da denn löschen?
Ich versteht nicht ganz. Was willst du da denn löschen?
Ich wollte den Speicher hinter einem Basicprogramm mit Nullen füllen
um ihn für Sprites zu nutzen die ich von Basic aus pixelweise beschreibe
Da das Beschreiben schon Ewigkeiten dauert wollte ich wenigstens das Löschen möglichst schnell machen.
Da dachte ich an
$288 648 4 Bildschirmspeicher-Anfang (Seite/Page), nur High-Byte, Normaladr. = $0400
in Verbindung mit [clr/home]
Wie aber (leider) oben zu sehen füllt [clr/home] ausnahmslos mit 32 / $20
Das kann man auch so machen:
Im Beispiel wird der Speicher von $3000-$33ff (16 Sprites) in ca. 0,5 Sek. gelöscht und damit ca. 8x schneller, als mit einer Poke-Schleife.
Muss man nur etwas umsichtig mit umgehen mit der Methode, dass man sich nix zerschießt.
Als ich @Telespielator den ersten fertigen Entwurf zeigte und stolz wie Oskar war, dass ich nur 8 Zeilen brauchte
sagte er, dass er schon auch etwas mit Sprites erwartet hätte.
DAS soll ich gesagt haben? Nee, da hast Du mich falsch verstanden... Ich habe ja selber in meinem Leben noch nie ein Sprite programmiert...
Dafür bastele ich gerade ein lustiges Spiel auf meinem 8096-SK und hoffe, ich komme mit zehn Zeilen hin...
Nee, da hast Du mich falsch verstanden...
Na ja, wer weiß wozu es gut ist
Auf jeden Fall hab ich ganz neue Ideen und ganz neue Ansätze.
Aber zehn Zeilen ist und bleibt eine harte Nuss.
Das ganz Gemeine ist ja, dass die Option 120 Zeichen pro Zeile nur sehr hakelig auf dem Brotkasten umzusetzen ist
Also müssen es 'echte' zehn Zeilen sein