Assemblierproblem mit ACME

Es gibt 42 Antworten in diesem Thema, welches 9.526 mal aufgerufen wurde. Der letzte Beitrag (30. Juli 2016 um 00:09) ist von Mac Bacon.

  • Was soll er denn sonst machen? Eine Kopierroutine in den Code einsetzen?

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Ach und ich vergaß zu erwähnen: Am Anfang Deines Programms kommt dann

    .segment "BYTEBREAKER"

    .word $0801

    ; Basic-Header
    ...

    Damit setzt Du die Ladeadresse auf 0801. Deswegen auch das komische "0801-2" als Segment-Startaddresse im Linkerconfigfile: damit schaffst Du Platz für die 2 Bytes der Ladeadresse, die ja dann beim Laden verworfen werden).

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Und schließlich musst Du auch den Basic-Header selber erzeugen, z.B. so wie unten. Aber das weißt Du sicher schon, es fehlt nur im bisherigen Sourcecode.

    Code
    .word line2, 2016
        .byte $9e
        .byte <('0' + start .mod 10000 / 1000)
        .byte <('0' + start .mod  1000 /  100)
        .byte <('0' + start .mod   100 /   10)
        .byte <('0' + start .mod    10)
        .byte 0       ; end of line
    line2:
        .byte 0, 0    ; end of basic
    start:

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • @ Claus

    Super stark!
    Das Prg Generieren klappt super!
    Ich habe ein Test Prg gemacht das ein Pik Symbol nach $0400 schreibt es tut!

    Der Speicher ab $7f00 (ich muss dahin und nicht nach $1000 wie bei den meisten SIDs) ist voller Nullen ohne Kopiervorgang aber das ist ja normal. Bzw. Ich ziehe von $7f00 nochmal $7e ab um das richtige Offset zu bekommen wo der SID Code eigentlich losgeht für die IRQ Routine. Also $7e82 statt $7f00.

    Ich mache die nächste Zeit dann weiter. Erstmal Kopierroutine schreiben. Dann prüfen ob das Kopieren hinhaut. Dann die IRQ SID-Abspielroutine. Melde mich dann.

  • @ Claus

    Lieber Claus!

    Ich habe eine Kopierroutine geschrieben von der ich ich glaube dass sie korrekt arbeitet.

    • sid2.s mit Befehlszeile
      cl65 -o sid2.prg --start-addr $0810 -t c64 -C c64-asm.cfg sid2.s
      führt zu sid2.prg. Muss nach load 8,1 ausgeführt werden mit sys 2064. Tut. Ohne Kopierroutine, das macht alles cl65.
    • sid3.s mit Befehlszeile
      ca65 sid3.s
      ld65 -C byteb.cfg sid3.o
      führt zu demo.prg, was direkt per Run startbar ist. Der Beweis dass es geschieht ist das kleine Pik-Symbol das links oben ins Screen RAM geschrieben wird. Das Programm steigt aber aus sobald die SID-IRQ-Routine angesprungen wird und man endet im Ready Prompt bei gelöschtem BS (die Befehlsfolge die nach Beenden des Programms per Tastendruck vorgesehen ist).

    In beiden Prgs wird das SID-File an $7e82 kopiert ($2100 Bytes + $ff Bytes - + $ff, weil ld65 sagt, es sind 126 Bytes zu wenig Speicher) - also dann gleich $ff drauf, weil das SID-File größentechnisch durch $FF teilbar ist und es mir das Kopieren leicht macht.

    An den Screenshots im Zip-File sieht man, dass ich im Monitor beide Prgs nach Start miteinander verglichen habe, und zwar dahingehend ob meine Kopierroutine in sid3.s genau dasselbe macht wie die org und res Direktiven in sid2.s (und sid2.prg funktioniert sauber, daher Referenz). Das RAM scheint bei beiden Prgs identisch, ich habe jeweils die ersten ca, 1500 Bytes am Anfang und nochmal das Ende bei $9f82 verglichen. Beide RAMs sehen identisch aus.

    Das heißt, meine Kopierroutine läuft korrekt.

    Das Verhalten des C64 bei sid3.s hatte ich bei sid2.s auch - und zwar wenn ich bei sid2.s den Basic-Start bei $801 lasse statt auf $810 hochzusetzen. Dann verhält sich sid2.s wie sid3.s. Bei sid2.s muss ich nur in der Befehlszeile --start-addr ändern. Bei sid3.s habe ich keine Ahnung was ich tun muss. Ich habe in der byteb.cfg und in sid3.s zwar Änderungen versucht (.word $810 im Source, start = $810-2 in der cfg) aber das brachte nichts.

    Ich habe jetzt mal alles in ein Zip gepackt zur Ansicht.

    Ich muss eigentlich nur wissen wie ich bei ca65 auf die Art wie Du es mir beigebracht hast, die Basic-Zeile verändern muss auf $810. Dann muss die Demo.prg auch per Run startbar sein.

    Danke für Deine Bemühungen.

  • In 'demo.prg' ist die Speicherstelle $8182 genullt, also auf BRK. Wenn da ein $8d = STA drin ist, läufts. Woher das rührt, weiß ich aber (noch) nicht.

    EDIT: Es sind auch $8282, $8382, $8482 ff. genullt, also hängts doch irgendwie wohl an der Kopierschleife.

    EDIT2: Da fehlt ja auch immer ein Byte:


    Code
    .C:0824  A0 FF       LDY #$FF
    .C:0826  B1 FD       LDA ($FD),Y
    .C:0828  91 FB       STA ($FB),Y
    .C:082a  88          DEY
    .C:082b  D0 F9       BNE $0826

    -> LDY #$00 !!!

    Noch ein EDIT: Die Erhöhung vom Lo-Byte um $FF ist natürlich auch unschön/unnötig und dann noch ohne CLC.

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

    3 Mal editiert, zuletzt von Hexworx (24. Juli 2016 um 00:12)

  • OK das clc zu vergessen war Schlamperei.
    Der Basic Start ab $810 kam aus einem SID Abspiel Tutorial aus dem Web. Da stand einfach, $810 nehmen ohne nähere Begründung.

    Im Tutorial brauchte es keine Kopier Routine das passiert dort per *=$810 und Org $1000-$7e

    Ich wollte beim Kopieren $22 mal $ff = $21de Bytes übertragen als doppelte For Next Schleife mit x und y Register als Zähler. Da sind dann die $2100 bytes des sid files drin plus divisions rest dadurch dass der teiler $ff ist.

    Ich schau es morgen nochmal an.

  • Der Basic Start ab $810 kam aus einem SID Abspiel Tutorial aus dem Web. Da stand einfach, $810 nehmen ohne nähere Begründung.

    Das ist unter normalen Umständen die niedrigste verfügbare ASM-Einsprung-Adresse hinter der (einzigen) BASIC-Zeile (also $080d, nicht $0810).

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • @ Hexworx

    Toll analysiert. Du hast scheints gar nicht in den Quellcode geschaut sondern gleich in den Monitor.
    Es klappt so wie Du sagtest.
    Bei einem Rückwärtszähler 0 zu laden statt $ff habe ich anderswo schon oft gesehen. Nur jetzt, wo ich mir selber etwas ausgedacht habe, hatte ich nicht mehr dran gedacht.

    Das heißt:

    Jedes 256. Byte in der Kopierschleife wird ausgelassen, nämlich immer dasjenige, bei dem das aktuelle Offset $ff beträgt. Denn das Kopieren ging immer erst bei $ff-1 bei mir los.

    Das Verändern des Basic Starts von $801 auf $810 ist jetzt gar nicht mehr nötig. Ich weiß (noch) nicht warum. Ich will aber die Basic Zeile eigentlich nie anfassen, bzw. mich noch nicht um solche Verschiebungen kümmern, da hat MacBacon Recht, als Anfänger will ich erstmal in Assembler fitter werden.

    Anbei nochmal die Kopierroutine mit herausgekürzten unnötigen Schleifen und clc, aber immer noch mit adc $ff

    Es funktioniert auch mit dieser "gekürzten" Fassung.

  • Prima, dass es jetzt geht! Wie Hexworx schon gesagt hat, ist noch ein bisschen überflüssiger Code in der Kopierroutine. adc addiert einen Wert auf den Akku. Du lädst zwar Werte aus den Speicherstellen $fb und $fd und addierst 255 dazu, aber tust nichts mit dem Ergebnis in A. Wenn das einen Effekt haben soll, müsstest Du danach mit sta das Ergebnis irgendwo hinspeichern. Aber: Deine innere Schleife geht ja von 0 bis 255 (einschließlich). Du musst also ohnehin nicht 255, sondern 256 addieren, was dem Erhöhen des Hi-Bytes in $fc und $fe entspricht (bei gleichbleibendem Lo-Byte). Du kannst also das Laden und Addieren des Lo-Bytes einfach rausschmeißen.

    Außerdem ist am Ende Deiner inneren Schleife Y immer 0, also könntest Du am Ende statt nach copyouter auch nach copyinner branchen (macht aber keinen großen Unterschied).

    Den Basic-Teil musst Du eigentlich nie anfassen, der Sys-Befehl wird immer zum Label start zeigen, wo immer Du das auch hintust.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Danke Euch!

    Diese gute Förderung haben wahrscheinlich in den 80er Jahren nur ausgewählte Neu-Mitglieder in Demo und Cracker Gruppen bekommen und da hat man sich noch per Swapping Briefe und Päckchen geschickt.

    Wer solche Connections nicht hatte und kein Super Hirn war ist irgendwann stecken geblieben.

    Heute darf im Forum 64 jeder fragen und erhält auch noch Blitz artig eine gute Antwort.

  • Zur Vervollständigung, auch evtl. zum Lernen für andere Anfänger hier die zurechtgestutzte Kopierroutine mit eigentlich universaler Verwendbarkeit:

  • Das "clc" und das Label "copyouter" können noch raus. ;)
    Und beim "ldx #$22" würde ich noch als Kommentar anmerken: "Kopiert 34 Pages"

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • So, here it is. War zu spät Vorgänger-Beitrag zu editieren. Ist nun ein weiterer Source-Baustein den ich verwenden werde.

  • Perfekt! :thumbup:

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • hibyte:
    inc $fc ;Erhöht den INHALT der Speicherzelle $fc um 1
    inc $fe ;Erhöht den INHALT der Speicherzelle $fe um 1

    Sowas sollte man vermeiden, da der Kommentar nicht mehr aussagt, als der Befehl selbst.

    Dann besser so:

    Code
    hibyte:
    inc $fc ; Target Hi-Byte erhöhen
    inc $fe ; Source Hi-Byte erhöhen

    Insgesamt könnte das auch so aussehen:


    Ist zumindest mein aktueller 'Stil', um auch später noch durchzusteigen. 'nextstep2' ist eigentlich auch noch überflüssig. Schadet aber ja nicht.

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • So das wars. Ich konvertiere zu ACME. ca65 Bye Bye! CBM Prg Studio sowieso bye bye, ich bin da eh zu Shell-lastig.

    Habe mit Rasterbars experimentiert und mit ca65 die Aligns nicht hinbekommen. Fremde Sourcecodes sind gut auf ACME anpassbar es sind nur Kleinigkeiten (z.B. !align 255,0 statt .align 256 oder !align 256).

    SIDs einbauen geht mit ACME auch gut und es gibt viele Demoszene Beispiel-Sourcecodes die sich glatt in Prgs umbauen lassen.

    Also, ich konvertiere. Ca65, es war schön mit Dir, ciao.

    Jetzt muss ich nur noch die !text Direktive mit einer Übersetzungstabelle füttern. Mein Sterne- und Scrolltext-Intro ließ sich mit einem Schlag übersetzebn, nur der Petrscii Code fehlte.

  • Ja, ca65, der Cross Assembler. Für Demo-Programmierung scheint mir ACME im Moment den einfacherern Einstieg zu geben. Ich brauche nicht zwingend das Segmente-Prinzip zu verstehen und muss für Selbstverständlichkeiten (Align) mir nicht das Hirn zerbrechen wie das mit dem Cross Compiler nun geht oder nicht geht.

    Edit:

    Es war !scr
    Jetzt klappt auch der Text. Muss sagen, das sieht gut aus und eine MorphOS Version gibt es auch.