Beiträge von Bytebreaker im Thema „Assemblierproblem mit ACME“

    Mit ca65 war ich gezwungen, ein importiertes SID Stück von Hand umzukopieren. Die resultierende Exe war genauso groß wie das SID File plus Code.

    Acme erspart mir Dank *= und !Bin die Kopierarbeit, die Exe wird aber riesengroß weil mein SID File bei $7e82 im Speicher stehen muss.

    Würde ein Kopiervorgang unter ACME die Exe ebenfalls kleiner machen oder muss man halt mit großen Exe Dateien leben wenn man auf feste Startadressen angewiesen ist?

    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.

    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.

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

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

    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.

    @ 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.

    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.

    @ 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.

    @ 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.

    Klappen tut es nur mit

    .org
    .code

    (...)

    .res
    .incbin

    und man MUSS die Basic Zeile auf $810 setzen. Bei $801 klappt es nicht (siehe erste auskommentierte Zeile. Man startet dann mit sys 2064. Ich weiß nicht warum nur $810 klappt - das mit $810 stand in einem Tutorial für einen IRQ-gestützten SID-File-Player schon fest. Ich habe nur das SID-File, die Adressen im SID-File geändert und das Geschehen drumherum ergänzt.

    Der C64 spielt das Stück ab, wechselt die Rahmenfarbe (langsam) und es steht Text auf dem zuvor gelöschten Bildschirm - den ich mit einer eigenen Routine löschen muss, denn die ROM-Routine macht den IRQ (warum auch immer) kaputt.

    .segment und .incbin, wie es "fortschrittlich" sein muss, sind im Sourced auskommentiert weil ich nicht weiß wie ich es mit diesen Direktiven zum Laufen bringen soll.

    Edit:

    Hier Ulrich v. Bassewitzs Erklärung zum Incbin/Segment-Thema:


    Please note that it is your job to make sure the resulting data is loaded to$5000. Anything the linker will do for you is to relocate the data in thesegment named "SOUND" to the address $5000 and write it to the given file. Forexample, if you just have this segment in your config file, and then load theresulting binary to $1000, it won't work. While the linker can prepare thedata so it is able to run at the given address, it cannot load it to thataddress. The standard setup for the C64 is to load the generated program at$801 (the BASIC start). The linker is used to relocate the data for thisaddress, and the startup code will take all necessary steps to initialize allnecessary stuff so the program can run. If you want something special (likeloading something to $5000), you will have to do that yourself.


    Das Zitat ist verlinkt, da steht dann auch der Rest drin.

    ACME macht glaube ich das Einbinden von Binaries an bestimmten Adressen und das Starten des Basic Programms an anderen Stellen als $0801 angenehmer möglich als ca65.

    Da muss man nämlich gleich die Konfig File Keule rausholen und für den Linker Segmente definieren die leer bleiben wenn man nicht von Hand ein Binary kopiert. Incbin klappt dann nicht mehr. Das Segment Prinzip wird als überlegener Vorteil beschrieben obwohl man es mit org und res als Direktiven viel einfacher hat.

    Ich habe gerade meine Probleme damit ein nicht re allokierbares SID Stück mit ca65 dort einzubinden wo es hin muss. Das klappt bei mir nur mit res und org als Ausnahme die der ca65 Programmierer eigentlich nicht mag. Ich muss dann sys 2064 machen damit es klappt und warum es nur mit Adresse $810 aber nicht $801 geht ist mir auch schleierhaft.

    Mit Segment und incbin geht es gar nicht weil ich nicht weiß wie ich von Hand das Sid File kopieren muss. Incbin klappt nur an die Stelle wo ich im Source gerade bin. Das SID File will da aber nicht hin.

    Ich überlege daher den Cross Assembler zu wechseln weil er mir zu "fortschrittlich" ist.

    CBM Hardware's Weg klappt auch bei mir. Super, danke.
    Die Anweisung habe ich in einer Dosbox gestartet. Acme ist im Path, die ACME Lib in der ACME Umgebungsvariable.

    Edit:

    Die Code-Beispiele aus dem ACME Archiv (Intros, Demos) klappten alle von vornherein. Nur das C64 Wiki Beispiel wollte nicht.