Wie erstelle ich eine PRG-File mit einem Basic Programm so das es im Emulator geöffnet werden kann.
Verwende C# als Programmiersprache.
Es gibt 36 Antworten in diesem Thema, welches 5.867 mal aufgerufen wurde. Der letzte Beitrag (
Wie erstelle ich eine PRG-File mit einem Basic Programm so das es im Emulator geöffnet werden kann.
Verwende C# als Programmiersprache.
Wäre es nicht einfacher den BASIC Code mit Copy and Paste in VICE einzufügen und dann abzuspeichern ???
Bitte melde dich an, um diesen Link zu sehen.
ZitatFür die TXT->PRG Rückwandlung schreibt man
"petcat -w2 -o OUT.PRG -- IN.TXT".
... er verwendet C# als Programmiersprache. Da hilft Petcat nicht weiter.
Mir ist kein C# Compiler für den 6502 bekannt, mit dem das ggf. gehen würde, oder kann der CC65 Compiler das evtl. ?
Warum muss es denn C# sein? Und wenn es C# sein muss, kann man auch externe Programme wie petcat von einem C#-Programm aus aufrufen.
Wenn das nicht erwünscht ist, muss man zwangsläufig den Tokenizer in C# nachbauen, bzw. den entsprechenden Code im petcat-Quelltext kopieren und anpassen.
Wie sieht denn deine Vorlage-Datei aus?
Wenn es der BASIC-Code in einem String ist, entweder externe Aufrufe (petcat), oder lustig selber tokenisieren. Kannst dir das ja mal bei C64Studo angucken. Ist aber weder elegant, noch schön, noch lesbar.
(gelöscht)
Man kann das Programm auch im ASCII-Code erzeugen und per Copy und Paste in den Vice reinkopieren.
So erstelle ich meine Basic-Programme - mit dem Texteditor auf dem PC.
Solange man nicht weiß, was der Threadersteller wirklich vor hat, ist das alles Kaffeesatzlesen.
Mir ist kein C# Compiler für den 6502 bekannt, mit dem das ggf. gehen würde, oder kann der CC65 Compiler das evtl. ?
Mir ist überhaupt kein C# Compiler für den 6502 bekannt.
Sowas hätte ich gerne. Am besten noch mit .NET und JIT. ![]()
Mir ist überhaupt kein C# Compiler für den 6502 bekannt.
Sowas hätte ich gerne. Am besten noch mit .NET und JIT.
Warum nicht gleich mit Windows API ?
in einem anderen Thread hast Du ja auch nachgefragt, wie man eine *.prg-Datei mit einem Zeichensatz erstellt.
Genauso wie so eine Zeichensatzdatei hat auch ein *.prg mit einem BASIC-Programm drin die ersten zwei Bytes mit der Ladeadresse. Damit enden aber schon alle Gemeinsamkeiten. Während der Zeichensatz aus 256 Zeichen a 8 Bytes aufgebaut ist, hast Du bei einem BASIC-Programm eine komplizierte Datenstruktur mit einer verketteten Liste aus (Programm-)Zeilen, die dann auch noch tokenisiert sind. Die Routine dazu ist im BASIC-Interpreter drin, es haben aber schon einige Leutz das für's Cross-Entwickeln erfolgreich portiert, z.B. in das bereits erwähnte petcat.
Welche Programmiersprache Du außerhalb des zu emulierenden Rechners für die Unterstützung deiner Cross-Entwicklung hernimmt, ist mal so herzlich egal. Jeder hat da so seine bevorzugten Werkzeuge.
Wenn Du unbedingt einen Tokenizer in C# selbst schreiben willst, nur zu: schreib ein paar BASIC-Programme im Emu, speichere sie ab, und analysiere deren Inhalt mit einem Hex-Editor. Detailkenntnisse von 65xx-Code sind allerdings schon hilfreich, wenn Du zum Gegenchecken den Tokenizer im ROM als Referenz und zum analysieren hernimmst.
Viele Grüße,
Michael
Bevor mich jetzt alle Java Hasser steinigen...
Ich könnte auch noch einen Tokenizer eben in Java anbieten. Sollte aber auch recht leicht zu portieren sein. Im Moment kann dieser aber nur mit Basic Dialekten umgehen die nicht auch noch ein Präfix Token benötigen. Ich arbeite aber daran.
Ein Tokenizer in C# ist jetzt auch nicht so ein Problem. Kniffelig wird's natürlich, wenn man die ganzen Besonderheiten und Fehler des Commodore Tokenizer exakt nachbilden will. ![]()
Besonderheiten und Fehler
Besonderheiten, klar. Die Routine im ROM ist die Referenz. Aber auf welche Fehler sprichst Du an? Ich kann mir höchstens Fälle vorstellen, wo der Tokenizer ein auf den ersten Blick unerwartetes, letztendes aber doch stimmiges Ergebnis liefert, z.B. hier: "...:FORT=STOP:...", wo eben nicht "S TO P" sondern das Schlüsselwort "STOP" tokenisiert wird.
Das meinte ich mit Fehlern. Kann man natürlich auch "unerwartetes Ergebnis" nennen.
Selbstverständlich ist Commodore-Basic 100% fehlerfrei! Sorry, dass ich das in Zweifel gezogen hatte.
Sorry, dass ich das in Zweifel gezogen hatte.
Kein Grund sich zu entschuldigen.
Selbstverständlich ist Commodore-Basic 100% fehlerfrei!
Habe ich das hier behauptet? Ich habe dir lediglich eine Frage gestellt und bin dir sogar soweit entgegengekommen, daß ich die wahrscheinlich von dir gemeinte Eigenheit der "Spezifikation" vorweg benannt habe.
Das Ding im ROM ist nun mal ein "greedy" Parser, es werden keine Delimiter zur Begrenzung der Schlüsselworte links und rechts gefordert, von Variablennamen sind nur die ersten zwei Zeichen signifikant, was vom Gebrauch längerer Namen eher abrät wodurch auch die Wahrscheinlichkeit heruntergebracht wird, daß sich da irgendwo ein Schlüsselwort drin versteckt.
Du kannst die Routine ja gerne verbessern. Kriegst Du sie dann immer noch in die 8K des BASIC-ROMs rein? Bist Du sicher, daß die Erzwingung von Delimitern (im häufigsten Fall nutzlose, Speicher kostende Leerzeichen) der heißeste Wunsch von BASIC-Programmierern auf dem C64 ist?
Da bin ich ja jetzt beruhigt das bei meinem eingenen Tokenizer, dem vom C64Studio und bei PetCat das selbe herauskommt bei dem Beispiel.
Ihr scheint ja zu wissen, was der OP eigentlich fragen wollte. Wer kann es mir kurz erklären?
Das meinte ich mit Fehlern. Kann man natürlich auch "unerwartetes Ergebnis" nennen.
Selbstverständlich ist Commodore-Basic 100% fehlerfrei! Sorry, dass ich das in Zweifel gezogen hatte.
Es bringt doch nichts, jetzt einen C64-Tokenizer zu schreiben, der z.B. eine FOR-Schleife mit "S TO P" bilden kann. Dann lädst du das in einen C64, drückst dort noch mal die Eingabetaste, und schon hast du Müll.
Ein Fehler wäre es deswegen, wenn der Tokenizer NICHT vorrangig z.B. STOP tokenisieren würde. Da hilft auch keine bemühte Ironie. ![]()
Ihr scheint ja zu wissen, was der OP eigentlich fragen wollte. Wer kann es mir kurz erklären?
Das weiß wohl keiner. Deswegen hat sich die Diskussion ja verselbstständigt. Aber ist ja auch so ein interessantes Thema. ![]()
Es bringt doch nichts, jetzt einen C64-Tokenizer zu schreiben, der z.B. eine FOR-Schleife mit "S TO P" bilden kann. Dann lädst du das in einen C64, drückst dort noch mal die Eingabetaste, und schon hast du Müll.
Genau das habe ich doch geschrieben. In meinem ersten Beitrag zum Tokenizer. Bevor Mike den Inhalt meines Beitrags verdreht hat.
Bevor Mike den Inhalt meines Beitrags verdreht hat.
Verdreht habe ich deine Aussage in Bitte melde dich an, um diesen Link zu sehen. mal überhaupt nicht, sondern lediglich genauer nachgefragt.
Dann mit so rhetorischen Figuren wie:
Selbstverständlich ist Commodore-Basic 100% fehlerfrei!
anzukommen bringt uns hier auch nicht weiter.
Hast Du derweil eine Antwort auf meine Fragen am Ende von Bitte melde dich an, um diesen Link zu sehen. parat?