exomizer - Unterschiede zwischen Windows- und Linux-Versionen

Es gibt 13 Antworten in diesem Thema, welches 3.473 mal aufgerufen wurde. Der letzte Beitrag (7. November 2015 um 16:29) ist von GI-Joe.

  • Mahlzeit !

    ich portiere gerade meine "make"-scripte für meine acme-Quellcodes von Windows nach Linux und da hab ich mich gleich mal an einer Stelle festgebissen ;(

    Der folgende exomizer-Aufruf funtioniert unter Windows einwandfrei, unter Linux gibts einen Syntax-Fehler

    Code
    exomizer sfx basic -t64 -s "lda#$00 sta$D015 sta$D020 sta$D021 sta$DBE7" -X "inc$D020 dec$D020" sourcefile.prg -o outputfile.prg


    unter Linux wird abgebrochen mit diesem Fehler:

    Code
    Phase 3: Generating output file
    ------------------------------
     Encoding: 1111334547770863,1012,1010234445566789,0120344455789ACF
     Length of crunched data: 36571 bytes.
     Target is self-decrunching C64 executable,
     basic start ($0801-$FFFF).
    line 742, syntax error, unexpected DIV
    Parse failure.

    Es liegt wohl an den Assembler-Fragmenten, denn wenn ich Die weg lasse, funzt exomizer erwartungsgemäß.
    Ich hab es mit exomizer 2.0.7 getestet - sowohl unter Windows als auch unter Linux.
    Hat hier Jemand mal einen heißen Tip auf Lager ?

    Viele Grüße,
    GI-Joe
    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. * 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.

  • Es liegt wohl an den Assembler-Fragmenten, denn wenn ich Die weg lasse, funzt exomizer erwartungsgemäß.

    :gahh: - die Lösung ist 'soooo einfach' gewesen ....

    Die Assembler-Fragmente müssen unter Linux zwingend in einfache:platsch: Hochkomma's gesetzt werden, dann zieht exomizer es sauber durch:

    Code
    exomizer sfx basic -t64 -s 'lda#$00 sta$D015 sta$D020 sta$D021 sta$DBE7' -X 'inc$D020 dec$D020' sourcefile.prg -o outputfile.prg


    Allerdings halte ich persönlich diese Lösung für unpraktisch, wenn man z.B. Assembler-Fragmente als Variablen mit einbauen möchte :S

    Viele Grüße,
    GI-Joe
    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. * 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.

  • die dollar sind ja variablen die deine shell/make ersetzt.
    schreibe ein backslash vor jedes dollar und alles ist gut.

    EDIT: oder nimm dezimalzahlen

  • die dollar sind ja variablen die deine shell/make ersetzt.
    schreibe ein backslash vor jedes dollar und alles ist gut.

    Danke für den Gedankananstoß :nuss:
    Ja, logisch - das $ is ja n Token der Linux-shell, was Windows cmd so nicht kennt/interpretiert :facepalm:

    Klar, mit den Backslashes funzt es nun auch mit den normalen Anführungszeichen:

    Code
    exomizer sfx basic -t64 -s "lda#\$00 sta\$D015 sta\$D020 sta\$D021 sta\$DBE7" -X "inc\$D020 dec\$D020" sourcefile.prg -o outputfile.prg

    Allerdings werde ich wohl erstmal bei den einfachen Hochkommas bleiben - das macht die Befehle irgendwie lesbarer :whistling:

    EDIT:

    Zitat

    EDIT: oder nimm dezimalzahlen

    funzt zwar, aber
    dezimalzahlen sucks :bgdev

    Viele Grüße,
    GI-Joe
    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. * 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.

  • Falls du tatsächlich make benutzt (und nicht shell-Skripte schreibst), musst du einfache Anführungszeichen oder doppelte Anführungszeichen und backslashes UND doppelte Dollarzeichen verwenden, also im Makefile:

    entweder

    Code
    acme ... -s 'lda #$$0b sta $$d011'


    oder

    Code
    acme ... -s "lda #\$$0b sta \$$d011"

    Denn hier würde ein nacktes Dollarzeichen erstmal von Make als Aufforderung Interpolation von Make-Variablen interpretiert, dannach nochmal von der shell...

  • Denn hier würde ein nacktes Dollarzeichen erstmal von Make als Aufforderung Interpolation von Make-Variablen interpretiert, dannach nochmal von der shell...

    [offtopic]Danke für den Tip ! Diesen "Fallstrick" kannte ich auch noch nicht ...
    Allerdings wenn ich sowas lese, bleibe ich lieber bei meinen shell-scripten als "make"-files.
    Die reichen für die schmalen Sachen hier erstmal völlig aus.

    Es gibt sicher gute Gründe, richtige make-files einzusetzen, aber ich verwende meine knappe Zeit lieber für die acme-sourcen :)[/offtopic]

    Viele Grüße,
    GI-Joe
    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. * 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.

  • Was auch gehen sollte ist die "PC-Notation" zu verwenden, also
    8-bit: 0xFF
    16-bit: 0xFFFF
    Zumindest beim Parameter Startadresse mache ich das immer so, sowohl unter Win als auch unter Linux...

  • Was auch gehen sollte ist die "PC-Notation" zu verwenden, also
    8-bit: 0xFF
    16-bit: 0xFFFF

    also -X 'inc 0xD020 dec 0xD020' funzt nicht (in allen Varianten - mit und ohne space, mit und ohne ", mit und ohne ' )- das hatte ich bei der Fehlersuche auch alles schon versucht ;)

    Ich bin aber mit -X 'inc$D020 dec$D020' erstmal zufrieden ^^

    Viele Grüße,
    GI-Joe
    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. * 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.

  • also -X 'inc 0xD020 dec 0xD020' funzt nicht (in allen Varianten - mit und ohne space, mit und ohne ", mit und ohne ' )- das hatte ich bei der Fehlersuche auch alles schon versucht ;)


    Ah okay, ich habe das wie gesagt bislang immer nur mit den "direkten" Terminal Parametern genutzt. Den Code im -s-Switch habe ich logischerweise als Linux-User automatisch 'escaped' und in Make-Files habe ich sowas überhaupt noch nie genutzt, weil man bei größeren Projekten ja nicht irgendwelchen statischen Code in seinem Make-File haben möchte.
    Also eigentlich ist das überhaupt so ein Feature, dass man im Grunde gar nicht nutzen sollte*.

    *Und ja, ich gebe zu, ich nutze es auch: bei mir eben gerne für Onefile-Quick-Tests -s "lda #\$0b sta \$d011", weil das ohnehin das Erste ist, was man machen würde, bis der Init fertig ist. Aber wenn ich ehrlich bin, würde ich mir das auch eher als Default-Verhalten von Exomizer "SFX" wünschen, als es 'manuell' mitschleppen zu müssen :wink:

  • *Und ja, ich gebe zu, ich nutze es auch: bei mir eben gerne für Onefile-Quick-Tests -s "lda #\$0b sta \$d011", weil das ohnehin das Erste ist, was man machen würde, bis der Init fertig ist. Aber wenn ich ehrlich bin, würde ich mir das auch eher als Default-Verhalten von Exomizer "SFX" wünschen, als es 'manuell' mitschleppen zu müssen :wink:

    Ist Geschmackssache. Ich finde die Eingabe von Code vor, während und nach des Entpackens sehr gut, das macht den Exomizer zum flexibelsten Packer. Leider ist er beim Entpacken nicht so schnell wie z.B. Byteboozer, der ähnliche Kompressionsraten hat. (das Abschalten des Screens und der Sprites bringt auch nur max 10% mehr Speed)

    Viele Grüße,
    GI-Joe
    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. * 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.

  • Der -s Parameter ist schon interessant. Hab mal geschaut wie du den benutzt hast, aber was mach ich wenn ich ca. 50 Befehle einfügen will? Da wirds etwas eng auf der Kommandozeile. Gibts da einen Trick oder eine 2. Möglichkeit etwas auszuführen bevor Exomizer loslegt?

  • Da wirds etwas eng auf der Kommandozeile.

    nö, wieso eng ?
    unter Linux kannst Du einfach Zeilenumbrüche "escapen", z.B. so:

    Wichtig dabei ist: der Backslash (der ja in der Linux-shell die "Sonderfunktion" des direkt nachfolgenden Zeichens aufhebt), muss direkt vor dem Zeilenumbruch stehen (weil der Zeilenumbruch das nachfolgende "Zeichen" ist und ignoriert werden soll). Wichtig ist hier das abschließende " in Zeile 13, da das Ende des Stings ja oben noch nicht definiert wurde.

    Noch schöner/komfortabler macht sich sowas, wenn man mit seinem Lieblings-Assembler ein ganz normales Programm mit BASIC-Line schreibt und dann in den gepackten Code dahinter springt. dazu muß der restliche Code natürlich anders gepackt werden, z.B. so:

    exomizer sfx basic -t64 -Di_load_addr=$08E0 -s 'lda#$00 sta$D015 sta$D020 sta$D021 sta$DBE7' -X 'inc$D020 dec$D020' sourcefile.prg -o outputfile.prg
    Der daraus resultierende gepackte Code hat in diesem Beispiel die Ladeadresse $08E0 und das Entpacken wird mit JMP$08E0 gestartet. Der gepackte Code hat in diesem Beispiel also keine Basic-Zeile mehr, einfach reinjumpen und gut is.
    So kannst Du z.B. ganz gemütlich von $0801 - $08E0 ein kleines Progrämmchen davor bauen, in dem Du am Ende an der Stelle $08E0 nur das gepackte Files einfügen mußt (ohne die beiden Bytes der Ladeadresse - siehe Zeile 11 und 49) und und wenn´s an´s Entpacken des fetten Fisches gehen soll, machste einfach einen JMP$08E0 und gut is (siehe Zeile 11 und 42).

    EDIT:
    $08E0 war jetzt nur ein Beispiel, Du kannst, wenn Dein Mini-Programm vorweg fertig ist, auch viel näher "ranrücken" mit deinem Wert - Du muß dann halt nochmal Dein Hauptprogramm mit exomizer neu packen mit einem anderen Wert für -Di_load_addr=$XXXX, der dann optimalerweise direkt hinter dem Code Deines "vorweg-Mini-Programms" liegen sollte ;)

    Viele Grüße,
    GI-Joe
    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. * 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.

  • Vielen Dank, bin schonmal einen Schritt weiter. War jetzt faul und hab die Methode mit dem Parameter -s und den Rückstrichen gewählt und das klappt soweit auch. Allerdings wollte ich den Bildschirm löschen und das hat ich nicht geschafft.

    Weder jsr 65371, noch jsr 58692 wollte klappen. Der Bildschirm wird zwar gelöscht und es entpackt, aber am Ende des Entpackvorgangs gibt es einen Crash.

    Hab testweise auch mal X, Y und status vor dem JSR gepusht, und danach gepullt. Half aber auch nix. :gruebel

    edit: hab den Bildschrim jetzt mit LDA und STA (und einer Schleife) gelöscht, das ging! ^^

  • Weder jsr 65371, noch jsr 58692 wollte klappen. Der Bildschirm wird zwar gelöscht und es entpackt, aber am Ende des Entpackvorgangs gibt es einen Crash.

    Hab testweise auch mal X, Y und status vor dem JSR gepusht, und danach gepullt. Half aber auch nix. :gruebel

    Wie schon erwähnt, ich halte die 2. Variante aus dem PostingBitte melde dich an, um diesen Link zu sehen. eh für besser/flexibler/komfortabler :dafuer:

    Viele Grüße,
    GI-Joe
    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. * 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.