Hello, Guest the thread was called10k times and contains 193 replays

last post from JeeK at the

BASIC 4.5 für den C64 (BASIC 3.5 + EIGENE BEFEHLE)

  • Puh, danke fürs Verständnis.
    Nebenbei bemerkt ist mir ein Bug beim BEGINBLOCK / ENDBLOCK Konstrukt aufgefallen. Sobald die Zeilennummern > 999 sind gibt es im "FALSE" Zustand immer eine Fehlermeldung "MISSING BEGINBLOCK".

    Daran arbeite ich gerade. Es kommt also bald einen neue Version.

  • Puh, danke fürs Verständnis.

    Da hast du nochmal Glück gehabt. :D


    Im Ernst:


    Bitte sehe die Meldungen hier zu deiner BASIC-Erweiterung immer nur als völlig unverbindliches Feedback an. Daraus sollte für dich keinerlei Druck entstehen. Du machst das freiwllig in deiner Freizeit und solltest genau das machen, was DU möchtest und für richtig hältst. Und das, was du bisher abgeliefert hast, ist wirklich gut! :thumbup:


    Alles andere sind Meinungen anderer, die du zur Kenntnis nehmen kannst und eventuell in deine Überlegungen einfließen lassen kannst. Mehr aber auch nicht. Entscheidend sollte für dich sein, was DU willst.

  • Bitte sehe die Meldungen hier zu deiner BASIC-Erweiterung immer nur als völlig unverbindliches Feedback an. Daraus sollte für dich keinerlei Druck entstehen. Du machst das freiwllig in deiner Freizeit und solltest genau das machen, was DU möchtest und für richtig hältst. Und das, was du bisher abgeliefert hast, ist wirklich gut! :thumbup:


    Alles andere sind Meinungen anderer, die du zur Kenntnis nehmen kannst und eventuell in deine Überlegungen einfließen lassen kannst. Mehr aber auch nicht. Entscheidend sollte für dich sein, was DU willst.

    So sehe ich das auch, stimme Snoopy voll zu :thumbup:

  • ACHTUNG! BASIC 4.5 Update (Version 20.05.01)

    Anbei die neuste Version mit einem Fix beim BEGINBLOCK/ ENDBLOCK Konstrukt. Weiter die angepasste Dokumentation zum BASIC 4.5

  • Ideen braucht das Land....In meinem kleinen BASIC Projekt, welches ich als Testprogramm für das BASIC 4.5 nutze stosse ich des öfteren auf den Wunsch WHITESPACES zu eliminieren. Also ähnlich dem TRIM Befehl aus anderen BASIC Dialekten.

    Beispiel:

    A$=" TEXT "

    LTRIM A$ --> "TEXT "

    RTRIM A$ --> "TEXT"


    Hier sind die Stringvariable Jongleure gefragt :)


    Irgendwie habe ich den Anfang noch nicht gefunden und freue mich über jede Idee.
    Gab es sowas in TSB? Wenn ja könnte mir der TSB Autor einen Tipp geben.


    Ich bin auf das Feedback gespannt.:pumpkin:

  • Ideen braucht das Land....In meinem kleinen BASIC Projekt, welches ich als Testprogramm für das BASIC 4.5 nutze stosse ich des öfteren auf den Wunsch WHITESPACES zu eliminieren. Also ähnlich dem TRIM Befehl aus anderen BASIC Dialekten.

    Beispiel:

    A$=" TEXT "

    LTRIM A$ --> "TEXT "

    RTRIM A$ --> "TEXT"

    Das ist eine Variante. D.h. aber, als "Parameter" ist ein String-Variablenname zwingend. Macht aber auch nichts. Wir haben ja ähnliches schon in FILES oder MEMORY.

    Aber dann als Funktionen.


    A$ = LTRIM$(" TEXT ")

    Das wäre universeller, aber birgt auch mehr Aufwand, da man hier in den Ausdrucksparser rein muss. Ich glaub dg5kr hat mit einem "normalen" Befehl hier einen leichteren Zugang.

    Das Schöne ist, dass man hier "inplace" operieren kann. Der String wird niemals größer. Für LTRIMS verschiebt die Startadresse im String-Descriptor an die erste Position ohne Leerzeichen und reduziert die Stringlänge im Descriptor um die Anzahl der Leerzeichen am Anfang. Für RTRIM reicht es, nur die Länge zu reduzieren um die Anzahl der Leerzeichen rechts.

  • Das wäre universeller, aber birgt auch mehr Aufwand, da man hier in den Ausdrucksparser rein muss. Ich glaub dg5kr hat mit einem "normalen" Befehl hier einen leichteren Zugang.

    Genauso ist es. Eigene Funktionen werden vom internen Parser als Zuweisung angesehen. Also wenn kein Befehle als gültig gefunden wurde, landen solche Ausdrücke VA$=FUNCTION$("WASAUCHIMMER") im LET und der versucht dann VA$ mit dem Ausdruck FUNCTION$("WASAUCHIMMER") zu füllen, was natürlich scheitert.

    Getreu dem Motto "Keep it simpel and stupid" habe ich mich (vorerst) für die Variante

    A$=" TEXT "

    LTRIM A$ --> "TEXT "

    RTRIM A$ --> "TEXT"

    entschieden.


    Wobei ich die Parserstelle im Bytedjungel inzwischen gefunden habe wo die LET Ausdrucksauswertung angesprungen wird. Hier könnte ich versuchen anzusetzen. Aber trotz Homeoffice bin ich (oder gerade deswegen) sehr eingespannt. Mein Job lässt mir kaum Zeit in gewohnter Weise an diesem Projekt zu arbeiten. Daher bitte ich um Geduld.


    Aber bis dahin gibt ein BASIC 4.5 mit zwei neuen Befehlen. Weiter findet ihr in derAnlage auch die ergänzte Dokumentation im WORD-Format.


    Ihr lieben Tester, ladet und testet die neue Version. Ich freue mich auf euer Feedback.

  • Neue Version mit BUGFIX:

    Code
    1. ;------------------------------------------------------------------------------
    2. ; 23.06.2020:
    3. ; FIX: FIND erkennt nun das BASIC Ende anhand der Pointer und nicht mehr anhand einer 00 (null null) Folge.
    4. ;------------------------------------------------------------------------------

    Unter bestimmten Umstanden erkannte FIND zu früh das BASIC Ende des Listings. Die Prüfung fand bisher auf das WORD $0000 statt.

    Das habe ich geändert und prüfe das Ende auf $2D, $2E.


    Viel Spaß beim BASIC Coden.

  • Anbei eine neue Ausgabe von BASIC 4.5.

    ;------------------------------------------------------------------------------

    ; 12.09.2020:

    ; NEW: C64 kennt nur OR AND NOT - neuer Befehl XOR (exclusiv Oder)

    ; X Y = S

    ; 0 0 = 0

    ; 1 0 = 1

    ; 0 1 = 1

    ; 1 1 = 0

    ; S = (NOT X AND X) OR (X AND NOT Y) -> Nachbildung mit UND / OR

    ; 10 x=0:y=0:s=(not x and y) or (x and not y): print s -> Wäre aber in

    ; BASIC vie langsamer als der EOR beim 6502


    Ein Exclusiv Oder kann in BASIC zwar mit der Folge

    S = (not X and Y) or (X and not Y) nach geahmt werden, allerdings ist die Ausführungszeit gegenüber einem native XOR (eor in Assembler) deutlich höher.

    Deshalb habe ich einen weiteren Befehl implementiert.

    XOR X,Y,S

    Wobei X und Y die Eingabswerte bilden und die Variable S die Ausgabe der Verknüpfung. Selbst verständlich kann für X,Y,S auch jede andere integer oder FP Variable genommen werden.

    Damit lassen sich zum Beispiel Public Key Verschlüsselungen reaisieren.


    Fragen? Anregungen?

  • Ich finde es ein bisschen komisch, dass dieses XOR völlig anders implementiert ist als AND und OR. Warum ist das kein Operator? Oder wenigstens eine Funktion? In BASIC V2 gibt es doch sonst keinen Befehl, der eine Variable als Eingabeparameter nimmt, in die er das Ergebnis zurückschreibt!?


    So wie es jetzt ist, kann ich sowas wie


    Code
    1. S=A XOR (B OR C)

    nicht machen. Außerdem ist das XOR, anders als AND und OR in BASIC, auf den Bereich von 0-255 begrenzt. Natürlich ist das effizienter zu implementieren, aber es passt halt so gar nicht zum Rest.

  • Außerdem ist das XOR, anders als AND und OR in BASIC, auf den Bereich von 0-255 begrenzt. Natürlich ist das effizienter zu implementieren, aber es passt halt so gar nicht zum Rest.

    Dem muss ich leider zustimmen. Das mit der Funktionsimplementierung ist besonders hier eine leidige Geschichte. Konnte man da beim MEM (als Alternative zu FRE()) noch darüber hinwegsehen, so ist XOR auf dieser Basis leider komplett aus jeglicher Norm und Konvention.

    Wir wir schon hier bzw. in Nachbar-Threads erörtert haben, muss man, um eine neue Funktion zu ergänzen auch den Tokenizer umschreiben (als erweiterte Kopie - Ich glaub, das bleibt einem hier nicht erspart - anlegen).

    Ich hab schon in Posting #32 darauf hingewiesen (auf Assembler: VAR$=MEINE_FUNC$(INTEGER) in BASIC Erweiterung. Aber wie?). Ob es eine elegantere Variante, die nicht so viel Code aus dem ROM wiederholen muss. Das wär' der dort im Posting erwähnte 2-Pass-Ansatz, den ich aber noch nicht probiert habe (ob der wirklich so funktionieren könnte, wie gedacht).