Hello, Guest the thread was called1.2k times and contains 14 replays

last post from 7Saturn at the

BASIC-Tokens unter verschiedenen BASIC-Versionen

  • Ich weiß nicht sicher obs hier rein gehört, ich denke aber schon. Falls nicht, bitte sinnvoll verschieben:


    Ich programmier ja seit einiger Zeit immer mal wieder an meinen Disk-Tools rum. Letzter Schritt war, dass ich das Programm für C16, 64 und 128 so gebaut hab, dass man z. B. bei allen dreien den Reset benutzen kann und die Hintergrundfarben gleich hat. Letzteres funktioniert ja beim C64 unter BASIC 2.0 nur mit den Pokes, unter 3.5 und 7 gibts dafür den COLOR-Befehl. Letzterer existiert ja nicht im B2, die Tokens sind dementsprechend auch nicht in der Form bekannt. Ich hab jetzt festgestellt, dass er am C64 dafür den Befehl LIST setzt. Die Frage die mich jetzt beschäftigt: Fummelt BASIC 2.0 evtl. beim Speichern oder sonst wie daran rum, so dass es ggf. sein kann, dass das Programm in den entsprechenden Zeilen nicht mehr auf dem C16 bzw. C128 läuft weils plötzlich doch andere Befehle sind? Oder fasst der die Tokens nicht an, solange man nicht am C64 daran rum editiert?

    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890

  • Hallo 7Saturn,


    ich habe Deine Frage gerade mit zwei Vice Emulatoren (für C64 und Plus/4) nachvollzogen:


    1. Ich habe die Zeile: 10 COLOR 4,1,0 auf einem VICE Plus/4 eingegeben und auf ein Diskimage abgespeichert.
    2. Das Diskimage auf einem VICE C64 attached und per LOAD wieder eingeladen.
    3. Gelistet: 10 LIST 4,1,0
    4. Anschließend an den LIST 4,1,0 Befehl ": PRINT "HALLO" angefügt und mit Return bestätigt!
    5. Auf dem VICE C64 mit SAVE unter einem anderen Namen wieder gespeichert
    6. Anschließend auf dem VICE Plus/4 wieder attached und geladen.
    7. LIST auf dem VICE Plus/4: COLOR 4,1,0: PRINT "HALLO"


    Funktioniert und gibt keine zerstörten Listings, was ich auch erwartet habe, das der BASIC Interpreter sich bis hierher "passiv" verhält!
    Es wird erst ein Problem geben wenn Du auf dem C64 am LIST Befehl (=COLOR) selbst herumeditierst.


    Have fun...


    TheChief

  • Jetzt muss ich aber doch noch mal nachtreten. Hab eben mit Yape & Vice 64 rumprobiert. Wenn ich unter Yape die Zeile

    Code
    1. 10 color 1,1,1

    speichere und das unter Vice 64 lade, erhalte ich

    Code
    1. 10 list 1,1,1

    . Mach ichs aber anders rum, also letzteres unter Vice eingeben und unter Yape laden, erhalte ich dasselbe wieder, also gerade nicht den COLOR-Befehl. Was mich jetzt ganz brennend interessieren würde ist, wie diese Tokens eigentlich genau gehandhabt werden, also u. A. wie die im RAM abgelegt und behandelt werden. Wenn ich jetzt z. B. nen Renumberer benutze, oder diesen BASIC-Compaktor, bekommen die irgendwas anderes als die Tokens zu sehen, oder nicht?

    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890

  • Ich weiß es eben nicht, ich bin da nur drüber gestolpert weils mir im Listing aufgefallen ist. Wer mir nen guten Pointer auf ne Info hat, immer her damit. Mir gehts eben darum, dass das Programm an dem ich werkeln, auf unterschiedlichen Plattformen gestartet werden kann und dann selbst raus findet auf welchem es läuft. D. h. z. B. dass die Zeilen mit COLOR-Befehl nie angesprungen werden, wenns kein C16 oder C128 ist. Ich hab nur die Sorge, dass im Laufe der verschiedenen Editierungen dann doch mal diese Befehle von irgendwas verhunagelt werden. Das würde ich gerne vorbeugen.

    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890

  • 1. Nicht alle Token aus einem "höheren" BASIC sind 2-Byte Token.


    2. COLOR ist ein 1-Byte-Token. Wert: $E7


    3. LIST ist ein 1-Byte-Token (was auch sonst): $9B


    4. Grundsätzlich gilt: Programmzeilen aus einem höheren BASIC nie in einer anderen Version editieren. Es gibt auch Unterschiede zwischen BASIC 4 und BASIC 3.5 / 7 (gleicher Token, anderer Befehl). In der Regel führt ein EDIT zu Murks.


    5. Programmzeilen aus einem höheren BASIC immer mit passendem BASIC 2-Verzweiger ausstatten (in der Regel eine Variable einmal dafür bereitstellen und dann z.B. mit ON GOTO die passnede BASIC-Variante anspringen).


    6. Das COLOR/LIST-Phänomen ist lustig (und ein Zufall). Hintergrund:
    In der LIST-Routine wird bei ($a71a) das Token als Zähler auf eine Tabelle der Befehlsnamen verwendet. Die Befehle sind fortlaufend ab $a09e mit abschließendem HIGH-Bit (gesetztes Bit 7) gespeichert, also: enDfoRnexTdatA .... lisT ....
    Vom Token wird erstmal $7f abgezogen. Somit wird aus END mit Token $80 der Zählerwert 1.
    Die Auswerteroutine zählt nun jeden Buchstaben mit gesetztem HighBit also D.R.T.A. ... Wird der durch das Token definierte Zählerwert erreicht, wurde der Text gefunden und wird dann ausgegeben. Genaugenommen wird einfach jedesmal der Zählerwert um eins dekrementiert und ist irgendwann bei Null angekommen, was die Ausgabe anstößt. Bei END ist das gleich der Fall, bei LIST (Token: $9b) muss man sich bis zum 28. ($1c) Eintrag durchgraben.
    Die oben angesprochene Tabelle der Befehlsnamen darf maximal 255 Zeichen lang sein, da das Durchsuchen der Tabelle mit dem Y-Register (LDA absolut,y) realisiert wurde. Ist der aus dem Token ermittelte Zählerwert höher als die Zahl der im verfügbaren 255-Byte-Abschnitt vorhandenen Befehls-Texte (genaugenommen als die Zahl der Bytes mit gesetztem Bit 7), so ergibt sich ein Überlauf im Y-Register. D.h. die Tabelle wird mehrfach durchlaufen. Beim oben beobachteten COLOR-Phänomen kommt es dazu, dass der Tokenzähler beim zweiten Durchlauf zufällig beim LIST ausgezählt hat. Also wird LIST angezeigt. Im Speicher steht aber noch immer der Token für COLOR. Editieren sollte man das im C64 aber nicht, denn dann wird die Zeile neu tokenisiert und es steht dann LIST nicht nur im Listing, sondern auch im RAM.


    Gruß WTE


    PS: Warum muss ausgerechnet ICH hier den C64 erklären?

  • Quote

    PS: Warum muss ausgerechnet ICH hier den C64 erklären?


    weil du einer der wenigen bist die bei diesem basic kram nicht schreiend weglaufen? =P

    Quote

    Deine Erklärung klingt auf jeden Fall sehr fundiert und ist logisch schlüssig


    yep.

  • Ich danke WTE für die Erklärung, das ist SEHR aufschlußreich. Nachdem die ganzen Listing-Manipulatoren (Renumber, Merge, Compactor und Co.) wohl nicht an den Tokens selbst rum pfuschen werden, sollte das dann aber gefahrlos möglich sein die anzuwenden? Also sagen wir mal in GW-BASIC oder Simons-BASIC nen Renumber und außer den Zeilennummern ändert sich nichts? Und ja, ist BASIC-Gedöns, das kann ich halt ein wenig im Vergleich zu Assembler, dass ich praktisch gar nicht kann. Was bleibt einem also übrig? Wenn meine Disk-Tools irgendwann mal fertig sind, werd ich mich auch wieder Assembler zuwenden. Das Buch "Das Machinensprache Buch zum Commodore 64" von Lothar Englisch hab ich schon hier und auch schon mal angefangen, aber irgendwie überzeugt mich das nicht so recht...

    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890

  • Stimmt, daran hab ich so schnell gar nicht gedacht. Stellt sich also die Frage ob die GOTOs und GOSUBs immer dieselben Tokens haben, oder ob man da auch auspassen muss.

    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890

  • Stellt sich also die Frage ob die GOTOs und GOSUBs immer dieselben Tokens haben, oder ob man da auch auspassen muss.


    Wenn GOTO/GOSUB in den verschiedenen Commodore-BASIC-Versionen verschiedenen Tokens verwenden würden, würde die ganze Bastelei mit verschiedenen Programmzeilen, die abhängig von der BASIC-Version angesprungen werden eh nicht funktionieren.

  • Wenn GOTO/GOSUB in den verschiedenen Commodore-BASIC-Versionen verschiedenen Tokens verwenden würden, würde die ganze Bastelei mit verschiedenen Programmzeilen, die abhängig von der BASIC-Version angesprungen werden eh nicht funktionieren.

    Siehst was mein Problem ist... Bis jetzt klappts ja ganz hervorragend. So hätt ichs halt gerne dauerhaft. ;-) Nicht dass irgendwann der Code für die Tonne ist, weil sowas mir ins Knie schießt.

    Ich danke dafür!

    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890