Würde ich nicht machen. Das wird ja in meinem Beispiel ja schon recht elegant gelöst:
Ja, ich gib zu die Lösung hat Charme. Obwohl sie beim ersten hinsehen nicht zu durchschauen ist und ich ja trotz aller Bytes-Sparerei ein Freund des Gradlinien, Step-by-Step Lösungen bin. Aber ich muß sagen, das find ich sehr charmant. Auch deine Empfehlung den Dispatcher immer mit dem ersten Zeichen nach dem Token zu verlassen macht die Auswertung eventueller Parameter einfacher und das wiederherstellen des CHR-Pointers wird größtenteils nicht mehr notwendig sein.
Also: dann lasse ich mal "die Finger fliegen" und schreibe den Code um. Wird was dauern, werds aber hier zu Schau stellen.
Hallo Besucher, der Thread wurde 58k mal aufgerufen und enthält 397 Antworten
letzter Beitrag von Boulderdash64 am
BASIC 4.5 für den C64 (BASIC 3.5 + EIGENE BEFEHLE)
- dg5kr
- Erledigt
-
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.
Also Leute, ich weiß gar nicht worüber ihr euch den Kopf zerbrecht. Wir reden hier über einen "Namen" eines Stück Softwares. Ich hätte das Ding auch "BASIC 56.1" oder "Roberts BASIC" oder "JOSEF" nennen können und dürfen. Ich arbeite doch nicht bei CBM im Marketing und muß mir Gedanken machen ob die Versionierung sich gut verkauft oder zu vorgänger Versionen passt (wo es ja noch nicht mal einen Vorgänger gibt). Also ich ich diskutiere seit vielen Tagen in diesem Thread mit einigen Usern wie man einen BASIC Extender (also BASIC 4.5) praktisch umsetzt und das auf einem richtig hohem Niveau. Und dann kommt ihr und meckert über eine "4.5"? Da fehlen mir echt die Worte.
-
Hi
Also mir ist es persönlich egal wie die Basicerweiterung heist, sie ist bis jetzt sehr gut und ich freue mich darauf wenn sie komplett fertig ist.
-
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.
Also Leute, ich weiß gar nicht worüber ihr euch den Kopf zerbrecht. Wir reden hier über einen "Namen" eines Stück Softwares. Ich hätte das Ding auch "BASIC 56.1" oder "Roberts BASIC" oder "JOSEF" nennen können und dürfen. Ich arbeite doch nicht bei CBM im Marketing und muß mir Gedanken machen ob die Versionierung sich gut verkauft oder zu vorgänger Versionen passt (wo es ja noch nicht mal einen Vorgänger gibt). Also ich ich diskutiere seit vielen Tagen in diesem Thread mit einigen Usern wie man einen BASIC Extender (also BASIC 4.5) praktisch umsetzt und das auf einem richtig hohem Niveau. Und dann kommt ihr und meckert über eine "4.5"? Da fehlen mir echt die Worte.
Das liegt daran, daß BASIC 4.5 sich namentlich einreit in die CBMs BASICs.
Btw.: Intern war CBM bei BASIC 4.75.
Roberts BASIC hätte ich nicht 'beanstandet' als Namen.
Warum ich BASIC 4.5 für falsch halte habe ich bereits gesagt, und dabei bleibe ich.
Trotzdem ist das eine gute Arbeit den du da ablieferst, hat aber mit deine Erweiterungen den CBM-Pfad verlassen.
-
Trotzdem ist das eine gute Arbeit den du da ablieferst, hat aber mit deine Erweiterungen den CBM-Pfad verlassen.
Danke
-
Also Leute, ich weiß gar nicht worüber ihr euch den Kopf zerbrecht.
Ja, das ist wirklich nebensächlich. Dennoch, gerade Namen - nicht nur bei Software - können einfach unglücklich ausfallen und/oder falsche Assoziationen wecken.
Da kann man über Hinweise anderer, die auch andere Sichtweisen haben, eigentlich nur froh sein (also als positiven Impuls sehen). So eine Namenswahl ist ja schließlich auch nichts, was man bis aufs Blut verteidigen müsste. Wie bei allem mit unterschiedlichen Meinungen und Zugängen zu einem Thema, kann man freilich diese auch stehen lassen oder ein Raider-heißt-nun-Twix-Manöver machen. Nur bloß nicht viel drüber herumdiskutieren....
-
Da kann man über Hinweise anderer, die auch andere Sichtweisen haben, eigentlich nur froh sein (also als positiven Impuls sehen).
Einerseits... ja.
Andererseits kann man nach dem Lesen einer gewissen Anzahl von Beiträgen auch einfach mal die Nutzer X, Y und Z gedanklich als Trollaccounts oder Rauschgeneratoren abhaken.
-
User JeeK hat sich die Mühe gemacht und meinen Dispatcher unter die Lupe genommen. Dabei hat er nicht nur "Hausputz" vorgenommen, sondern auch einen Vorschlag statt einen Token-Abfragekette eine Speichertabelle als Einsprungadressen für die Befehl anzuwenden. Diese Methode ist nicht sofort zu durchschauen, aber sehr effizient. Also habe ich den Code um geschrieben.
An einer Stelle mußte ich die Syntax des Sourcecode formal ändern, weil im C64 Studio wohl kleine Abweichungen zum ACME sind.
Aus
lda (_jump_tab-2)+1,y ; Sprungadresse High
pha
lda (_jump_tab-2),y ; Sprungadresse Low
pha
musste ich
lda _jump_tab-1,y ; Sprungadresse High
pha
lda _jump_tab-2,y ; Sprungadresse Low
pha
machen. Was ja kein Problem darstellt.
Allerdings hat dieser Teil am Anfang der Routine:
Code- jsr CHRGET ;wir holen ein zeichen
- php
- cmp #$7f ;und vergleichen es mit unserem master-token
- beq _chk ;haben wir es gefunden so machen wir weiter
- plp
- jmp B45_PTR_EXE_STATM_AFTER_CHRGET
- _chk plp
- jsr CHRGET ;wir holen noch ein zeichen, da wir ja das master-token gefunden haben
- ;brauchen wir nicht mehr pruefen ob wir ein slave-token haben
Nicht die gewünschte Wirkung gezeigt. Das heißt das alle Token, die KEINE BASIC4.5 Token sind sollen ja vom BASIC 3.5 Parser verarbeitet werden. Der macht aber ein Syntax Error weil mit dem obigen CHRGET nicht mehr das Befehl Token im Pointer steht, sondern das darauf folgende. Das ändert auch nichts daran, das der Prozessor Status gerettet und wieder hergestellt wird.
Weiter nützt der Sprung B45_PTR_EXE_STATM_AFTER_CHRGET nichts, da ja aktuell nicht mehr ein Befehltoken da ist. Bestenfalls ei Paramter. Wenn also das Token kein 7F als Mastertoken ist, muss der alte CHR Pointer wieder hergestellt werden. Ich habe den Beginn der Routine dahin gehen geändert:
Alles anzeigenCode- MYDISPATCH lda CHRPTR ;wir speichern den CHRGET pointer
- sta OLD_CHRPTR
- lda CHRPTR+1
- sta OLD_CHRPTR+1
- ;------------------------------------------------------------------------------
- jsr CHRGET ;wir holen ein zeichen
- php
- cmp #$7f ;und vergleichen es mit unserem master-token
- beq _chk ;haben wir es gefunden so machen wir weiter
- ;------------------------------------------------------------------------------
- lda OLD_CHRPTR ;wenn wir das master-token nicht gefunden haben landen wir hier
- sta CHRPTR ;und stellen den chrget pointer wieder her
- lda OLD_CHRPTR+1 ;da sonst der PARSER mist baut
- sta CHRPTR+1
- plp
- jmp (B35_PTR_EXE_STATM) ;Zum BASIC 3.5 Parser
- ;------------------------------------------------------------------------------
- _chk plp
- jsr CHRGET ;wir holen noch ein zeichen, da wir ja das master-token gefunden haben
- ;brauchen wir nicht mehr pruefen ob wir ein slave-token haben
- cmp #$0D ; höchste Sub-Tokennummer+1
- bcc _jump_cmd ; wenn kleiner, dann zum Kommando
- jmp INTERPRET
Gleichzeitig habe ich dann die Empfohlene Weise, alle Befehls Routinen mit einen CHRGOT (statt wie bisher mit CHRGET) zu beginnen, weil die Befehls Token (7F und 01-0C) bereits abgehandelt wurden.
Das Trickreichste allerding ist der Rücksprung der Befehlsroutinen. Die gingen bisher über einen JMP (Vector nach Basic 3.5 Parser).
Aber in dem ich mit
; Kommando kommt mit RTS in die Interpreterschleife zurück
lda #>(INTERPRETER_SCHLEIFE-1)
pha ; High-Byte
lda #<(INTERPRETER_SCHLEIFE-1)
pha ; Low-Byte am Stack
Die Einsprungadresse des Parsers auf den Stack lege würde ein einfaches RTS dann genau dort hin springen. Was es auch tut
Somit genügt es die Befehlroutinen mit RTS zu verlassen. Genial! Großen Respekt und Dank an JeeK.
Habe den Dispatcher als Anlage mit dran gehangen.
-
Nicht die gewünschte Wirkung gezeigt. Das heißt das alle Token, die KEINE BASIC4.5 Token sind sollen ja vom BASIC 3.5 Parser verarbeitet werden. Der macht aber ein Syntax Error weil mit dem obigen CHRGET nicht mehr das Befehl Token im Pointer steht, sondern das darauf folgende. Das ändert auch nichts daran, das der Prozessor Status gerettet und wieder hergestellt wird.
Ja, welchen Eingesprungspunkt verwendest du für B45_PTR_EXE_STATM_AFTER_CHRGET? Die Interpreterroutine von BASIC35 ist leider nicht so einfach, dass man da quer einspringen kann, weil am Anfrang eine Statuserhebung gemacht wird, die später abgefragt wird:
Da kann man leider nicht einfach nach C3AA springen.
Dort wird nämlich das High-Byte von CHRGET-Zeigers abgefragt, ob er sich <$300, d.h. im Direktmodus läuft. Das wird in Bit 7 von $E9 vermerkt.
Das müsste man also herausziehen und du in deiner Routine ergänzen (also von C3A1 bis C3A5) bevor du zu C3AA springst.
Das ist irgendwie nicht schön. Daher ist das mit dem CHRGET-Zeiger retten und wiederherstellen eigentlich auch eleganter. Was mir dabei nicht so gefällt, der Zwischenspeicher irgendwo mitten im Code des Dispatchers liegt. Wenn ich an ROM-fähigen Code denke (und darauf achte ich immer, egal ob ich vorhabe daraus ein ROM zu machen oder nicht), dann würde das so nicht funktionieren. Rein vom Design hätte ich vorgeschlagen entweder
- irgendwelche für diesen kurzen Zeitraum verwendbare Speicherstellen in Zeropage bzw. < $0400 zu nehmen oder
- das nur am Stack zu retten oder
- einen gesonderten Variablenbereich zu definieren, der leicht vom Codeteil (ev. im ROM) abgetrennt werden kann.
Die Stack-Variante könnte so aussehen:
Alles anzeigenCode- MYDISPATCH lda CHRPTR ;wir speichern den CHRGET pointer
- pha
- lda CHRPTR+1
- pha
- ;------------------------------------------------------------------------------
- jsr CHRGET ;wir holen ein zeichen
- cmp #$7f ;und vergleichen es mit unserem master-token
- beq _chk ;haben wir es gefunden so machen wir weiter
- ;------------------------------------------------------------------------------
- pla ;wenn wir das master-token nicht gefunden haben landen wir hier
- sta CHRPTR+1 ;und stellen den chrget pointer wieder her
- pla ;da sonst der PARSER mist baut
- sta CHRPTR ;vom Stack wiederherstellen (Reihenfolge beachten!)
- jmp (B35_PTR_EXE_STATM) ;Zum BASIC 3.5 Parser
- ;------------------------------------------------------------------------------
- _chk
- pla ; aufhobenen CHRGET-Zeiger verwerfen
- pla
- jsr CHRGET ;wir holen noch ein zeichen, da wir ja das master-token gefunden haben
- ;brauchen wir nicht mehr pruefen ob wir ein slave-token haben
- cmp #$0D ; höchste Sub-Tokennummer+1
- bcc _jump_cmd ; wenn kleiner, dann zum Kommando
- jmp INTERPRET
Weiter nützt der Sprung B45_PTR_EXE_STATM_AFTER_CHRGET nichts, da ja aktuell nicht mehr ein Befehltoken da ist. Bestenfalls ei Paramter. Wenn also das Token kein 7F als Mastertoken ist, muss der alte CHR Pointer wieder hergestellt werden. Ich habe den Beginn der Routine dahin gehen geändert:
Siehe auch Frage oben von mir. Der Sprung nach B45_PTR_EXE_STATM_AFTER_CHRGET würde schon was nützen, wenn er denn der richtige ist und die Voraussetzungen (siehe auch oben) geschaffen sind.
Aber ich gebe zu, ich hab das nicht alles selbst getestet, sondern nur zusammengestellt, wie ich es machen würde (aus meinen Erfahrungen).Übrigens: In deiner obigen Variante brauchst man das PHP und PLP dann aber nicht mehr. Einfach weglassen bzw. siehe mein Beispiel des Dispatchers mit der Stack-Rettungsvariante.
-
Ich habe den Code nun soweit umgeschrieben, das er auch auf einem EPROM gebrannt lauffähig sein sollte.
Alle variablen Speicherstellen (nicht die TEXT-Konstanten), die mit irgendwelchen temporären Bits gefüllt werden liegen nun im RAM. Dabei wird der Kassettenpuffer reichlich genutzt. Das heißt die Datasette kann nicht mehr genutzt werden, was wohl kaum noch der Fall ist.
Weiter habe ich mir überlegt das es unsinn ist für jede Routine exclusiven Speicher für zwischen Infos bereit zu stellen. Deshalb habe ich Speicherstellen als allegemeine Tabelle normiert. Diese Normierten Namen der Speicherstellen können dann im jeweiligen Code mit sprechenden Namen wieder zugewiesen werden.
Also in etwar so:
Alles anzeigenCode- ;==============================================================================
- ;Allgemein nutzbare Zwischenspeicher für Disk und Text operationen
- ;Diese Bereich hat alle Variablen Speicherstellen, die sich zur Laufzeit ändern
- ;Falls das Programm in ein ROM gebrannt wird MUSS dieser Bereich im RAM liegen
- ;==============================================================================
- ;--------------|--------|--------------|---------------------------------------
- ;80Byte Textpuffer für unverselle Zwecke
- ;$33C - $3FB 828 - 1019 Datasetten-/Kassettenpuffer (192 Byte)
- TEXTBUFFER = $033C
- TEXTBUFFERLEN = $03FF
- ;--------------------------------------------------------------------------------
- ;--------------|--------|--------------|---------------------------------------
- B35_PTR_TOKENIZER = $02A7 ;save the BASIC V3.5 Vector Lo
- ;B35_PTR_TOKENIZER+1 = $02A8 ;save the BASIC V3.5 Vector Hi
- B35_PTR_KLARTEXTER = $02A9 ;save the BASIC V3.5 Vector Lo
- ;B35_PTR_KLARTEXTER+1 = $02AA ;save the BASIC V3.5 Vector Hi
- B35_PTR_EXE_STATM = $02AB ;save the BASIC V3.5 Vector Lo
- ;B35_PTR_EXE_STATM+1 = $02AC ;save the BASIC V3.5 Vector Hi
- B35_PTR_ISR = $02AD ;save the BASIC V3.5 Vector Lo
- ;B35_PTR_ISR+1 = $02AE ;save the BASIC V3.5 Vector Hi
- ;--------------------------------------------------------------------------------
- ;--------------|--------|--------------|---------------------------------------
- ;Allzweck Varablen - Speicher - WORD
- VW01 = $02AF
- ;VW01+1 = $02B0
- VW02 = $02B1
- ;VW02+1 = $02B2
- VW03 = $02B3
- ;VW03+1 = $02B4
- VW04 = $02B5
- ;VW04+1 = $02B6
- ;Allzweck Varablen - Speicher - BYTES
- VB01 = $02A2
- VB02 = $02A3
- VB03 = $02A4
- VB04 = $02B7
- VB05 = $02B8
- VB06 = $02B9
- VB07 = $02BA
- VB08 = $02BB
- VB09 = $02BC
- VB10 = $02BD
- VB11 = $02BE
- VB12 = $02BF
- ;------------------------------------------------------------------------------
Und genutzt werden kann es so:
Langsam wird BASIC 4.5 erwachsen
-
Anbei die neuste BASIC 4.5 Version.
Vielen Dank für deine Mühen und die stetige Weiterentwicklung an der BASIC 4.5-Erweiterung!
Ich habe heute mal deine Erweiterung im C64-Modus des Mega65 (C65) ausprobiert und hier einen Beitrag dazu geschrieben:
Es lauft wirklich prima und sogar mit mehr freien Speicher als am C64.
Edit: Der freie Speicher ist gleich dem des C64. Es war (leider) nur irgendein Seiteneffekt nach dem Start (siehe auch hier).
-
Ich habe gestern mal Pegasus Basic V4.0 ausprobiert.
U.a. fand ich hier den MEM-Befehl recht aussagekräftig, da jeweils auch die belegten Speicherbereiche angezeigt werden:
Vielleicht wäre es ja eine Idee, dies beim MEMORY-Befehl des BASIC 4.5 noch mit dazu zunehmen?
-
Oja, das finde ich auch
. Da stimme ich Dir zu. Die Ausgabe ist sehr ansprechend. Zack, - wieder ne Herausforderung. Danke für die Info. -
Ich habe gestern mal Pegasus Basic V4.0 ausprobiert.
Vielleicht wäre es ja eine Idee, dies beim MEMORY-Befehl des BASIC 4.5 noch mit dazu zunehmen?
Hallo Snoopy,
könnte Dir sowas gefallen?
Da meine Darstellung nicht im Businessmode ist, sondern klassisch "groß" wirkt es anders.
-
Da meine Darstellung nicht im Businessmode ist, sondern klassisch "groß" wirkt es anders.
Das ist doch glasklar ein Vorteil - denn dann funktioniert es in beiden Modi.
-
Alles anzeigen
Ich habe gestern mal Pegasus Basic V4.0 ausprobiert.
Vielleicht wäre es ja eine Idee, dies beim MEMORY-Befehl des BASIC 4.5 noch mit dazu zunehmen?
Hallo Snoopy,
könnte Dir sowas gefallen?
Da meine Darstellung nicht im Businessmode ist, sondern klassisch "groß" wirkt es anders.
Also mir gefällt deine Darstellung sehr gut!
Respekt für deine wirklich tolle Arbeit an dieser Erweiterung!
