Hallo Besucher, der Thread wurde 68k mal aufgerufen und enthält 157 Antworten

letzter Beitrag von syshack am

Bas.Edit der Basic Editor unter Windows !

  • Kleine Anekdote: Genau das von Dir gewünschte Feature des ' Kommentars nur für den Editor hatte ich ursprünglich, bis mich ein Anwender von Exbasic darauf hinwies, dass ich ihm seinen Source verstümmel...


    Machs doch einstellbar.


    Hier übrigens mal mein Preprozessor, geschrieben in FreeBASIC. Entfernt alle unnötigen Leerzeichen und macht möglichst kurze Zeilennummern.
    (Bitte nicht zu schief ansehen, das ganze ist eigentlich nur ein Hack für mich...)

  • Ja, das sieht so ähnlich aus wie meine erste Inkarnation - die Vergleiche auf "THEN", "GOTO" "GOSUB" kommen mir doch sehr bekannt vor ^^


    Aber wofür ich mir echt einen Klapps auf den Hinterkopf geben sollte: ich hab eine Routine zum Entfernen überflüssiger Leerplätze außerhalb von Strings, die benutze ich für die Umwandlung von Label-Code zurück in den Zeilennummern-Mode. Vor lauter Betriebsblindheit :anonym hab ich nicht daran gedacht, die auch einfach mal vor dem Tokenisieren aufzurufen, das hätte mir manchen Klimmzug erspart... Ich hab das Problem mit dem IF fo= ba zwar jetzt gelöst, aber das wäre natürlich gar nicht nötig gewesen. Naja, man lebt und lernt ...

  • Naja, jetzt hab ich einfach ein paar Prüfungen auf Spaces mehr als unbedingt nötig wäre - aber lieber doppelt als keinmal. Da es nicht zeitkritisch ist, lass ich das mal drin, ansonsten würde ich die ganzen scSkipSpaces(buffer, p) wieder rausnehmen... Allein der Syntax-Check sind jetzt schon 1300 Zeilen Code, da bin ich vorsichtig mit unnötigen Änderungen - if it runs, don't touch it!


    Nochmal zu Deinen ' Kommentaren: Das wirft natürlich ein Problem beim Speichern auf. Im PRG-File sollen die dann ja nicht drin sein, damit der Commodore Interpreter nicht meckert, also müssen die beim "Save PRG" rausfliegen. Damit Du die bei der nächsten Editier-Session noch hast, musst Du den Source also auch noch als PETSCII specichern. Und das nächste mal dann entsprechend die PETSCII-Datei laden. alles machbar, aber so richtig glücklich macht mich das nicht.

  • So, nach den ersten Erfahrungen schnell noch ein Update nachgeschoben, aktuell ist jetzt V1.05.


    Code
    1. - verbesserte Erkennung von Stringausdrücken im Syntax-Check
    2. - verbesserte Erkennung von logischen Ausdrücken (<log>) im Syntax-Check
    3. - überflüssige Leerzeichen nach dem Tokenisieren aber vor dem Syntax-Check entfernt, dadurch nicht mehr anfällig gegen "unerwartete Leerplätze"
    4. - Endlosschleife bei Erkennung gültiger PRINT-Ausdrücke (<print>) behoben
    5. - nach Fehler-Erkennung im Syntax-Check wird jetzt der Cursor an die entsprechende Stelle im Source positioniert
  • Version 1.07 hochgeladen


    Code
    1. - Bugfix, Program crashte wenn minimiert
    2. - Proofreader zugefügt (F8) - ermittelt für jede Zeile die Checksum nach dem ersten Proofreader-Algorithmus aus der Compute
    3. (Alle Zeichen der Zeile außer Leerplätzen werden als ASCII 8 Bit ohne Überlauf aufaddiert, der resultierende 8-Bit-Wert am Ende ist die Prüfsumme)
  • Version 1.10 hochgeladen:

    Code
    1. - nach erfolgreichem Syntax-Check werden jetzt noch alle Sprünge auf Gültigkeit geprüft
    2. - Intelli-Auto eingebaut


    Intelli-Auto bedeutet, dass die Auto-Numbering Funktion jetzt die Zeilen über und unter der einzufügenden Zeile beachtet und eine Zeilennummer dazwischen erzeugt. Also zwischen 10 und 20 automatisch die 15 vergibt, zwischen 15 und 20 dann die 18 usw. Sollte kein Platz mehr sein, werden die nachfolgenden Zeilen, soweit nötig, um 1 nach oben verschoben, dabei werden natürlich alle Sprünge entsprechend angepasst.
    Im Endeffekt bedeutet das, Auto Numbering einmal einschalten und dann Zeilennummern beim Eingeben einfach vergessen, das System kümmert sich um alles!


    HOL2001: Gute Idee, hab ich mal gemacht!

  • WOW! Das nennt man Fortschritt :)


    Habe vorher immer mit Word und VICE (cut/paste) und manchmal tok64 gearbeitet. Dies gehört jetzt definitiv zur Crossdevelopment toolliste dabei.


    Wenn ich das richtig sehe wird das Font vom Originalen CharROM des Cevi's generiert?


    Wäre eine Simons Basic Token Unterstützung schwierig ein zu binden?

  • Zitat

    Wenn ich das richtig sehe wird das Font vom Originalen CharROM des Cevi's generiert?


    Jupp, genau, den Font für den VC-20 und den C64 findest Du im fonts-Unterverzeichnis, einstellen, welchen er benutzt kannst Du in der BasEdit.Ini

    Code
    1. ' character ROM file
    2. chargen=fonts\chargen64


    Du kannst auch einen selbstdefinierten Font nehmen, das File muss 2*256 Zeichen a 8 Byte enthalten, bzw. die 4k werden so interpretiert...


    Zitat

    Wäre eine Simons Basic Token Unterstützung schwierig ein zu binden?


    Sollte problemlos möglich sein, Du brauchst nur ein entsprechendes Tokenfile zu erzeugen, siehe beiliegende Samples für diverse Basic-Dialekte.
    Schön kann man das am Beispiel TokenList_BasicV7.txt für das Basic V7 des C128 sehen:

    C
    1. ; Basic V7
    2. #include TokenList_BasicV2.txt
    3. rgr, $CC
    4. rclr, $CD
    5. ...


    d.h. für SimonsBasic benötigts Du sowas wie

    C
    1. ; Simons Basic
    2. #include TokenList_BasicV2.txt
    3. ...ab hier die Tokens von SimonsBasic...


    Leider werde ich aus der Übersicht hier: Basic-Tokens bei SimonsBasic nicht schlau, was sollen die ganzen >> Tokens???

  • Leider werde ich aus der Übersicht hier: Basic-Tokens bei SimonsBasic nicht schlau, was sollen die ganzen >> Tokens???


    Tokens sind Kürzel für BASIC Befehle. BASIC benutz sie um Platz zu sparen und es erhöht die Geschwindigkeit des Interpreter enorm.


    Das BASIC-II des C64 nutz nicht alle Codes für Token. Die "freien" Token werden leider unterschiedlich interpretiert von verschiedenen BASIC Varianten.


    Simos's BASIC nutzt offenbar zwei Byte Tokens. Dadurch schlagen die mehrere Fliegen mit einer Klappe:

    • Die maximale Anzahl neuer befehle erhöht sich auf 256!
    • Es gibt keinerlei Kollisionen mit bestehenden BASIC Dialekten.
  • Jupp, genau, den Font für den VC-20 und den C64 findest Du im fonts-Unterverzeichnis, einstellen, welchen er benutzt kannst Du in der BasEdit.Ini


    Quellcode
    1
    2
    ' character ROM file
    chargen=fonts\chargen64


    Ich hatte es schon gesehen und geändert. Perfekt!


    Leider werde ich aus der Übersicht hier: Basic-Tokens bei SimonsBasic nicht schlau, was sollen die ganzen >> Tokens???


    Ich bin mir da nicht sicher, aber sind die Basic V2.0 und die Simons Basic Anweisungen zusammen nicht mehr als 256, und somit ein zweites Byte benötigen zur Erkennung?


    Edit:
    Diddl
    Da bestätigst du meine Vermutung.

  • Hi Diddl, das ist mir schon klar - ansonsten würde mein BasEdit nicht funzen.
    Ich unterstütze bereits 2-Byte Tokens, wie sie z.B. Basic V7 benutzt und sogar 3-Byte-Tokens, wie sie Waterloo Structured Basic benutzt. Das sind quasi 1-Byte-Tokens mit angehängter 2-Byte-Zieladresse für Schleifen, um sofort dahin zu springen statt erst den Basic Quelltext nach der Zeilennummer zu durchsuchen. Also soweit sogut.


    Was mit Kopfzerbrechen bereitet ist folgendes:

    Code
    1. 6428 at(
    2. 6429 until
    3. 642a >>
    4. 642b >>
    5. 642c use
    6. 642d >>
    7. 642e global
    8. 642f >>


    Was soll ich mit 642a, 642b, 642d und 642f anfangen? Was sind das für Befehle? Und von diesen ">>-Befehlen" tauchen noch viel mehr in der Liste auf.
    Ich könnte natürlich ein Tokenfile machen, in dem alle anderen befehle aus der Liste drin sind, aber irggendwie hab ich ein ungutes Gefühl dabei. Es sei den irgendjemand kann bestätigen, dass die ">>-Befehle" einfach nicht implementierte Codes sind.

  • Neue Version 1.11 hochgeladen

    Code
    1. - Fehler bei der Prüfung auf gültige Sprungadressen behoben
    2. - kleine Syntax-Änderung für den RUN Befehl in TokenFile_BasicV2.txt


    Die Syntax-Änderung war nötig, weil außer RUN und RUN 100 auch sowas wie RUN X oder auch RUN 1+X*(2-3+A) gültige Befehle sind. Letztendlich wird alles, was keine Zahl-Konstante ist, als RUN 0 interpretiert. Daher musste ich die Syntax von "c[<num_lit>]" auf "c[<num>]" ändern.
    Achtung: Der Syntax-Check meckert allerdings bei einer Zeile wie 10 RUN X jetzt eine ungültige Sprungadresse an. RUN oder RUN 100 werden natürlich noch korrekt erkannt. Eventuell bau ich dafür nochmal einen workaround, erschien mir jetzt aber nicht so releant wie den ersten Fehler zu beheben...

  • Das Ganze ist viel komplizierter als ich dachte, allein dass RUN <ausdruck> geht wusste ich gar nicht!



    Damit sind vermutlich alle RENUM Implementierungen an die Wand gespielt. Wenn ich mir das Sprungziel errechnen kann, darf so ein Programm nicht mehr neu nummeriert werden. Nur wenn alle Ziele konstant sind ist RENUM ok.

  • Nö, RENUM ist safe, weil nur RUN <constant> tatsächlich zu <constant> springt, RUN <expression> hingegen sprint immer in Zeile 0, egal, was für ein Ausdruck da steht. Scheint mir ein Bug im Interpreter zu sein, anscheinend ist bei der Berechnung des Sprungzieles jenseits von Konstanten irgendwas schiefgelaufen und es kommt immer 0 raus.


    Lustig ist auch Folgendes:

    Code
    1. 10 GOTO100BLABLABLA


    Das springt tatsächlich in Zeile 100 ohne zu meckern.


    Auch sehr schön:

    Code
    1. 10 GOSUB100BLABLABLA:PRINT"WIEDER DA!"
    2. 20 END
    3. 100 PRINT"SUB 100"
    4. 110 RETURN


    Das springt in Zeile 100, printet "SUB100", kommt zurück und printet "WIEDER DA!".


    Solche Konstrukte meckert allerdings mein Syntax-Checker an, ich hoffe, niemand benutzt solchen Dreck :argue


    Ebenfalls im Interpreter erlaubt und von meinem Syntax-Checker auch durchgewunken:

    Code
    1. 10 GOTO100,200,300
    2. 20 GOSUB 100,200,300


    Da wird einfach nur die 100 angesprngen, der Rest wird ignoriert...


    Ich hab jedenfalls eine Menge dazugelernt nach fast 30 Jahren. Allein dafür hat sich das gelohnt.

  • Code
    1. 10 GOSUB100BLABLABLA:PRINT"WIEDER DA!"


    Also das ist wohl klar ein Bug des v2 BASIC!


    Ich verstehe noch dass er das Sprungziel (100) auswertet und springt. Also mit GOTO könnte es meinetwegen noch ok sein. Aber spätestens beim RETURN würde ich mir ein SYNTAX ERROR erwarten wegen dem BLABLA..


    Naja, Microsoft hat bis heute einen äußerst schlampigen Programierstil. Das scheint schon in den ersten Jahren so gewesen zu sein ... :(

  • Ich denke mal, das ist ein Seiteneffekt von ON X GOSUB 100,200,300 - bei X=1 oder 2 wird dann, sobald die passende Sprungmarke gefunden wurde, einfach zum nächsten : gesprungen und der Rest damit überlesen. Deswegen ist auch ein Konstrukt wie 10 GOTO 100,200,300 erlaubt. Das hat wohl eher mit platzoptimiertem Code wegen zu wenig ROM zu tun als mit Schlamperei, weil die Auswertung nach GOTO/GOSUB immer die gleiche ist, egal ob vorher ein ON X stand oder nicht.
    Nachdem ich jetzt ein paar Tage mit dem Syntax-Check zugebracht habe, muss ich sagen, dass der Basic V2 Interpreter schon ein recht geniales Teil ist, an einigen Befehlsfolgen hab ich mir fast die Zähne ausgebissen und das in einer vergleichsweise bequemen Hochsprache. Der Syntax-Check belegt etwa 1.400 Programmzeilen bei mir... Dafür kann ich den über Tokenfiles und eine Syntaxbeschreibung steuern :)