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.
Fragen zu Exomizer
-
TheRyk -
1. Oktober 2009 um 21:22 -
Erledigt
Es gibt 169 Antworten in diesem Thema, welches 46.850 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Oder einfach gleich Bitte melde dich an, um diesen Link zu sehen. verwenden ...
-
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 ausMacht eben bloß keinen Sinn, wenn z.B. der Song von $E000 bis $F800 liegt, meine Routine sieht eher so aus:
CodeLDA #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ändeDer 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 AkesonZitatSidreloc 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
'How less black could this be? The answer is: none". -
TheRyk
Poste mal deine exakte Exomizer-SFX-Aufruf Zeile. Dann zeige ich dir, wie du sie abändern musst! -
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. -
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
ZitatQuellcode UND docs vom Packer UND Packer liegen vor. Weniger black geht kaum

'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?
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.
-
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.
-
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 $D000etc. durchDecrunching Tabellen oder ähnlichesirgendwas zerschossen wird. Gibt es eine Möglichkeit, dem Exomizer zu erzählen, dass er fürseinewhatever Decrunchingzwecke gefälligst Teile des RAMs in Ruhe lassen bzw z.B. erst ab $E000 rumspuken soll?Danke im Voraus, Grüße
RykEdit: 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
-
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

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

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?

besser spät als nie: Barbarian funktioniert zB scheinbar nur mit KERNEL onBTW: 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.
-
Cool, danke

-