Hallo Besucher, der Thread wurde 57k mal aufgerufen und enthält 397 Antworten

letzter Beitrag von Boulderdash64 am

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

    Ich weiß ja nicht, was BASIC 4.5 (also BASIC 3.5 für C64) vom normalen Interpreter verwendet, aber der BASIC-V2-Code ab $A000 ist de facto nicht geeignet vor dem lesenden Zugriff ROM weg- oder RAM einzublenden. Das BASIC 3.5 der C264-Linie macht alle releventen (ZP),Y Zugriffe (Programmtext, Variablen+Arrays, String-Heap) über einen Stub-Routine (GetUnderROM), in denen das RAM bei ausgeschaltetem Interrupt eingeblendet, das Datum geholt wird und wieder ausgeblendet wird, wobei das Aus-/Einblenden bei der C264-Architektur schon recht effizient mit einer einfachen Schreibaktion auf eine Speicherstelle geht. Bei C64 muss man mit Port $01 herumwursteln (maskieren und mit dem Akku herumjonglieren). Vorteil bei der C264-Architektur ist, dass man fürs Schreiben nichts weglenden muss, weil IO > $F000 liegt. Beim C64 müsste man, wenn man den I/O-Bereich $D000 bis $DFFFF dabei haben will, dann auch noch das Schreiben über einen Stub führen. Das wird dann schon ziemlich unelegant.


    Ich mein, wenn man viel ROM-Platz hat (diese Stub-Aufrufe brauchen mehr Platz und so manche Optimierung lässt sich dann auch nicht mehr so direkt verwenden) und man mit dem gebremsten Zugriff zugunsten des RAMs leben will, dann geht das natürlich alles. Der Aufwand das BASIC V2 quasi komplett zu überarbeiten (ich ahne, dass BASIC 3.5 für C64 von Bank-Switching keine Ahnung hat) ist meiner Schätzung nach beträchtlich.

    Die Idee das in Programmtext und Variablen und String-Heap zu trennen ... das schränkt das ganze wieder zu sehr ein, wär für mich ein zu harter Kompromiss, wenn man schon so einen Aufwand treiben will. Das Zeil sollte sein, das volle RAM zu nutzen, egal in welcher Konstellation Programmtext, Variablen und Strings anfallen.

    Der Aufwand wäre sicherlich beträchtlich.

    Aber es würde sich bestimmt lohnen.


    Allerdings ist dann die Frage, ob man nicht gleich was richtig vernünftiges macht.

    Ein modernes BASIC.

    Mit langen Variablennamen.

    Mit Funktionen und lokalen Variablen ...


    FUNCTION ... [EXIT FUNCTION ] ... END FUNCTION

    SUB ... [EXIT SUB] ... END SUB


    Moderne Kontrollstrukturen.

    DO .. [EXIT DO] .. LOOP

    DO WHILE xx ... LOOP

    DO UNTIL xx ... LOOP

    DO ... LOOP WHILE xx

    DO ... LOOP UNTIL xx

    IF .. THEN .. ELSE .. ENDIF

    FORALL xx IN yy .. [EXIT FORALL] .. END FORALL


    Listen wäre auch ein sehr starkes Konstrukt.



    Das DEF FN() von BASIC 2 ist ja schon ein guter Ansatz.

    Leider geht es nur für numerische Ausdrücke und nicht für Strings.

    Wäre vielleicht eine Variante - aber wäre das nicht etwas VIEL für den doch recht kleinen verfügbaren Speicher? FN() mit Strings dürfte doch bspw. ne Menge Platz brauchen und auch die anderen Ideen sind sicher nicht platzsparend... Wenn es dann nur jemand nutzen kann, der eine 1 MB RAM-Erweiterung besitzt, wird keiner den Aufwand auf sich nehmen, das zu schreiben für DANN davon noch 3 Leute, die es tatsächlich auch nutzen...


    Damit es sich verbreitet, sollte die nötige Basis relativ verbreitet sein und die üblichen 32 K RAM sind aus meiner Sicht zwar verbreitet - aber echt knapp bemessen...

    Guten Morgen zusammen,


    daraus ist ja ein recht interessanter Verlauf geworden. Die Ideen sind allesamt zwar maximal im „Proof of concept“ aber dennoch weiterhin Bodenständig.


    Leider habe ich das BASIC 3.5 (die PLUS/4 Variante BAISC 3.5 nach C64 implementiert) mangels Dokumentation nur in kleinen Teilen verstanden.

    Immer dort wo ich mich mit meinem BASIC 4.5 eingeklinkt habe, sind mir die Funktionen klar.

    Außerdem ist das ROM Listing des PLUS/4 nicht nutzbar, weil es bei der Implementierung von Michael Schimek konstruktionsbedingt zu viele Abweichungen gibt. Selbst Core-routinen unterscheiden sich.


    Dennoch glaube ich das sich das BASIC 3.5 für den C64 nicht in ein ROM verbannen lässt und vollständig das BAISC 2.0 ROM ersetzt, weil BASIC 3.5 bei den „alten V2“ Befehlen das vorhandene BASIC ROM nutzt. Die V2 Routinen werden nicht in RAM kopiert. Dier Erweiterung, welche aus dem V2 ein V3.5 macht liegt halt unter dem ROM im RAM. Meine Erweiterung der Erweiterung Endet bei 9FFF, weil ab A000 die V3.5 Version beginnt.

    Um das zu realisieren ist der Aufwand so hoch, das ich auch eine BASIC Variante "from scratch" entwickeln könnte.


    Zitat Diddl :

    Allerdings ist dann die Frage, ob man nicht gleich was richtig vernünftiges macht.
    Ein modernes BASIC.
    Mit langen Variablennamen.
    Mit Funktionen und lokalen Variablen ...

    Ja, das fänd ich auch toll. Mit einem drei oder Mehrköpfigen Entwickerteam sicher machbar, aber ich bin alleine und nur Stundenweise in der Woche an BASIC 4.5 tätig. Leider ist das Klientel recht bescheiden um damit seine Brötchen zu verdienen. Und ein Quickbasic, ala DOS nachzubilden....Wo bleibt den da der Charme der 80er.....


    Auf der anderen Seite lag es nie in meinem Focus ein BASIC mit 50K freien Speicher als ROM Cartridge zu entwickeln. Als reiner 8Bit Assembler Hobbyprogrammierer kann ich neben meinem ausfüllenden Beruf nicht genügend Enthusiasmus in mich rein kippen um damit die Nächte zu verbringen. Irgendwann möchten meine Frau und mein Bett mich sehen :emojiSmiley-12:


    Meine Motivation ist: Spaß am 8Bit Programmieren und neben bei unseren Casual-Basic-Programmierern das Leben etwas zu erleichtern.

    Sollte sich jemand berufen fühlen so etwas zu entwickeln, so bin ich sicher ein sehr interessierter Mitstreiter. Aber im Alleingang habe ich da offen gestanden keine Motivation.


    Dennoch, Daumen hoch an alle die sich für mein Projekt interessieren!! :thumbup:

    Einen riesen Dank und einen noch größeren Daumen an alle die BASIC 4.5 auch für ihre kleinen oder großen BASIC – Projekte nutzen. :thumbsup:


    Den größten Dank gilt all denen die mich in der Vergangenheit bei kleineren oder größeren Problemen tatkräftig unterstützt haben.:respect:


    Zusammenfassend:

    Was ist tun werde: Ich werde BASIC 4.5 weiterhin pflegen (soweit es meine Zeit zu lässt), BUGS beseitigen und ab und an neue Ideen hinzufügen.:f5:

    Was ich nicht tun werde: Alles daran legen um ein Cartride BASIC zu entwickeln mit 50K freien Speicher oder ein QBASIC für den C64.:saint:


    Vielen Dank!!

    Ein Hauptproblem ist also: 4.5 setzt auf das 3.5 auf, was vom C16/plus 4 stammt, aber seinerseits auf 2.0 aufgesetzt schon ist - schönes Wirrwarr... ;-)
    Also technisch "sauberer" wäre es damit gewesen, tatsächlich alles ALTE komplett links liegen zu lassen und ein völlig davon unabhängiges 4.X zu schreiben - also incl. aller alten, EIGENTLICH schon vorhandenen Befehle...

    Wobei es aber vermutlich einfacher und zeitlich weniger aufwändig gewesen wäre, genau das zu tun - etwas in ein schlecht, oder gar nicht dokumentiertes System einzubauen ist eigentlich IMMER sehr viel aufwändiger, als es sauber Neu zu machen - zumal man alte Bugs ja übernimmt und diese dann auch beheben möchte, was NOCH mühsamer sein dürfte?!?


    Soll kein Meckern sein!! Bitte nicht so deuten - sind nur meine Erfahrungen aus meiner SPS- & Roboterprogrammierzeit...

    Zitat von Boulderdash64

    Ein Hauptproblem ist also: 4.5 setzt auf das 3.5 auf, was vom C16/plus 4 stammt, aber seinerseits auf 2.0 aufgesetzt schon ist - schönes Wirrwarr... ;-)
    Also technisch "sauberer" wäre es damit gewesen, tatsächlich alles ALTE komplett links liegen zu lassen und ein völlig davon unabhängiges 4.X zu schreiben - also incl. aller alten, EIGENTLICH schon vorhandenen Befehle...

    Wobei es aber vermutlich einfacher und zeitlich weniger aufwändig gewesen wäre, genau das zu tun - etwas in ein schlecht, oder gar nicht dokumentiertes System einzubauen ist eigentlich IMMER sehr viel aufwändiger, als es sauber Neu zu machen - zumal man alte Bugs ja übernimmt und diese dann auch beheben möchte, was NOCH mühsamer sein dürfte?!?

    Schon richtig, sehe ich auch so (rein als Ideal). Das war wohl die Design-Entscheidung des ursprünglichen Autors. Er wird seine Gründe gehabt haben. Vordringlich waren ihm anscheinend eher die Möglichkeit beim C64 das BASIC-3.5-Flair zu erleben, vermutlich gepaart mit zeitlichen Einschränkungen bei der Entwicklung und das Projekt noch zeitgerecht zu veröffentlichen. Dann noch Sahnestückchen wie 60 K-RAM und eine ROM-Version (die für eine eine reine Software-Lösung eher weniger Verbreitung fände) wird er sich wohlweislich erspart haben (schon alleine vom Aufwand - nicht allen ist die Gnade zuteil geworden, sich beispielweise für 3 Monate zu verbarrikadieren, um ein Projekt fokussiert durchzuziehen).

    Ja schon, aber da sind wir dann schon bei einem ganz anderen Thema und hier off-topic. ;)

    Wie schon im vorigen Post gesagt, der Aufwand würde sich grundsätzlich lohnen. Aber man darf das Ziel von BASIC 3.5 auf dem C64 nicht vergessen. Aus meiner Sicht erwächst der "Nutzen" aus einer gewissen Kompatibilität zu C264-Software und der Portabilität.
    Dass nun dg5kr hier dies als Basis genommen hat, um eigene Erweiterungen zu ergänzen, hat wohl praktische Gründe, vermutlich weil es einfacher und weniger Aufwändiger ist, als so eine Erweiterung komplett neu zu entwerfen. Das wäre dann eher schon ein Community-Projekt und nicht, wo ein Einzelkämpfer von gelegentlich Zeit investieren kann (und dabei seinen Spaß an der Entwicklung hat - die würde ich ihm nicht mit hochtrabenden Ansprüchen zunichte machen wollen). ;)

    Ansprüche sowieso nicht - ich sehe es eher als Ideenfindung, Brainstorming, Anregungen, vielleicht natürlich auch Wünsche, weil wir ja Menschen sind :emojiSmiley-02: - WAS er dann macht, entscheidet letztendlich ER oder jemand, der sich der Sache widmet. Natürlich wäre es zu begrüßen, mehrere in so ein Projekt zu integrieren - nur WIE??

    Optimal wären da Leute, mit ähnlicher Ahnung, Ambitionen und Wohnsitz jeweils "um die Ecke"...

    Jeek hat da schon recht. Genau so war es. Ich hatte zunächst auf der grünen Wiese begonnen eine BASIC Erweiterung zu schreiben. Da ich damals in den 80ern das BASIC V2 nicht gelungen fand, aber in BASIC 3.5 Variante (nur leider auf der 264er Reihe) gelungen fand, wollte ich was ähnliches "bauen". Allerdings verlor ich mit derzeit mehr und mehr die Lust, Befehle neu zu entwickeln dies es bereits im BASIC 3.5 gab. Also überlegte ich mir welche Befehle ich neben den 3.5er gerne auch noch gehabt hätte. Da kam mir die Version von Michael Schimek sehr recht und ich begann dort auf zu setzen um zu das BASIC 3.5 mit meine eigenen Ideen auf zu werten.


    Gerne würde ich hier das Warum hat er oder warum könnte er... abschliessen.

    Und gerne, sehr gerne nehme ich Ideen oder Vorschläge auf die in dem Fokus dieses kleinen Projektes passen, welches von einer One-Man-Show geführt wird.


    Und wie bereits mehrfach erwähnt bin ich bemüht die Version so gut ich das schaffe zu pflegen.


    In meinem nächsten Thread möchte ich mich wieder den konkreten technischen Umsetzungen eine kleinen Problems in BASIC 4.5 widmen, was ich aktuell habe.

    Danke an alle die mich unterstützen :thumbsup:

    Ich habe wieder eine kleine Herausforderung.
    Der Befehl INFO ist inzwischen obsolete. Also habe ich mir überlegt, was stelle ich mit dem frei gewordenen Token so an.

    Was ich oft vermisse, ist ein kleiner, einfacher Editor Um Texte in SEQ Files zu schreiben.

    Un hier meine Idee.


    - Die Notiz umfasst zunächst genau eine Bildschirmseite (Sticky Notes)

    - Ich möchte den vorhanden Bildschirmspeicher nehmen (in -B45 aktuell von TEXT: $0C00-$0FC0, FARBE:$D800-$DBC0)

    - Wegen dem Speicherplatz sollen so viele wie nur irgend möglich KERNAL oder BASIC Routinen genutzt werden.


    In meiner Vorstelung könnte der Prozess grob so abblaufen:

    ;- 1. Bildschirmbereich sichern (in freien Specher ablegen) $0C00 - $0FC0, $D800-$DBC0

    ;- 2. Sende ein ESC-N (Kill Window, SCR) und ESM-M (Scrolling ein)

    ;- 3. Die ENTER Taste soll keinen Befehl absetzen (Verbiege Pointer?? oder KEYIN Schleife??)

    ;- 3. Es wird nur im Screen frei editiert. Dazu stehen die normalen Editiertasten wie in BASIC zur verfügung.

    ;- 4. SAVE mittels Hotkey (RUN-STOP o.ä.)

    ;- 5. Save Notes to Disk als SEQ

    ;- 6. Restore den Screen

    ;- 7. Stelle ggf. Pointer(s) wieder her.


    In meiner naiven Vorstellungdachte ich Kernel oder BASIC brächte ja alles mit.


    Mein jetiges Ergebnis ist eher ernüchternd. Den Bildschirmspeicher zu sichern und wieder herzustellen war reine Fingerübung.

    Aber dann gings los. Zur Zeit nutzte ich die Kernal Routine GETIN ($FF4E) in einer Schleife um die Tastatur anschläge zu registrieren. Die Zeichen auf den Bildschirm zu schreiben war auch einfach. Aber es fehlte der Cursor. Der war schnell programmiert. Jedoch beiße ich mir die Zähne aus an der Darstellung des Zeichens unter dem Cursor.

    Fazit: Ich habe inzwischen viel zu viel eigenen Code rein gesteckt, so das einfach zuviel Memory verbraucht wird. Und irgendwie glaube ich das mann diesen kleinen Editor viel effizienter hinkriegt. Ich werde das Gefühl nicht los inzwischen einige Funktionen programmiert zu haben, die es im ROM bereits gibt......


    Ich brauche IDEEN und Codesnipsel.


    In der Anlage das "PROOF of Concept" in einer very early version.

    Das Cursorblinken kann man komplett dem System überlassen, das Konvertieren von/zu Screencode ebenso. Hier ein Beispiel:

    Einsprung via @entry, den END_CHARACTER muss man selbst festlegen.

    Ich habs jetzt nicht getestet, sondern nur aus dem Sourcecode meiner Eingabepuffer-Routine zusammengestückelt.

    Ich bin nicht sicher, ob das hierher passt, aber in DurexForth dient eine abgespeckte Vim-Variante als Editor. Vielleicht kann man sich das ja mal genauer ansehen.

    Zitat von Mac Bacon

    Das Cursorblinken kann man komplett dem System überlassen, das Konvertieren von/zu Screencode ebenso. Hier ein Beispiel:

    Code
    1. !address {
    2. z_chars_in_keybuf = $c6
    3. z_cursor_disable = $cc ; zero means interrupt handles cursor
    4. .........

    Einsprung via @entry, den END_CHARACTER muss man selbst festlegen.

    Ich habs jetzt nicht getestet, sondern nur aus dem Sourcecode meiner Eingabepuffer-Routine zusammengestückelt.

    Wow, das ist mehr als ich erwartet habe. Vielen Dank. Ich werde es zügig testen und melde mich. Nochmals Danke!

    Hallo zusammen,

    ich habe nochmal die Zeit gefunden ein wenig an BASIC 4.5 zu schrauben.

    Der Befehl INFO wurde in seiner Funktion "ersetzt". Aus einer kleinen HILFE-Seite (One-Pager) wurde eine Art MEMO Funktion.

    Das war der Grund für meine Anfragen vorher zum Thema "minimal Editor".


    Was ist neu/anders:

    Gibt man INFO zum ersten mal ein, so wird der Bildschirm gelöscht und ein blinkender Cursor erscheint oben links.

    Jetzt kann ich allerlei Zeugs reinschreiben was alles in einem Bildschirm (40x25) passt. Dabei ist der Business-Mode (kleine Zeichen) Standard.

    Zum Editieren, wie Zeile einfügen/löschen oder Zeilenende löschen usw., dienen die oft wenig beachteten ESC-Codes ab BASIC 3.5 Version.

    Ein CTRL-Q und direkt gefolgt von einem ENTER (RETURN) speichert das geschriebene in ein File Namens MEMO.TXT ab. Wird der Befehl INFO

    erneut aufgerufen, so wird dieses File vorher automatisch geladen und die letzte Notiz wird angezeigt.

    Zufünftig plane ich den Befehlo INFO in "MEMO" umzubenennen weil es einfach besser passt.


    Auszug aus den ESC-Kommandos


    Laden könnt Ihr die Version und die aktuelle Dokumantation aus dem Link in meinem Footer.

    Über Feedback freue ich mich.

    Zitat von dg5kr

    Ein CTRL-Q und direkt gefolgt von einem ENTER (RETURN) speichert das geschriebene in ein File Namens MEMO.TXT ab.

    Kleine Korrektur: Es ist nicht die CRTL-Taste, sondern die C= Taste. Also C= Q gefolgt von einem RETURN beendet den Editor. Das liegt daran das ich in der Entwicklung einen Emulator nutze und die C= auf der CTRL liegt. :platsch:

    Dann scheint es noch einen BUG zu geben: Aus bisher nicht nachvollziehbaren Gründen werden Änderungen manchmal (nicht immer) NICHT auf Disk geschrieben. Da bin ich aber dran und werde baldigst eine Korrektur zur Verfügung stellenn

    Zitat von dg5kr

    Über Feedback freue ich mich.

    Ich habe es gerade mal ausprobiert. Gleich vorneweg: Ich finde es gut umgesetzt und es hat soweit auch alles funktioniert. :thumbup:


    Aber ... es ist wie so oft Ansichtsssache. Für mich hat dieser INFO-"Befehl", genauer gesagt: Notizseite, nichts in einer BASIC-Erweiterung zu suchen. Das hat keine Funktion, die das BASIC an sich erweitert. Den dafür verwendeten Speicherplatz würde ich eher für BASIC-Funktionen verwenden.


    Aber, wie gesagt, ist nur meine persönliche Meinung und die wollte ich dir als Feedback geben. ;)

    Zitat von Snoopy

    Aber ... es ist wie so oft Ansichtsssache. Für mich hat dieser INFO-"Befehl", genauer gesagt: Notizseite, nichts in einer BASIC-Erweiterung zu suchen. Das hat keine Funktion, die das BASIC an sich erweitert. Den dafür verwendeten Speicherplatz würde ich eher für BASIC-Funktionen verwenden.


    Aber, wie gesagt, ist nur meine persönliche Meinung und die wollte ich dir als Feedback geben. ;)

    Das stimmt. Es hat erstmal nix mit BASIC als solche zu tun. Könnte aber in BASIC-Projekten von nutzen sein.

    Aber der Hauptgrund liegt eher in der Historie:

    Weiter in der Vergangenheit dieses Themas habe ich den Befehl INFO Text aus Platzgründen in eine SEQ Datei verbannt. Das kam aber nicht gut an. Im Zuge der dann folgenden Diskussion war es klar das Aufgrund meines Handbuches der INFO Befehl eigentlich überflüssig war. Jetzt war ich aber in der Zwickmühle. Wenn ich einen Befehl wegnehme verschieben sich die Token und die Programme laufen nicht mehr. Es würde also ein "toter" Befehl werden. Das fand ich zu schade. Weiter kam hinzu das BASIC 4.5 inzwischen im C64Studio übernommen wurde und ich dem Autor nicht ständige Tokenänderungen zumuten möchte.

    Somit kam mir die Idee das INFO ja auch Informationen bringen und das könnten ja auch eigene Infos sein. Somit war die "Mini Memo Seite" geboren.


    Also nochmal: Ja du hast recht. Die Bytes hätte ich anderweitig nutzen können. Es gab da mal den Vorschlag Datenbank artige Befehle einzuführen. Das steht bei mir noch auf der Liste. Aber auch hier wird die Premisse sein: Wenige ist mehr. Wer Datenbanken programmieren will, der soll auf Superbase zurück greifen.


    Es ist aber sehr schön zu lesen das der Editor funktioniert. Eventuell findest du ja doch gefallen dran ^^

    Zitat von dg5kr

    Dann scheint es noch einen BUG zu geben: Aus bisher nicht nachvollziehbaren Gründen werden Änderungen manchmal (nicht immer) NICHT auf Disk geschrieben.

    Wenn ich BASIC 4.5 als Modul starte (CRT), dann wird die Datei nie abgespeichert. Auch wenn eine Diskette in 8 liegt.


    Geht das nur mit dem BASIC, wenn es von Diskette gestartet wird?

    Zitat von Snoopy

    Wenn ich BASIC 4.5 als Modul starte (CRT), dann wird die Datei nie abgespeichert. Auch wenn eine Diskette in 8 liegt.


    Geht das nur mit dem BASIC, wenn es von Diskette gestartet wird?

    Nein, das sollte immer funktionieren. Ich habe die Version 21.06.17 zum Download bereit gestellt. Bei mir ging es jetzt als PRG und CRT.

    Bitte nochmal probieren (mit VER auf richtige Version achten)

    Danke!

    Ich denke, ich mache hier was verkehrt:


    Ich benutze VICE 3.1 unter Linux Lite (Ubuntu)



    Lasse mir ein leeres D64-Images in Laufwerk 8 erstellen und einlegen.


    Lege dann das CRT ein. VICE startet dann neu und zeigt mit alles korrekt an:



    Ich schreibe eine kurzen Text und gehe mit C= + Q und RETURN wieder raus



    Hier ist kurz ein "unknow error" sichtbar bevor ich wieder im BASIC bin.


    Auf der Diskette ist leider nichts angelegt worden: