Beiträge von GI-Joe im Thema „exomizer - Unterschiede zwischen Windows- und Linux-Versionen“

    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:

    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 ;)

    *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)

    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]

    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

    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

    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 ?