Fragen zu Exomizer

Es gibt 169 Antworten in diesem Thema, welches 46.852 mal aufgerufen wurde. Der letzte Beitrag (29. Januar 2022 um 12:38) ist von InsertDisk2.

  • Ja, aber wenn die SID's bei $E000 und $FFFF liegen, bringt einem das umschalten ja nix. Dann muss man ja vorher wissen, das sie im Kernal liegen. Also bräucht man wieder die Adresse.

  • Wie war das noch mit Exomizer, entpackt der nicht je nach Konfiguration von hinten nach vorne? Wenn das die Defaulteinstellung wäre müsste man wohl in die Entpackroutine eingreifen und die entsprechenden Pointer direkt vor dem eigentlichen Entpackprozesss begutachten, um die exakte Endadresse rauszukriegen.

    Aber das ist jetzt eher spekulativ, ich selbst benutze Exomizer eher selten bis gar nicht, weil zu langsam, zu optionsreich und zu blackboxig :)

  • * kernel an
    * sid playerroutine
    * kernel aus

    Macht eben bloß keinen Sinn, wenn z.B. der Song von $E000 bis $F800 liegt, meine Routine sieht eher so aus:

    Code
    LDA #KERNELSTATUS; #$35 oder #$36 eben je nach Range, die ich nach dem Decrunchen vergeblich gesucht habe
    STA $01
    JSR $PLAY
    LDA #$36; KERNEL wieder an, um ein paar doch Routinen nutzen zu können zwecks RAM-Sparens
    STA $01
    JMP $EA81; Ende Gelände

    Der nächste Song hätte immer eine "frische" ROM Kopie.


    Oder aber er überschreibt das RAM, weil es mit seiner eigenen Range kollidiert :) Mir fiel noch als Idee ein, dass man vor dem Decrunchen bei ausgeschaltetem KERNEL alle Werte im RAM von $E000 bis $F... aufaddieren könnte als Checksumme, die man erneut erheben und vergleichen könnte nach dem Decrunchen. Aber was für ein Aufwand...

    Zitat

    ...deine Lösung auch mehr als Praktikabel...


    Ich feilsche mittlerweile schon um jedes Byte. Um möglichst universellen Einsatz zu gewärleisten, lasse ich sogar Tape Buffer und ZP und weite Teile des Stacks, in Ruhe, also die üblichen Orte, an denen man sonst gern mal RAM findet und einsetzt. Mir ist dementsprechend lieber, jedem File ein oder zwei Bytes anzuhängen (und in Kauf zu nehmen, dass im Durchschnitt jedes 256. oder 128. File einen Block zu groß wird) als alles, was im Code mehr als 5 Bytes frisst.

    Oder einfach gleich Bitte melde dich an, um diesen Link zu sehen. verwenden ...


    Mach ich natürlich, Ulli, großartiges Tool, keine Frage aber 91% sind eben leider nicht 100% :)
    Zwar schreibt Linus Akeson

    Zitat

    Sidreloc is capable of relocating 91% of HVSC Bitte melde dich an, um diesen Link zu sehen. out of the box. Many of the remaining tunes can be relocated by tweaking the settings to fit them.


    Aber um allzu viel zu tweaken, müsste ich tiefer einsteigen, als ich ihm Moment will. Und selbst dann werden - wenn auch wenige - Fälle bleiben, an denen SidReloc an seine Grenzen stößt.

    zu langsam, zu optionsreich und zu blackboxig


    Ich versteh schon, was Du meinst, deswegen nutze ich relative stupide den sfx-Kram im wesentlichen so, wie wir ihn im Wiki mit Beispielen beschrieben haben.
    Bitte melde dich an, um diesen Link zu sehen.
    Die Crunching-Rate ist einfach mal satt(!) unübertroffen. Für Huppiefluppie livedecrunching würde ich glaube ich auch eher ByteBoozer wählen. Aber auch das geht mit Exomizer ziemlich schnell, wenn man weiß, wie (was ich nicht tue). Für meine Zwecke wie SIDs decrunchen und dann abspielen, ist Exomizer allemal schnell genug, z.B. hier eingesetzt:
    Bitte melde dich an, um diesen Link zu sehen.
    Ob man nun einen Sekundenbruchteil wartet, weil der Coder irgendwo mit Absicht ne Pause eingebaut hat oder weil gerade decruncht wird, merkt doch der User gar nicht ^^

  • zu optionsreich und zu blackboxig

    Zu optionsreich?
    Blackboxig? Und welchen Packer benutzt Du?
    Quellcode UND docs vom Packer UND Packer liegen vor. Weniger black geht kaum :wink:
    'How less black could this be? The answer is: none".

    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.

  • Mir ist dementsprechend lieber, jedem File ein oder zwei Bytes anzuhängen (und in Kauf zu nehmen, dass im Durchschnitt jedes 256. oder 128. File einen Block zu groß wird) als alles, was im Code mehr als 5 Bytes frisst.

    Das ist hier zwar etwas off-topic, aber: Commodore war es auch egal, dass jedes 256. File einen Block zu groß wird. Man schreibe 254 Byte in eine Datei bzw. speichere einen 252-Byte-Bereich und prüfe dann die Blockzahlen - der Bug ist sogar noch in Jiffy-Dos enthalten... :)
    Zum Thema: Du hast eigentlich schon alles dazu gesagt; es bringt nichts, zwei Bytes zu sparen, wenn man dafür mehr als zwei Bytes Code schreiben muss.

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

  • Zu optionsreich?
    Blackboxig? Und welchen Packer benutzt Du?

    Den, der bei 64Tass dabei war. Der hat nur eine Option, und die kann man getrost ignorieren :)

    Zitat

    Quellcode UND docs vom Packer UND Packer liegen vor. Weniger black geht kaum :wink:
    'How less black could this be? The answer is: none".


    Nuja, das Geschwindigkeitsproblem wird dadurch trotzdem nicht gelöst, und der Sourcecode will ja auch erstmal gelesen und verstanden werden. Bei dem vergleichsweise simplen Tass-Dingen hab ich mir die Mühe mal gemacht, damit sich das rechnet werd ich den erstmal noch ne ganze Weile weiterbenutzen :)

  • TheRyk
    Poste mal deine exakte Exomizer-SFX-Aufruf Zeile. Dann zeige ich dir, wie du sie abändern musst!


    Eigentlich habe ich die Baustelle abgehakt. Aber nicht dass es heißt, man hätte nicht alles versucht, meinst Du, was in der Batch steht?

    Code
    exomizer sfx $0f5d foo.prg -o xfoo.prg -n -Di_load_addr=$1000


    Decrunching Aufruf also mit JMP $1000, bei $0F5D poke ich vor dem Decrunchen lediglich JMP $woandershin rein, damit das decrunchte File weiter "behandelt" werden kann.

  • Hänge folgende Zeile an deine Exomizer-Zeile an, dann hast du deine Endadresse in $fe/$ff nach dem entpacken. Macht zusätzliche 28 Bytes pro Packdatei.

    Code
    -s "lda$101d sta<$fe lda$101e sta<$ff ldy#$03 lda($fe),y pha dey lda($fe),y pha ldy$1001" -f "pla sta<$fe pla sta<$ff"

    Einfacher wäre es natürlich in deinem Code z.B das Highbyte der Endadresse vor dem Entpackvorgang zwischenzuspeichern, um dieses nach dem Entpackvorgang auswerten zu können. Aber du kämpfst ja um jedes Byte.

    Code
    lda $1007
        sta $fe
        lda $1008 
        sta $ff 
        ldy #3      ; #2 = Lowbyte; #3 = Highbyte der (Endadresse+1) der decrunchten Datei 
        lda($fe),y
        sta $02     ; Highbyte von (Endadresse+1) der decrunchten Datei in Zeropage $02 zwischenspeichern
    
    
        jmp $1000
  • Cool, danke!

    Zumindest weiß ich jetzt WIE :)

    Ein Advanced Beginner wie ich findet zwar oft noch mal einen Haufen Bytes im Main Code, aber wenn das crunched file echt um 28 byte größer wird, muss ich mir gut überlegen, ob ich das in Kauf nehmen will, heißt halt jedes edit 9. file (im durchschnitt) belegt zusätzlich einen Block

    Bin mittlerweile recht festgefahren auf der Idee, die Program End Adresse einfach vor das gecrunchte File zu schieben. Das kostet mich evtl zwar mehr als 28 bytes pro Disk aber im günstigsten Fall nicht mal einen Block; der Main Code ist eben nunmal heilig im Moment, weil dort noch ein paar Sachen realisiert werden müssen, es somit evtl(!) - genau oder auch genau nicht - darauf ankommt, ob ich die gefragten 1-2 bytes aus der ZP oder sonstwoher lese.

    To be released @ Bunker 2013 ;) Wenn es fertig wird, reiche ich auch umfangreiche Doku evtl auch Sources mit, so dass z.B. auch die hier gestellten und noch nicht beanworteten Fragen nach "which f...in SID uses KERNEL" geklärt werden können ^^

    Der Tipp kann aber auf jeden Fall nochmal nützlich werden, wenn ich das auf Massenspeicher (NeoRAM/EF) übertrage.

    Es sind keine anzeigbaren Aktivitäten vorhanden.

    2 Mal editiert, zuletzt von TheRyk (30. Juli 2013 um 11:15)

  • Ich habe gerade das merkwürdige Problem, dass ab einer gewissen Range des zu crunchenden Codes beim Decrunchen Teile des Hauptprogrammes zerhackt werden. Das vor Übergriffen des Decrunchings zu schützende Hauptprogramm liegt bei $0800-$0FFF und $D000 bis $DFFF. Wenn ich nun etwas crunche, was ursprünglich schon eine Range bis sagen wir mal $CFXY hat, dann wird offenbar mit SFX so ungünstig decruncht, dass mein Main Code unterhalb $1000 bei $D000 etc. durch Decrunching Tabellen oder ähnliches irgendwas zerschossen wird. Gibt es eine Möglichkeit, dem Exomizer zu erzählen, dass er für seine whatever Decrunchingzwecke gefälligst Teile des RAMs in Ruhe lassen bzw z.B. erst ab $E000 rumspuken soll?

    Danke im Voraus, Grüße
    Ryk

    Edit: Sorry, einiger Unsinn musste editiert werden

    PS: Problem besteht nicht bei niedrigerer Range und scheint erst so zu sein, seit ich das RAM unter $D000 im MainCode nutze

    Es sind keine anzeigbaren Aktivitäten vorhanden.

    2 Mal editiert, zuletzt von TheRyk (19. September 2013 um 13:56)

  • Für derartige Projekte solltest Du Dich endlich mal von SFX verabschieden und MEM und den exodecrunch Code nutzen. Dann hast Du auch die Kontrolle über das RAM. Für SFX gibt es da imho keine weiteren Optionen.

  • Jau, ist wohl so... *schnüff*

    Bitte melde dich an, um dieses Medienelement zu sehen.

    Danke :)

    ich habe Deinen Beitrag aus dem Nachbar-Thread schon offen :)

  • Ouch, Double Facepalm myself...

    Mein Problem war keines, man muss einfach nur $01 richtig setzen :baby: vor dem Decrunchen eigtl weiß ich das auch, aber allmählich verlier ich mal wieder den Überblick, Zeit für Kaffee und Krawallbrause :D

    Alles roger also auch mit SFX, Herr Whitaker kann also vorerst wieder einpacken, der RAM-Befehl Exodecrunch Kram inklusive der bei mir auf ACME nicht lauffähigen Samples ist für mich im Moment wie weiße Figuren und schwarzer Kaffee..., das muss Spider mir irgendwann nochmal erklären, aber nicht jetzt ;)

  • Nunja, das YouTube Video ist immer noch "the way to go" - oder wie man so schön sagt. "aufgeschoben ist nicht aufgehoben"... Für das, was Du da treibst wäre es schlauer, sich langsam mal von dem SFX zu verabschieden =)

  • Jau, seh ich auch ein :angel

    Keine Ahnung, was beim Compilieren Deiner Snippets schief lief, es lag nicht an den Pfaden, vermutlich ist mein ACME doch mal reif für ein Update, werde mich gelegentlich in dem besagten ExoDecrunch-Fred mal melden, bis dahin ergötze ich mich weiter am ReadMe und den Kommentaren im Code wie "Still no idea --> Ask your Mother", "Clueless -> go play a game", eh, eh, eh ^^

    Jetzt ist erstmal gewisser Release oder zumindest Code-Druck da, weil das Teil auf der CC eingesetzt werden soll übermorgen

  • [offtopic]

    Nur um meine Neugier zu befriedigen.... Welche zB? :nixwiss:


    besser spät als nie: Barbarian funktioniert zB scheinbar nur mit KERNEL on

    BTW: Es gibt auch nicht wenige .SIDs, die selbst nach $01 schreiben, um sich die ROM/RAM Konfiguration so zu legen, wie sie es gern hätten, merkt man, wenn man beim Relocaten mit SIDReloc "out of bond" Schreibzugriffe bei $01 gemeldet kriegt ^^[/offtopic]

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

    C128DCR mit Comet64
    Apple IIgs (defekt)
    Acorn Electron
    Oric Atmos (defekt)
    VC-20 mit UltiMem

  • Cool, danke :)

    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.