Hello, Guest the thread was called2.4k times and contains 50 replays

last post from JeeK at the

Variablenwert aus Basic durch Poke verändern

  • Hi,


    ganz zu Beginn eines Basic Programms lade ich Variablen aus einer Datei.

    Sie sind daher wohl auch immer an der selben Stelle.


    Wenn ich mit einem Poke z.B. eine 153 anstelle der vorher dort befindlichen 5 setze, dann ändere ich, wie gewollt, die Zeichenfarbe innerhalb des Strings von weiß nach hellgrün.


    Wenn ich das aber innerhalb des Basic Programms mache, poked er die 153 an eine andere Stelle - obwohl sich laut Monitor die Speicheradressen nicht verändert haben.


    Ist das, was ich vorhabe totaler Schwachsinn oder mache ich etwas falsch?:/

  • Hattest Du den Poke mit gleicher Länge schon im ersten Programm? Falls Du den Poke nachträglich hinzugefügt oder die Längen seiner Nummern verändert hast, dann verschieben sich ja Programm-Ende und die Variablen.

    Ne, da verschiebt sich gar nix. Der Variablen werden bei Programmänderung gelöscht.

  • Habe versucht eine Testdiskette zu erstellen. Da klappt es aber ohne Problemlos.

    EDIT: Probiert in Vice mit Vice-Monitor ALT+M

    Schön das es klappt. ;)


    Nix für ungut. Wenn es eine vollständige Beschreibung gibt, was geht und was nicht, dann bin ich wieder dabei.

    Weil, wenn der Fragesteller zu faul ist, das Problem zu beschreiben, dann bin ich auch zu faul, um zu helfen. ^^

  • Sie sind daher wohl auch immer an der selben Stelle.

    Zumindest bei Strings ist diese Annahme nicht immer richtig.


    Sich das ganze per Monitor mal anzuschauen ist sicher recht instruktiv, haben viele hier sicher auch schon mal gemacht, kann aber auch zu falschen Annahmen führen. Nicht immer weil da irgendwo etwas im (BASIC-)Speicher steht, heißt, daß das auch noch in Gebrauch ist ...

  • Also: basic variable in $hex ausgeben? (oder) mit peek? aus variablenspeicher? wie? - BASIC - Forum64


    ... mit der Korrektur etwas weiter unten im Thread. Bei Zeichenketten kommt noch als Indirektionsstufe dazu, daß die Zeichenkette nicht direkt an der gelieferten Adresse steht, sondern nur ein Zeiger darauf (+Stringlänge). Konstante Zeichenketten 'behält' BASIC V2 im BASIC-Quelltext (!!!), sobald eine Zeichenkette 'angefaßt' wird, landet sie hinten im Speicher im String-Heap.

  • Nee, klappt ja nur in der vereinfachten Testversion.


    Und Hoogo : Wenn ich es als Direktbefehl Poke geht es ja. Nur nicht im Programm.


    Mike : Es geht um ein String-Array. Diese werden dann als STRING nur noch ausgegeben, nicht mehr verändert. Den link muss ich mal durcharbeiten, danke erstmal.

  • Beschreib doch bitte einfach mal das Ziel, das Du eigentlich erreichen willst. :D

    So auf Anhieb fällt mir nämlich rein gar kein Grund ein, warum man per POKE in den Basic-Variablen würde herumpfuschen wollen...

  • Ich weiß einfach nicht, wo ich den Quatsch hinladen soll, um ihn später von Basic aus zu ändern und schnell auszulesen.


    Jetzt lad' ich den Inhalt per load nach $cc00 und lese von da ein (bzw. poke da andere Farben). Geht aber eben von Basic aus sehr langsam mit dem lesen.


    Es geht im Prinzip darum ein Menü zu laden.

    Vermutlich wär es sinnvoller den Bildschirminhalt und die Farbe von woanders herzukopieren bzw. einen zweiten Bildschirmspeicher zu nutzen (würde der nicht auch ggf. von Variablen überschrieben?).

  • Es geht im Prinzip darum ein Menü zu laden.

    Warum wird das geladen und nicht direkt im Programm erzeugt?

    Soll das Programm so eine Art Screen-Editor werden und deshalb Bildschirmmasken laden und speichern können?


    Ich wiederhol mich mal:

    Beschreib doch bitte einfach mal das Ziel, das Du eigentlich erreichen willst.

  • Ich weiß einfach nicht, wo ich den Quatsch hinladen soll, um ihn später von Basic aus zu ändern und schnell auszulesen.

    Irgendwo zwischen $C000 und $D000. Aber 4kB laden für ein Menü? Schneller, einfacher, flexibler und platzsparender wäre es, das zu generieren:


    Basisadresse des Bildschirmspeichers anpassen, Bildschirmspeicher löschen mit CHR$(147), etwas reinschreiben, Bildschirmspeicher-Adr. zurücksetzen. Auf dieselbe Weise kann man darin nachträglich was ändern, oder auch ohne Adr.-Änderung darin herumPOKEn. Allerdings könnte man das auch direkt in dem angezeigten Bildschirm tun; darum verstehe ich das Vorhaben auch nicht so ganz.


    Im Variablenspeicher POKEn halte ich grundsätzlich für keine gute Idee. Es ist weder schneller noch platzsparender als die Aufgabe mit BASIC-Bordmitteln zu lösen. Man bräuchte ja nur PRINT CHR$(C1)"MENUEPUNKT1" schreiben und statt POKEn dem C1 den gewünschten Farbwert zuordnen, z.B 5 für Weiß oder 30 für Grün.

  • Soll das Programm so eine Art Screen-Editor werden und deshalb Bildschirmmasken laden und speichern können?

    Irgendwo zwischen $C000 und $D000. Aber 4kB laden für ein Menü?

    Es geht um eine ganze Bildschirmseite, die weitestgehend gleich bleibt.

    Das mit Print auszugeben war ok, aber mühsam in der Umgestaltung. Daher habe ich einen ganzen Bildschirm erstellt und wollte in 4 oder 5 Variablen (es sind nur knapp 1300 Byte) vorliegen haben um ihn jederzeit auszugeben (der andere Bildschirminhalt kann dann weg). Da dort dann auch die Farben als ASCII Zeichen vorliegen, kann ein "Button" die Farbe wechseln, wenn man nur dieses eine Zeichen wechselt.


    Die wenigen Zusatzausgaben kann ich dann an den entsprechenden Bereich printen.


    Erkenntnis:

    • Die Variablen sind zu unzuverlässig bzw. wäre es den Aufwand am Ende nicht Wert.
    • Ein Speicherbereich zu kopieren dauern in Basic...
    • Einen zweiten Bildschirmspeicherbereich zu verwenden löst den Bildschirminhalt, aber nicht die Farbe - und den müsste ich vor Überschreiben durch übermässige Variablenverwendung sichern?!

    Man bräuchte ja nur PRINT CHR$(C1)"MENUEPUNKT1"

    Wenn das dann aber eine zusammengeflicktes Print-Werk wird (was ich ja vorher hatte), dann hatte ich hier und da Hilfsvariablen, die wiederum den Variablenspeicher zugemüllt haben. Vermutlich aber zu vernachlässigen und nicht schlimmer als andere "Lösungen".


    Im Endeffekt sollte es lediglich im Basic übersichtlicher bleiben bzw. war es "eine Idee" ggf. für die schnelle Darstellung mehrerer Seiten und dafür wäre wohl das Befüllen mehrerer Bildschirmspeicherbereiche am sinnvollsten - wenn mir dann auch die Farbänderung beim Umschalten nicht so leicht gelingt.


    Aber kann ich einen zweiten Bildschirmspeicherbereich "schützen" bzw. als reserviert markieren, so dass er nicht durch Variablen überschrieben würde?

  • Aber kann ich einen zweiten Bildschirmspeicherbereich "schützen" bzw. als reserviert markieren, so dass er nicht durch Variablen überschrieben würde?

    Ja, das geht, am Ende des BASIC-Speichers, indem man die entspr. Zeiger in der Zeropage umstellt. Die Strings gehen dann eben nur bis $9C00 (bzw. ab, weil rückwärts). Allerdings würde ich dafür zuerst die 4 mögl. Bereiche ab $C000 nutzen.

    ggf. für die schnelle Darstellung mehrerer Seiten und dafür wäre wohl das Befüllen mehrerer Bildschirmspeicherbereiche am sinnvollsten

    Könnte man machen und ist dann natürlich instant angezeigt. Allerdings gibt es nur einen Farbspeicher, sodass man die zugehörigen Farbinformationen auch retten müsste, und das ist wiederum eher nix für BASIC (ohne die erforderlichen Asm-Routinen). Mit anderen Worten, man muss die unterschiedlichen Bildschirmseiten sowieso neu PRINTen, wenn sie unterschiedlich farbige Zeichen enthalten.


    Etwas übersichtlicher sind farbige PRINTs mit C$"TEXT", wobei man dem C$ das Steuerzeichen für die Farbe zuordnet. So schlimm finde ich das nicht. In anderen Dialekten schreibt man COLOR(14):PRINT"TEXT" oder ähnlich, was auch nicht kürzer ist. Schlimmer ist in BASIC V2 das Positionieren des Textes (jedes Mal mit 2 POKEs und 1 SYS), wenn man kein Maschinenroutinchen dafür verwendet. In den erweiterten PRINT-Aufruf über solch eine Positionierungsroutine könnte man auch leicht noch die Farbe mit einbauen, von wegen SYS pr, x,y,c, "text".

  • Ja, das geht, am Ende des BASIC-Speichers, indem man die entspr. Zeiger in der Zeropage umstellt. Die Strings gehen dann eben nur bis $9C00 (bzw. ab, weil rückwärts). Allerdings würde ich dafür zuerst die 4 mögl. Bereiche ab $C000 nutzen.

    Naja, ich meinte ja schon einen umschaltbaren Bildschirmbereich und da wüsste ich nicht, wie ich über $3c00 hinweg käme.

    Allerdings gibt es nur einen Farbspeicher, sodass man die zugehörigen Farbinformationen auch retten müsste, und das ist wiederum eher nix für BASIC (ohne die erforderlichen Asm-Routinen).

    Ja, das war mir klar, deswegen war ja der Gedanke meinen Print in Variablen zu packen.

    Vielleicht sollte ich einfach die entsprechenden "Buttons" per poke färben, das sind ein paar Zeichen jedes Mal. Also, wie gehabt lade ich mir den Spaß in Variablen, die printe ich und korrigiere einzelne Farben.


    Schlimmer ist in BASIC V2 das Positionieren des Textes (jedes Mal mit 2 POKEs und 1 SYS)

    Nutze ich in Subroutine für die paar veränderlichen Details.

    In den erweiterten PRINT-Aufruf über solch eine Positionierungsroutine könnte man auch leicht noch die Farbe mit einbauen, von wegen SYS pr, x,y,c, "text".

    Klingt eigentlich nach überschaubarem ASM, so dass selbst ich das noch entwickeln/verstehen könnte.


    Gibt's eigentlich eine schnelle Variante den Farbspeicherbereich auf einen Wert zu setzen oder wäre das auch wieder eine kurze ASM Routine (wobei ich die wohl tatsächlich noch hinbekomme...)

  • Gibt's eigentlich eine schnelle Variante den Farbspeicherbereich auf einen Wert zu setzen

    Bildschirmadresse wieder irgendwo hinsetzen, z.B. mit POKE 648,160 nach $A000, dann PRINT"{steuerzeichen für farbe}{clr}", und wieder POKE 648,4.

    Für die Anzeige ab $4000 muss man den anderen Steuerkram in CIA2 und VIC auch noch setzen. Dafür böte sich dann eine Unterroutine an.