Hello, Guest the thread was called19k times and contains 312 replays

last post from dg5kr at the

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...

    Quote from 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.

    Quote from 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!