Posts by dg5kr

    Beim Durchlesen der letzten Posts habe ich mich sehr unterhalten gefühlt. Ich verspreche euch, in BASIC 4.5 werden sicher ein Duzend Bug drin sein. 😉

    Ich möchte diesen Interpreter soweit bekommen, das ich selbst Lust darauf verspüre mit ihm ein „größeres“ BASIC Projekt direkt und ohne Umweg über einen PC auf den C64 selber zu realisieren.

    Es gab zum Thema Bugs schonmal eine Diskussion. Da ging es um mangelhaftes Tests bei BASIC 4.5 usw. Ohne auf den Inhalt ein zu gehen: Ich hätte längst den Spaß ans Programmieren in 6502 Assembler, respektive auf den C64 verloren wenn da wie jetzt auch es mal richtig kniffelig werden kann. Weiter habe ich bemerkt, das bei solche Themen immer wieder unglaublich viel und richtig geile Ideen zum Vorschein kommen.

    Leute: Ihr seid einfach großartig. Danke!

    So, genug den Bauch gepinselt. Denn das bringt mich kein stück weiter :idea:Also her mit den Lösungsvorschlägen.
    Ich habe gerade das C64Studio geöffnet und werde weiter an das rückwärts scrollende BASIC Listing tüfteln :rauchen:

    Wenn du vom Start der aktuelle Zeile, deine 90 Bytes zurückspringst und ab da vorwärts suchst, bis du an dem Start einer Zeile vor der aktuellen bist, dann ist es entweder die Zeile vor der aktuellen oder es kommen noch weitere (kurze) Zeilen vor der aktuellen.


    Auf alle Fälle musst du viel weniger vorwärts Suchen als wenn du jedes Mal am Anfang des Codes startest.

    In der Tat scheint mir das nach der regen Ideen-Diskussion am Ende des Tages ein Sprung um 1-n Zeilen zurück eine Sinnvolle Lösung. Mit den bereits existierenden Lösungen von FC3 oder Programmers Helper habe ich an Ermangelung von längeren BASIC-Listings keine Erfahrung mit den Laufzeiten sammeln können. Der C65 (Suche ab der 1. Zeile) scheidet aufgrund der "moderneren" Architektur auch aus, da ich glaube das er ohne hin intern Programme schneller ausführt.
    Aber: Aus meiner Sicht bleibt bei einem Sprung mitten in eine BASIC-Zeile immer noch das Restrisiko die 00-Bytefolge fälschlicherweise als Zeilen Ende zu erkennen obwohl es entweder eine Zeilenummer oder schlimmer eine "gepokter" DATA Code sein könnte. Wobei zugegeben: Wer in BASIC Code in fixen Adressen pokt um Codeänderungen zu machen, der macht sich die Probleme selbst. Das sollte alse eher selten sein.


    Je mehr ich darüber nachdenke, desto mehr bevorzuge ich die Lösung mit den 90Byte Rücksprung.
    Jedoch werde ich mir den Vorschlag von JeeK (oder GoDot , von wem auch immer :emojiSmiley-12:) mal genauer testen.
    Wer weiß, eventuell glingt es mir ja noch vor Weihnachten eine neue BASIC 4.5 Version raus zu bringen :D

    Ich suche vorwärts, bis ich auf die aktuelle Zeile stosse und nehme dann die Zeile davor.


    Nur mit dem Unterschied, dass ich nicht jedes Mal vom Start loslege, sondern mir die Zeilen spare, die es nicht sein können.

    Darüber habe ich auch schon nachgedacht. Eine Zeile kann maximal 80Bytes (+Header Informationen) lang sein. Springe ich als, sagen wir 90Bytes zurück. Dann lande ich im Idealfall irgendwo in der vorherigen Zeile. So weit so gut. Nun kann ich Rückwärts das Ende der Vor-Vorherigen suchen und dann den Anfang der Zeile danach. Das wäre dann (aber nur dann) die vorherige Zeile.
    Wenn aber die vorherigen Zeilen aus nur einen oder wenigen Befehlen bestehen, dann lande ich bei 90Bytes rückwärts schon mehrere Expemplare zurück. Der Schuss ginge zu weit nach hinten los.
    Weiter überlegt wäre das nicht schlimm. Ich suche das Zeilen Ende dieser angesprungenen Zeile, den nächsten Anfang und vergleiche die Zeilennummer bis ich auf der aktuellen Zeile lande. Damit kenne ich die Zeilennummer und die Adresse der vorhergehenden.
    Aber: Wenn da bei der Suche nicht das Problem des 00Bytes wäre (was ja u.a. das Zeilenende kennzeichnet), den es könnte auch das 00Byte eine Zeilennummer sein.

    Ich frage mich allerdings: Das Problem des Rückwärts scrollenden Listings haben doch schon viele andere gelöst (z. B. Programmers Helper oder Final Cartridge 3)? Wie haben die das hinbekommen?

    Hallo, nach langer Zeit habe ich weiter an BASIC 4.5 gearbeitet und an meiner "Hassliebe" den BASIC Zeilen Scrolleditor.
    Ich suche nach einer Routine, wie ich ausgehend von einer aktuellen BASIC Zeile ($14/$15) die vorhergehende Zeile finde.

    Die nächste Zeile zu finden ist recht simpel, steht ja jeweils in der Zeile drin. Aber leider nicht die vorhergehende Zeile.


    Zum Beispiel:

    1090 REM MEIN PROG

    2010 PRINT "HALLO"

    3900 PRINT "DU DA."

    4000 END


    Aktuell steht der Pointer auf Zeile 3900. In $14/$15 steht also 0F3C. Jetzt muss ich aber $14/$15 mit der Zeile 2010 bestücken. Wie zum Teufel finde ich die Zeilennummer heraus. Die kann ja alles mögliche sein.

    Ich habe da voll den Blackout und brauche ein paar ideen. Wer kann mir weiterhelfen?


    Danke, Danke, Danke!

    erstmal für alle Antowrten einen riesen Dank! Ich kann gar nicht oft genug betonen wie sehr ich dieses Forum in Sachkenntnis, Höfflichkeit und Fairnis zu schätzen weiß.


    Mit der Antwort von mit LINGET scheine ich weiter zu kommen.


    Ich möchte kurz meine Motivation erklären:

    Gerne möchte ich mein BASIC 4.5 um eine sinnvolle Developerfunktion erweitern, nämlich mit den Tasten CTRL-CRSRDWN, bzw. CTRL-SHIFT-CRSREDWN das vorhandene BASIC Listing auf dem Bildschirm ab der aktuellen Zeilenposition in $14/$15 zu scrollen.

    Dabei wollte ich den Anzeige Teil mit der vorhandene LIST Funktion abgucken.


    Via Interrupt das Keyboard abzufragen und zu reagieren klappt. Nun möchte ich den Teil realisieren:

    1. Feststellt ist ein BASIC Programm überhaupt da? (Erledigt)

    2. Welche Zeile wurde zuletzt bearbeitet oder angezeigt (steht in $14/$15)

    Jetzt kommts:

    3. CTRL-CRSRDOWN? -> Zeige (wird später realisiert) Zeile in $14/$15 UND hole die Zeile danach und lege Sie in $14/$15

    4. CTRL-SHIFT-CRSRDWN? -> hole die Zeile VOR der aktuellen aus $14/$15. Speichere diese in $14/$15 und zeige diese an.


    Verstanden? Sind meine Vorstellungen prinzipell richtig?


    Daher benötige ich die Routinen wie oben beschrieben.....glaube ich :rolleyes:


    Last mich nicht hängen, ich bin echt ratlos.......DANKE :thumbsup:

    Hallo zusammen,

    ich benötige eure Hilfe. Für meine SCROLL Funktion des BASIC Editors brauche ich zwei Kernfunktionen, wo ich einfach nicht weiter komme. Ich könnte das Problem als eigene Routine lösen. Aber genau das will ich nicht weil es irgendwo im BASIC ROM Teil dafür schon was fertiges gibt. Ich find es bloss nicht.


    Ich benötige in Assembler zwei Routinen:

    "BASIC LINE 2 POINTER" -> Soll mit zur aktuellen BASIC Zeile aus Adresse $14/$15 den passenden Pointer zur Adresse im BASIC RAM dieser Zeile liefen.

    "POINTER 2 BASIC LINE" -> Wie oben, nur anders rum. Gibt es die Zeile nicht, soll in $14/$15 FF stehen


    Nach Möglichkeit sollten schon fertige BASIC Routinen verwendet werden.


    Ich Danbke euch jetzt schon!!!

    BREAKPOINT / DEBUGGING von ASM Programmen innerhalb von Interrupt Routinen oder KEYBOARD abfragen


    Hallo zusammen. Ich setze das C64Studio schon eingige Zeit ein. U. a. habe ich damit mein BASIC 4.5 für den C64 entwickelt. Hiermit möchte ich dem Entwickler einen riesen Dank und einen noch größeren Lob für seine professionelle Arbeit aussprechen.

    Trotz der vielen tausend Zeilen Code in Assembler mit dem C64Studio glaube ich noch nicht das volle Potenzial aus zu schöpfen.

    Derzeit sitze ich vor dem nächsten Improvement von BASIC 4.5. Hier werden u.a. die Vectoren $0302 (Eingabe Vektor) $0314(IRQ Vektor) verbogen um sie auf meinen eigenen Routine zu lenken. Allerdings erweist sich das Debugging meiner Routinen oft als schwierig, weil ja im Emulator bei jeden Tastenanschlag, egal welcher, meine Routine und damit auch mein BREAKPOINT aufsucht.

    Wenn ich z. B. den Programmablauf der Tastenfolge CTRL und dann F7 trace will wirds problematisch, da ich bis zum drücken der F7 ja gar nicht mehr komme, weil bei CTRL schon der BRAKPOINT angefahren wird.

    Soweit verstanden? ?(


    Meine Frage: Wie kann ich bei Tastaturfolgen erst beim "letzten" Ereignis das Programm anhalten?

    Kein neuer BASIC 4.5 Befehl, sondern eine tolle Funktion:


    Ich möchte den BASIC Editor (das ist das Teil wo man die BASIC-Zeilen rein hackt :P) gerne um eine Funktion erweitern.

    Ich habe im "Programmers Helper" und in der Final Cartridge 3 gesehen das mit den Cursortasten nach dem Befehl "LIST" in dem Listing rauf und runter gescrollen kann.

    Das mach das durchsuchen unglaublich einfach. Und genau das hätte ich gerne - Aber wie?

    Inzwischen bin ich schon mit dieser Funktion ein guten Stück voran gekommen. Allerdings habe ich noch eine kleine Wissenslücke?(:

    Ich habe es noch nicht auf die Kette bekommen die nächst größere (oder kleinere) Zeilennummer zu ermitteln. In $14/$15 ist als integer die letzte Zeile, die irgendwie bearbeitet wurde (Erstellt oder mit LIST angesehen). Ansonsten ist $14=FF, $15=FF.


    Die LIST im BASIC ROM vorhandene LIST Routine brachte mich nicht weiter (oder ich habe ihre Funktion nicht kapiert:S).

    Wer kann mich auf die richtige Spur bringen? Danke!8o

    Oja, ich Vollhorst. Da hat es überschneidende Speicherbereiche gegeben. Bitte die letzt Version downloaden. Danke für den Hinweis.

    Kein neuer BASIC 4.5 Befehl, sondern eine tolle Funktion:


    Ich möchte den BASIC Editor (das ist das Teil wo man die BASIC-Zeilen rein hackt :P) gerne um eine Funktion erweitern.

    Ich habe im "Programmers Helper" und in der Final Cartridge 3 gesehen das mit den Cursortasten nach dem Befehl "LIST" in dem Listing rauf und runter gescrollen kann.

    Das mach das durchsuchen unglaublich einfach. Und genau das hätte ich gerne - Aber wie?


    Bevor ich eine Zeile Code entwickle, würde ich die Aufgabe zunächst abstrahieren, in Teilaufgaben zerlegen und jeden Block zunächst einzel fest machen.Wenn ich das mal in Telstücke zerlege, dann würde ich folgende Blöcke bekommen -

    Der Befehl LIST setzt einen MERKER

    Die NMI Routine ist zu erweitern und fragt den MERKER ab

    Ist MERKER=1, dann Frage Tastatur auf UP/DOWN ab und springe zu den LIST-UP/LIST-DOWN Routinen

    Ist MERKER=1, dann Frage Tastaur ab ob "HOTKEY" (RESTORE oder STOP-Taste) gedrückt und setze MERKER=0

    LIST-UP: Zeige vorhergehende BASIC-Zeile auf aktuelle Cursor-Position - 1

    LIST-DOWN: Zeige nächste BASIC-Zeile auf aktuelle Cursor-Position + 1

    Verlasse NMI

    Anregungen zur Machbarkeit habe ich hier gefunden. Einen Artikel dazu gab es in der "Compute! Gazette Issue 55", Seite 81. Das Listing ist dabei, aber eben nur zum Abtippen und nicht im dokumentierten Assembler.


    Ideen? Vorschläge?

    Den Vorschlag zur Verbesserung der LOAD/SAVE Routinen von User Mac Bacon habe ich aufgegriffen und umgesetzt. Für den Hinweis mit Adresse $9D nochmals Danke.
    Die Schleife um den Screenmemory abzuklappern konnte ich mir dadurch sowohl beim LOAD, als auch beim SAVE sparen. Perfekt :thumbsup:
    Nun bitte ich markusC64 und Snoopy bitte nochmals zu testen. Vielen Dank! Die Aktuelle Version ist wie gewohnt im Link unten zu finden.

    Es scheint ziemlich sicher ein Problem von VICE zu sein. Getestet habe ich es mit VICE 3.1 unter Linux Lite und VICE 3.0 (32bit-Windows). In beiden Fällen wird im INFO nach "C= + Q" kurz ein "unknown error" angezeigt und ich komme dann wieder ins BASIC 4.5, ohne dass eine Datei auf der Diskette angelegt wird.


    Ich habe es versuchsweise gerade mit mit dem Emulator Z64K ausprobiert (BASIC 4.5 als CRT und Diskettenimage in LW 8 eingelegt) und hier funktioniert alles wie vom Erfinder gedacht. :)


    Auf dem "TheC64 Maxi" läuft es bei mir auch. Hmm, trotzdem würde ich gerne die Ursache kennen. Ich werde mal eine Version publizieren, die etwas "geschwätziger" ist (DEBUG-Version) und hoffentlich diese uminöse "unknow error" etwas mehr umschreibt.

    Seltsam. Ich habe ausschliesslich Kernel Einsprünge zum SAVe verwendet:

    Warum machst Du das denn manuell per OPEN/CHKOUT/CHROUT/CLOSE? Nimm doch einfach $ffd8 (Kernal-SAVE).

    Nun, die Routine $FFD8 verlangt im Vorfeld genauso eine parameterisiertes SETLFS und SETNAM. Da spare ich also nicht wirklich viele Bytes. Weiter (aber das ist mein persönlicher Geschmack) fand ich das erscheinende "saving...." als störend und habe deshalb meine "eigene" Routine mit den jeweiligen Kernal I/O Routinen angesprochen. Das ist alles....

    Snoopy Original C64 Kernal oder Speeder?


    Ich habe das CRT nämlich gerade am Ultimate 64 ausprobiert und dabei festgestellt, dass der "INFO"-Befehl offenbar mit Speeder-Kernals Probleme hat, mit "S-Jiffydos V2" ist der sogar abgestürzt.

    Seltsam. Ich habe ausschliesslich Kernel Einsprünge zum SAVe verwendet:


    Bitte entschuldige die lange Antwortzeiten. Mein Job fordert mich zur Zeit wieder ganz schön.
    was ich in deiner Config vermisse sind die Einstellungen für Diskette und CRT Devices.
    wenn du das CRT geladen hast, deine Diskette eingelegt, könntest du diesen Zustand mal in deiner Config speichern und mir wieder zu senden?


    Vielen Dank.

    Also, ich habe es mal versucht nachzuollziehen. Jedoch kann ich den Fehler nicht reproduzieren.


    Könntest du mir mal deine Vice-Config (nur die C64 Sektion) zu senden.


    Benutzt du eine SDL oder eine X11 Version? Oder anders gefragt: Selbst kompiliert oder per Reositoroy installiert?

    Im Home sollte es eine .vice geven. Bei SDL steht dort eine Datei sdl-vice, bei X11 weiß ich es offen gestanden nicht.

    Hi Snoopy,

    ich glaube du machst nichts falsch.
    Ich bin zur Zeit noch im Homeoffice und kann noch kann esrt später nachsehen, bzw. testen. aber ich habe einen Verdacht:

    Die Speicherstelle $BA Kennzeichnet das letzte Laufwerk, welches im Zugriff war. Wird ein Programm von Disk geladen, hat ie ganz klar den Wert der Drive-Nr. Aber bei einem CRT bin ich mir da über den Wert nicht sicher. Und eine Prüfung auf Werte <8 und >12 führe ich nicht durch.

    Könntest du bitte folgendes Testen:

    CRT Laden und direkt danach mit ? peek(dec("00BA")) den Wert abfragen. Ist er 8 - 12? Wenn nein, dann lege eine Disk ein und lade das Directore mal mit dem load "$",8 und schaue dir $BA nochmal an. Nun sollte 8 drin stehen.

    Jetzt rife INFO auf, schreibe was rein und C=Q + ENTER. Wieder INFO starten. Steht nun ein Text drin? Gibt es ein File MEMO.TXT auf Disk 8?


    P.S. Was sagt DS$?


    Danke für deine Hilfe.

    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!

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