Beiträge von Endurion

    Soviele Dinge, die ich auch mal in den automatischen Build einbauen muss.... Doku online ist auch aktualisiert.

    Eine Suche wäre mal was. Es gibt natürlich die im Browser-Control eingebaute Suche (Ctrl-F), aber die sucht nur innerhalb der aktuellen Seite.

    Was aber bei den wichtigen Pseudo-Ops geht: Cursor auf das Schlüsselwort und F1 drücken (z.Bsp. !message, etc.)

    Dann musst du mir genau sagen, wie du vorgehst. Der Punkt, den ich behoben habe, war eigentlich in einer Utility-Funktion, die überall verwendet werden sollte.


    Ich hatte den Fehler beim Erstellen eines .d64 direkt aus einem .bas-File, wenn im Dateinamen Leerzeichen waren, wurden da Nullen draus. Wenn es bei dir noch nicht klappt, dann muss ich was übersehen haben.

    !message funktioniert so:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Da könnte man den Wert ausgeben lassen. Wie man es dann aber einliest...

    Auf jeden Fall machbar wäre im Assembly mit io.filesize arbeiten, und ein

    * = ...

    MEIN_START

    BASIC_SIZE = io.filesize( basic.prg )

    !if ( $0801 + BASIC_SIZE ) > MEIN_START {

    !warn "Achtung! BASIC überlappt ins Assembly!"

    }

    Du könntest mit !message die Adressen ausgeben lassen und dann irgendwie parsen.

    Was wird denn zuerst erstellt? Das Assembly?

    Du könntest ein Label für Start und Ende setzen, und das Assembly beim BASIC-Programm als Dependency konfigurieren (+ Symbole). Dann hast du in BASIC die Label-Werte im Zugriff.

    Das sieht z.Bsp. so aus:

    assembly_inc.asm wird als Dependency von basic.bas zuerst gebaut, das dabei gesetzte Label JUMP_ADDRESS ist dann in BASIC einsetzbar, wenn die Häkchen entsprechend gesetzt sind.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Etwas kniffliger wird das zeitgleiche Abprüfen, ob der Anfang des Assemblys mit BASIC überlappt.


    Eine Variante wäre im Assembly die File-Größe des (zuletzt) gebauten BASIC-PRGs für die Berechnung der Startadresse zu verwenden:
    Bitte melde dich an, um diesen Anhang zu sehen.


    Ist aber ein kleines bisschen Henne-Ei :D

    Das wird so denke ich nicht funktionieren. Eine SEQ-Datei ist WIMRE mehr oder weniger als eine binäre Datei zu betrachten. Da stehen ja nicht nur die Strings drin, die man reingeschrieben hat, sondern alles mögliche in ROM-internen Formaten.

    So etwas kann man nur schwer umsetzen, da man wissen muss, welche Variablen-Typen oder Werte in welcher Reihenfolge geschrieben wurden. War das jetzt eine Zahl? Ein CHR$(irgendwas) oder doch ein String?

    Vieles kann man vermutlich irgendwie richtig raten, aber es wäre doch ein Raten. Da ist es wahrscheinlich besser, mit dem Hex-Editor zu arbeiten.

    Was ist denn dein Ziel? Die Inhalte der SEQ-Datei anzupassen?

    @Bitte melde dich an, um diesen Link zu sehen. ich habe gelesen das C64 Studio auch Mega65 unterstützt. Wie ist der Fortschritt in dieser Richtung ?

    Inwiefern meinst du?

    Der Assembler kann das schon seit mehr als zwei Jahren, die diversen Editoren Grafik, Sprite, Charset unterstützen die erweiterten Modi direkt. Das Spiel Mega Sisters ist damit entstanden.

    Was fehlt dir denn?

    Ich meine, das war so. Die CPU kann mit den normalen Opcodes immer nur ein 64k-Fenster sehen.

    Man kann mit den speziellen 32-Bit-Opcodes Adressen >64k ansprechen bzw. auslesen, aber direkt anspringen ging WIMRE nicht.

    Vielleicht mal in den Mega65-Foren fragen, ob man Code >64k direkt ausführen kann und was man dabei berücksichtigen muss.

    Ich kann mir vorstellen, dass es ähnlich dem B-Register (mit dem man die Zeropage virtuell verschieben kann) auch was für den Code gibt.


    Jetzt muss ich aber auch gestehen, dass ich mich bei Mega Sisters da drum herum gedrückt habe. Der Code ist komplett in den untersten 64k, nur die Grafiken und Sprites sind in den höheren Bänken. Da muss man nur die Pointer entsprechend setzen, das klappt dann ganz gut.

    Der Absturz war natürlich durch das Rumschieben der PETSCII-Werte, da fehlten dann plötzlich eine Reihe. Das habe ich korrigiert. Dafür eine neue WIP-Version.

    Das mit dem Nicht-Einfügen der geschweiften Klammern kriege ich aber nicht nachgestellt, da brauche ich mehr Info:

    * Welches Tastatur-Layout benutzt du? DE, EN?

    * Mit welcher Tasten-Kombination fügst du die Klammern ein? (AltGR-7, AltGR-0, oder bei Englischem die direkte Taste, oder

    * Kannst du mir deine Key-Binding-Einstellungen hier anhängen? (File->Preferences->BASIC->Key Binding->Export this)

    So, jetzt müsste es eigentlich passen. Habe die Werte mit dem Symbol-Modus und VICE abgeglichen.

    Zusätzlich ist auch das Prefines-in-BASIC-Verwenden dabei. Es geht nicht alles, nur normale Symbole (ohne Wert, dann haben sie den Wert 1), oder rein numerische Symbole. Zur Verwendung einfach das Define in geschweifte Klammern setzen. Achtung, da die Groß/Klein-Schreibweise passen muss, empfiehlt es sich, die Predefines in Großbuchstaben zu schreiben.

    In der Config:

    ADRESSE = 49152

    In BASIC

    10 SYS {ADRESSE}


    Neue WIP-Version

    64erGrufti : Verflixte Aufmerksamkeit. Ich hatte schon angefangen, dann kamen wieder 10 andere Dinge an. Bin dabei!

    birko70: Geschwungene Klammern sollten sich eingeben lassen? Kommt evtl. ein BASIC-Key-Binding dazwischen?

    Aber das Auswerten scheint tatsächlich nicht zu greifen, ich glaube, das hatte ich nur für vererbte Labels von Assembler-Code eingebaut. Das muss ich für BASIC noch machen.

    Kostenlose SIDs am Eingang, jeder aber nur einen! Mehr Stunden pro Tag (30 statt 24 sollte passen)!

    Ich bin eigentlich immer rundum zufrieden, bin aber auch nur samstags vor Ort.