Hello, Guest the thread was called6.4k times and contains 183 replays

last post from dg5kr at the

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

  • Ich habe da mal eine vielleicht dumme Frage. Es gibt das Basic 4.5 als PRG und als CRT Datei, ist es grundsätzlich auch möglich das Basic 3.5 ROM auszutauschen oder das File im Reprom64 zu benutzen? Dann hätte die Funktion im Reprom64 das Basic umzuschalten auch einen Sinn.

  • Ich habe da mal eine vielleicht dumme Frage. Es gibt das Basic 4.5 als PRG und als CRT Datei, ist es grundsätzlich auch möglich das Basic 3.5 ROM auszutauschen oder das File im Reprom64 zu benutzen? Dann hätte die Funktion im Reprom64 das Basic umzuschalten auch einen Sinn.

    Nein, nein, die Frage ist auf keine Fall dumm. Ich hoffe nur dich richtig verstanden zu haben. BASIC 4.5 gibts als PRG und als CRT.

    Du nutzt das REPROM64 damit du auf Knopfdruck verschiede ROMs nutzen kannst. Soweit ist alles klar. Nun kommt es. Möchtest du das BASIC 3.5 aus dem BASIC 4.5 haben, also ein BASIC 4.5 - 3.5 = 1.5 ???

    Oder möchtest du BASIC 3.5 als ROM switchen mit BASIC 4.5 (wo 3.5 ja inkludiert ist)???


    Zur Erläuterung: BASIC 3.5, welches vom C16, PLUS4 kommt, wurde damals von Michael Schimek für den C64 geschrieben. Damit ist (rein für BASIC) eine kompatibiltät zum PLUS4 geschaffen. Der Autor wollte das reine BASIC Programme so auf dem PLUS4 und auf dem C64 lauffähig sind. Dies BASIC 3.5 habe ich mir geschnappt (weil ich damals das BASIC vom PLUS4 schon klasse fand) und mit weiteren Befehlen von mir erweitert. Daraus habe ich dann ein BASIC 4.5 gemacht. BASIC 4.5 ist sozusagen eine Symbiose aus dem damaligen BASIC 3.5 und meinen Erweiterungen.


    Eventuell kannst du deine Frage mit diesen Informationen nochmal umformulieren und dann hoffe ich Dir eine ausreichende Antwort geben zu können.

  • Mir stellt sich eigentlich von Anfang an die Frage warum du es BASIC 4.5 nennst, und nicht z.B. 3.7 oder 3.8.

    Immerhin hast du BASIC 3.5 (von den 264er Serie) als Vorlage genommen und nicht BASIC 4.0 (von den PETs).

    BASIC 3.6 ist von CBM schon 'belegt': es ist das BASIC vom CLCD (Commodore LCD Laptop).

  • Eventuell kannst du deine Frage mit diesen Informationen nochmal umformulieren und dann hoffe ich Dir eine ausreichende Antwort geben zu können.

    Ich habe das so verstanden dass er gerne eine (sagen wir mal) 8KB grosse ROM-Datei hätte, die das Basic-ROM des C64 ganz einfach optional ersetzen könnte. Ähnliches habe ich mich auch schonmal unterschwellig gefragt, im Zusammenhang mit Emulatoren um dort ein basic.rom File alternativ zu ersetzen. Es gibt ja etliche Alternativ-Kernals sowohl für Hardware als auch logischerweise dann einsetzbar in Emulatoren, aber so gut wie garkeine Basic-Alternativen als ROM. Das sind immer entweder Cartridges oder ladbare Programme.

  • Weil es von BASIC 4.0 keine C64 implementierung gibt. Von 3.5 sehr wohl.

    Was ist mit den BASIC 4.X Befele? sind die vorhanden?

    z.B. -> Append; Catalog; Concat; Dopen; Dclose; Go; Record; Redim??


    Es ist unerheblich ob 4.x für den C64er gab/gibt. Es geht um die Logik.

    In BASIC 4.5 sollten reine BASIC 4.0 Programme die keine Peeks und Pokes nutzen ablauffähig sein.

    Denn genau das war das Ziel beim BASIC 3.5 am C64er, es sollten BASIC 3.5 Programme vom C16/Plus 4 auf dem C64er laufen.

  • Also, wir müssen hier immer zwischen einer BASIC Erweiterung und einem alternativen BASIC-Kernel unterscheiden.

    Auch wenn bei mir das originale BASIC in das darunter liegende RAM kopiert wird um es bei Bedarf zu verändern ist es immer noch eine Erweiterung. Nämlich alles was über das BASIC V2.0 hinaus geht wird ja in einem weiteren Speicherbereich außerhalb der BASIC Kernel Adressen gelegt.

    Zur Übersicht des C64 Memory Map empfehle ich diese oder diese Seite. Der Basic Kernel liegt von $A000-$BFFF im ROM. Darunter (oder darüber, wie man es sieht) liegt auch der RAM.

    Es gibt ein Projekt m. e. das sich mit einem reinen BASIC-Kernel replacement beschäftig (irgendwo auf GitHub).

    Das ist aber keine BASIC Erweiterung. Erweiterung nutzen auch sehr stark bereits vorhandene BASIC V2 Routinen. Aber es sind eben Erweiterungen zu dem vorhanden BASIC V2 und kein Ersatz.Warum auch neu schreiben. Ehrlich gesagt würdest du ein BASIC V2 und ein Simon Basic als Erweiterung gar nicht in die 8K BASIC Kernel unterbringen können.


    Ich hoffe das hilft weiter.

  • Es ist unerheblich ob 4.x für den C64er gab/gibt. Es geht um die Logik.

    Welche Logik? Erst Basic 2, dann Basic 4, dann Basic 3.5 und dann Basic 7. :whistling:

    Wenn du nachdenkst, siehst du schon die Logik dahinter.

    Außerdem laufen BASIC 2.0 Programme in alle 'höher Levelige' BASICs.

    Wobei 3.5 eh ein Sonderfall ist, weil es von vornherein ein ConsumerBASIC war/ist.

    Erst bei 7.0 wurde die 'Profi-BASIC (4.x) wieder mit dem Consumer-BASIC vereinigt.

  • Möchtest du das BASIC 3.5 aus dem BASIC 4.5 haben, also ein BASIC 4.5 - 3.5 = 1.5 ???

    Oder möchtest du BASIC 3.5 als ROM switchen mit BASIC 4.5 (wo 3.5 ja inkludiert ist)???

    Ich bin auch doof. Der Cevi hat doch Basic 2.0 und der C16 das Basic 3.5. Mein Vorhaben war eigentlich zwischen dem Ur 2.0 und dem super duper 4.5 umschalten zu können, auch wenn 4.5 abwärtskompatibel ist.


    Ich habe das so verstanden dass er gerne eine (sagen wir mal) 8KB grosse ROM-Datei hätte, die das Basic-ROM des C64 ganz einfach optional ersetzen könnte.

    Ja, genau richtig. So meinte ich das.


    Also, wir müssen hier immer zwischen einer BASIC Erweiterung und einem alternativen BASIC-Kernel unterscheiden.

    Aha, das beantwortet dann glaube ich auch meine Frage. Basic 2.0 ist ein Kernal Basic und als ROM auf das Board gesteckt. Basic 3.5 und 4.5 sind lediglich Add Ons für 2.0 und daher nicht Stand alone ausführbar. Es ist also nicht möglich ein 8K ROM mit Basic 4.5 aufs Board zu proppen, wahrscheinlich auch bedingt bzw. begrenzt durch die nur 8K die zur Verfügug stehen.

  • Bobbel Mann sollte auch nicht vergessen daß die 264ern eine vollkommen andere Bankswitch-System haben als der C64.

    Immerhin hat der +4 60671 Basic Bytes Free, und unter dem Optionalen BASIC 7.0 (jawohl das gibts für den +4) 51199 Bytes Free hat.


    Auch wenn manch einer es anders sieht: Das BASIC ist bei ALLE CBM-Computern nur ein Programm. Nur der Kernal ist das OS der CBM-Rechner (mit Hilfe vom DOS in den 'intelligenten' Laufwerke). Es wurde aber mit Betriebssystemfunktionen, besser gesagt mit ein minimal CLI (auch bekannt als Direct-Modus) aufgepeppt.

    Schaffst du es das BASIC 3.x komplett (also inklusiv den BASIC 2.0 Anteil) in ein Bankswitch-System die der C64er Beherrst zu pressen, dann fluppt dat auch auf dem Cevi.

    Andere Programme die der +4 so im ROM hat sind der 'Monitor' (wie beim C128) und die 3+1 Software. Das alles geht dort wegen des anderen Bank-Switching.

    Siehe dazu auch -> http://amigos.amiga.hu/plus4/plus4/basic7.htm und http://blog.c128.net/archives/26

  • Freddy

    Danke für die Erklärung. Schade das das nicht so einfach ist. Mein erster Rechner war ein C16 mit Datasette. Mein Bruder und ich sind damals fleißig in Basic am Programmieren gewesen, daher wäre das ein nettes Gimmick das Basic auf dem 64 Laufen zu lassen. Davon ab frage ich mich immer noch wofür man beim Reprom64 ein alternatives Basic ansteuern kann.

  • Freddy

    Danke für die Erklärung. Schade das das nicht so einfach ist. Mein erster Rechner war ein C16 mit Datasette. Mein Bruder und ich sind damals fleißig in Basic am Programmieren gewesen, daher wäre das ein nettes Gimmick das Basic auf dem 64 Laufen zu lassen. Davon ab frage ich mich immer noch wofür man beim Reprom64 ein alternatives Basic ansteuern kann.

    Die Lösung ginge wohl nur über ein Modul am Expansion Port.

  • Drauf wetten würde ich nicht... Es bestünde eine Restchance, dass ein Ansatz wie beim Superkernal (jedoch für das Basic) es tun könnte. Beim Superkernal wird das Bankswitching (in diesem Fall zum Menü bzw. anderen Kernal) ja, sowie tbekannt, dadurch ausgelöst, dass bestimmte Adressen in bestimmter Reihenfolge gelesen werden (beim Einlesen der Opcodes, die dann ausgeführt werden).


    Freilich wird sich eher kaum jemand finden, der das umsetzt. Aber machbar dürfte das so sein.

  • Drauf wetten würde ich nicht... Es bestünde eine Restchance, dass ein Ansatz wie beim Superkernal (jedoch für das Basic) es tun könnte. Beim Superkernal wird das Bankswitching (in diesem Fall zum Menü bzw. anderen Kernal) ja, sowie tbekannt, dadurch ausgelöst, dass bestimmte Adressen in bestimmter Reihenfolge gelesen werden (beim Einlesen der Opcodes, die dann ausgeführt werden).


    Freilich wird sich eher kaum jemand finden, der das umsetzt. Aber machbar dürfte das so sein.

    Machbar schon, aber genau wie du sagst: WER tut sich das an???

    Dafür ist der Bedarf viel zu klein.

  • Drauf wetten würde ich nicht... Es bestünde eine Restchance, dass ein Ansatz wie beim Superkernal (jedoch für das Basic) es tun könnte. Beim Superkernal wird das Bankswitching (in diesem Fall zum Menü bzw. anderen Kernal) ja, sowie tbekannt, dadurch ausgelöst, dass bestimmte Adressen in bestimmter Reihenfolge gelesen werden (beim Einlesen der Opcodes, die dann ausgeführt werden).


    Freilich wird sich eher kaum jemand finden, der das umsetzt. Aber machbar dürfte das so sein.

    Naja, man kann ja den Kernal-Bereich auch fürs BASIC verwenden. Es wird auch jetzt schon E000 bis E400 von BASIC verwendet. Da könnte ich mir schon vorstellen, dass man auf mehrere Kernel-Images für E000 bis FFFF eine BASIC-Erweiterung einpflanzt, die da zwischen den Teilen hin und her schaltet, eventuell so weit gehend, dass das alte BASIC-ROM gar nicht verwendet wird, wenn man eine Bankswitching-Reimplementierung des BASICv2-Teils anpeilt (um möglichst viel von den 64 KByte RAM zu nutzen). Ist natürlich auch supermühsam, wenn ich an das Herumschalten denke und die Anordnung der Codeteile, sodass die richtigen Teile in einem ROM-Teil drinnen sind samt aller Nebeneffekte mit IRQ und NMI.

    So elegant wie bei der 264er-Architektur, wo das gesamte ROM in einem Stück eingeblendet ist, ist es freilich dann nicht mehr.

  • Hmmm, laß mal überlegen. Ich habe mich ja mit meinem Displatcher noch VOR dem BASIC 3.5 gehangen. Wird ein Token von mir erkannt, wird es ausgeführt und dann springe ich, da hast du recht, unnötigerweise zum BAISC 3.5 Parser. Besser wäre es hier in den ......Ja, wo springe ich den eigentlich hin??


    Im Parser würde ich den "JMP MeinBefehl" in einen "JSR MeinBefehl" ändern dann geht der Rücksprung in den Parser. Von dort aus würde ich dann irgendwo hinspringen, aber wo?

    Im READY Modus? ($A7AE)

    Ich hab's hier nicht explizit angeführt ...

    Wir brauchen hier zusätzlich

    1. Den Einsprungspunkt des BASIC35-Dispatchers nach dem 1. CHRGET

    2. Den Einsprungspunkt des BASIC35-Dispatchers für ein unbekanntes Token (oder die entsprechende Fehlerroutine)

    3. Den Einsprungspunkt mit dem Start der Interpreterschleife. Das kann meines Erachtens ruhig die ROM-Routine sein,

    den die geht ohnehin über den $3xx-Hook und führt dann zur BASIC35-Routine.

    aber richtig, es sollte A7AE sein.


    Ich glaube es wäre ein ticken schneller wenn ich nach Abschluss meine Befehls Routine nicht zum Dispatcher zurück kehre, sondern am Ende der Befehlsroutine nach A7AE springe, oder?

    Würde ich nicht machen. Das wird ja in meinem Beispiel ja schon recht elegant gelöst:

    Damit kann man alle Kommandos mit RTS enden lassen (spart 2 Bytes in jedem Befehl) und hier im Beispiel noch einmal die Empfehlung das erste CHRGET vor dem Aufruf des Befehls aufzurufen und alle Befehle - falls notwendig - mit CHRGOT starten lassen. ABER: Mit einer CMP-Kaskade geht der Status vom CHRGET verloren (die Tabellen-Variante hat das Problem nicht), daher der Ansatz oben gezeigt mit php/plp. ;)


    Oder man macht es so wie im ROM, dass man ein JSR für die Rücksprungadresse verwendet und in den Befehl hineinverlängert, der mit RTS

    wieder zurück kommt ...

  • Außerdem müssen die 'Kernfunktionen' des Kernals immer da sein.

    Die 'Konsole', DOS-Schnittstelle zu den Laufwerken, usw....

    Genau das meinte ich mit Gruppieren der Codeteile. BASIC-Befehle den den Kernal brauchen, haben im die Routinen mit eingeblendet, jene, die nicht so auf den Kernal angewiesen sind brauchen nur die IRQ/NMI-relevanten Teile. D.h. man hat X Kernal-Images, wo mehr oder weniger Kernal drinnen ist (und demnach auch mehrfach vorkommt) über die dann das BASIC verteilt ist. Ich weiß, klingt ziemlich wackelig - ich glaub es auch erst, wenn ich es funktionierend sehen würde. ;)
    Kann der Super-Kernal auch mehr ROM als E000 bis FFFF gleichzeitig einblenden?

  • Nee. Wie auch, er sitzt ausschließlich im Steckplatz für den Kernal auf der C64 Platine.

    Und für den User ist eine Umschaltung auch gar nicht vorgesehen - und auch nicht dokumentiert.

    Und ich fürchte (ohne es zu wissen), dass man immer über den fest integrierten Menükernal gehen muss... Mit dem Superkernal gäbe es daher vermutlich große Probleme, so etwas hinzubekommen.