2018-05-16: Exomizer v3.0.0 released
https://bitbucket.org/magli143/exomizer/wiki/Home
Bis zu 50% schnelleres Entpacken
Leichte Kompressionsverbesserung
Hello, Guest the thread was called22k times and contains 166 replays
last post from Zirias/Excess at the
Fragen zu Exomizer
- TheRyk
- Thread is marked as Resolved.
-
-
Hab mal ne Frage zu exodecrs. Ich wollte damit diverse Screens im laufenden C64-prg entpacken, aber wie kann ich einstellen, WOHIN entpackt wird? Rufe Exomizer folgendermaßen auf:
Bei .prgs nimmt er die Adresse aus dem Header der ungepackten Datei, nehme ich mal an. Aber wie kann ich eine Reihe von Screens (als .bin) einzelnd packen, die ggfs. auch an unterschiedlichen Stellen HIN (!) entpackt werden sollen?
Gibt es dafür eine Pack-Option? *find"brettvormkopf"-smileynicht*
Die letzten zwei Bytes in den gepackten Daten definieren die Endadresse (+1) wo er es auspackt. Wenn du zum Beispiel eine Datei packst die ihre Startadresse bei $C000 hat und 628 ($274) Byte lang ist, dann steht im von Exomizer erzeugten File zuletzt 74 C2, d.h. die Datei wird dann rückwärts von $C274 aus entpackt.
Wenn du die beiden Bytes überschreibst, entweder schon im File oder im Speicher nach dem Laden des gepackten Files entpackt exomizer die Daten entsprechend an eine andere Stelle. Wird in obigem Beispiel 74 C2 zum Beispiel mit 00 D0 ersetzt, dann landen die Daten nach dem Auspacken im Bereich von $CD8C bis ausschließlich $D000 . -
Blöde Frage: Wenn man mehrere Blöcke an verschiedene Speicheradressen platziert, dann scheint der Entpacker die freien Bereiche dazwischen auszunullen. So zumindest meine Feststellung nach Debuggen mit Store-Breakpoints auf der Suche nach dem verschwundenen Loader-Code.
Kann man das irgendwie abstellen?
-
Nicht direkt.
Was du machen kannst ist die einzelnen Blöcke einzeln als "mem" zu komprimieren und den Beispiel Entpacker so anpassen dass er deine Blöcke entsprechend auspackt.
(Das mache ich so in vielen Projekten, sorgt auch dafür dass es deutlich kleiner wird.)
-
Den musst du eigentlich gar nicht anpassen sondern einfach nur mehrfach aufrufen ... Nur eben sicherstellen, dass dein get_compressed_byte (oder wie diese Routine heißen sollte) die komprimierten Blöcke in der richtigen Reihenfolge liefert.
-
Ah ja, also Handbetrieb. Hab' es befürchtet
Ich habe mich da aus Faulheit auf sfx verlassen, dann muss eben mem ran. Naja, das kenne ich ja schon von Bomb Jack DX.
Danke!
-
Naja sfx taugt ja echt nur für was fertiges "mal eben" packen. Habe ich so noch nie in nem eigenen Projekt verwendet, ist viel zu unflexibel. Den decruncher hat man ja schnell included und aufgerufen, man muss nur die Routine schreiben, die die komprimierten Bytes liefert (was im einfachsten Fall wenige instructions sind).
Damit kann man dann nette sachen machen, z.b. von diskette "on-the-fly" decrunchen oder auch während des entpackens schon was halbwegs interessantes tun (ist in meinem letzten werk, das excess/abyss invitro, so drin). sfx sehe ich eher für schnelle tests oder kram, den man gar nicht selbst gecodet hat
