Hallo Besucher, der Thread wurde 2,2k mal aufgerufen und enthält 9 Antworten

letzter Beitrag von BlondMammuth am

Anfänger-Frage zu Vorwärtsreferenzen in ACME

    Halllo Alle,


    ich versuche mich grade an ACME, und habe folgendes Anfänger-Problem mit einem Code-Fragment:


    Code
    1. ..
    2. beq init
    3. ..
    4. .init ldy #20


    und bekomme als Fehlermeldung für diese Zeile 2:


    "Value not defined (init)."


    Kann mir jemand verraten, wie ich den ACME dazu kriege, Vorwärts-Referenzen aufzulösen? Mir würd auch der wortlose Hinweis auf ein Beispiel-File reichen. Nur aus den Infos, die ich online gefunden habe, habe ich es nicht rekonstruieren können.


    Danke in Voraus!

    Zeile 2:


    bne .init


    Der Punkt fehlt. Wenn denn das Label lokal sein soll. Ansonsten beides mal ohne Punkt.

    Zitat von BlondMammuth

    Mir würd auch der wortlose Hinweis auf ein Beispiel-File reichen. Nur aus den Infos, die ich online gefunden habe, habe ich es nicht rekonstruieren können.

    Die Datei "docs/QuickRef.txt" enthält ganz am Anfang ein Mini-Codebeispiel. Ich sollte allerdings wirklich mal mehr Praxisbeispiele ins "examples"-Verzeichnis werfen, z.B. ein gewisses Speichertestprogramm.

    Nachtrag, weil ich auch hierzu nichs finde (offenbar nicht gut genug gesucht, aber wie auch immer, ich schaffs nicht alleine): Ich möchte eine Zeropage-Indizierung per y verwenden, also konkret:


    Code
    1. LDY #A0
    2. loop LDA $0D,y
    3. STA $00,y
    4. INY
    5. BNE loop


    will ich mit dieser Schleife 96 bytes innerhalb der ZP hinauf schieben. Um elegant mit BNE abschliessen zu können, lasse ich den Zähler fürs lesen herum-wrappen, und zähle y nach oben.


    Ich komme drauf, dass diese Zugriffe nicht ZP-indiziert sondern absolut indiziert compiliert werden, dass also der Lesezugriff weit über die ZP hinausgreift, ganz und gar nicht in meinem Sinne.


    Somit gibt es zwei Möglichkeiten: Entweder es gibt gar keine ZP-indizierte Adressierung mit Y (wobei ich aus mehreren Büchern nicht so recht schlau geworden bin, die da irgendwie verwaschen daher fabulieren, unter anderem Rodnay Zaks Buch über den 6502), oder ACME will irgendwie sanft zu einer solchen überredet werden. Daher die Frage: Woran liegts, und WENN es diese Addressierung gibt, wie kitzle ich sie aus dem ACME raus?


    Danke vorerst!

    Mit ist noch nicht ganz klar, was Du in der ZP tun willst (Addressen 0 und 1 auf diese Weise zu überschreiben scheint mir gefährlich), aber Du erzwingst Addressing Modes in ACME durch hinzufügen von "+1" oder "+2" zum Mnemonic, also in Deinem Fall

    Code
    1. LDY #A0
    2. loop LDA+1 $0D,y
    3. STA+1 $00,y
    4. INY
    5. BNE loop

    Ob und warum ACME sich hier aber für absolute Adressierung entscheidet weiß ich nicht.


    EDIT: ach ne, Du fasst 0 und 1 ja gar nicht an :)

    Vielen Dank :dafuer: ! :winke:


    Ja, ich will eigentlich eine virtuelle Maschine basteln, die auf dem alten Ceh genauso läuft wie auf modernen Prozessoren (wo ich vermutlich eher auf C zurückgreifen werde, aber auf dem C64 muss ich optimieren, daher Assembler).


    Das Stückchen Code soll - wenn ein Teil des Stacks (32 bytes) woanders hin gerettet ist - den Rest (96 bytes) nach oben verschieben, und das Ganze soll stattfinden, wenn ein bestimmter Treshhold erreicht ist. Ich bin am überlegen, ob es besser wäre, die zu verschiebende Anzahl doch numerisch genauer zu umfassen, aber ich denke, das zahlt sich nicht aus. Ich müsste dann einen anderen Adressierungsmode verwenden, mehr vorbereiten, und das wegen ein paar Bytes hin oder her. Dann schon lieber eine konstante Menge.


    Was natürlich noch besser wäre: wenn ich den Stack wrappen könnte, also innerhalb der ZP nicht verschieben bräuchte, sondern nur weg retten. Allerdings sind die Zugriffs-Routinen dann so viel langsamer, dass wohl statistisch gesehen der Nachteil den Vorteil überwiegen würde.



    Nachtrag: LDA $00,Y ergibt eine "Illegal combination of command and postfix". Dasselbe mit ,X funktioniert jedoch. Offenbar hat ACME mir die Frage nach der Existenz dieser Adressierungsart bereits beantwortet. ;-)

    Holla, Mac Bacon hat natürlich recht! Mensch, diese Ausnahmen für selten verwendeten Adressierungsarten vergisst man doch leicht... :/