Ich sag auch danke.
Hat in 2.0.8 gegenüber 2.0.7 irgendwas eigentlich für C64 Relevanz?
Ich sag auch danke.
Hat in 2.0.8 gegenüber 2.0.7 irgendwas eigentlich für C64 Relevanz?
[offtopic]
Nur um meine Neugier zu befriedigen.... Welche zB?
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]
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
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 ![]()
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 ![]()
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
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.
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.
* 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:
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
ZitatSidreloc 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 ![]()
[offtopic] duke: ich bin auf Reisen und habe daher mein Trouble-Shooting.TXT nicht zur Hand, reiche aber gern Beispiele nach, es war ganz sicher mehr als ein Fall und nichts völlig Unbekanntes. Habe auch die Sprungziele nicht im einzelnen nachverfolgt (Enthusis Vermutung scheint mir aber z.B. naheliegend), aber festgestellt, dass man auf der sicheren Seite ist, wenn man bei Tunes, die über $E000 hinausragen, das KERNEL ausschaltet und es ansonsten anlässt.
Soulstealer: die Betonung liegt auf "close to universal", d.h. alles von $1000 bis $F... sollgehandlet werden. Wenn ich Deine Lösung ROM ab $E000 ins RAM schaufeln wähle, bin ich keinen Deut weiter als im Moment, da ich ja wieder Lo-Byte und Hi-Byte des ungecrunchten Tunes kennen muss, um zu entscheiden, ob die ROM->RAM Nummer stattfinden darf; es liegen etliche Game Tunes zwischen $E000 und $FFFF, von denen sich bei weitem nicht alle einfach, also mittels Tools, relocaten lassen. Das Ding soll im übrigen auch unbehandelte und somit gecrunchte PSID Files abspielen.[/offtopic]
BTT
Wäre halt schön gewesen, wenn es - wie Sauhund vermutete -, einfach bei $AE/$AF gestanden hätte nach dem Decrunchen, tut es aber nunmal nicht. Im Moment ist es - für mich - am einfachsten, wenigstens das Highbyte als Flag vor das Exomizat zu stellen und vor dem Decrunchen auszulesen. Das eine Byte tut angesichts des gewünschten Effekts nach dem Crunchen ja seltenst weh (in den wenigsten Fällen wird genau dadurch ein Block auf der Diskette "überlaufen").
Grundsätzlich ist da was dran, für andere Projekte würde ich mittlerweile auch eher dazu neigen, mir die KERNEL-Routinen, die ich brauche, einfach irgendwo ins RAM zu kopieren.
Aktuell geht es aber um einen "close to universal" SID-Player, leider gibt es tatsächlich SIDs, die auf KERNEL-Routinen zugreifen ![]()
Erstmal vielen Dank!
Aber ich werde das jetzt wohl erschlagen, indem ich ein oder zwei Flag-Bytes vor das "Exomizat" hänge mit der Endadresse des ungecrunchten Inputs (entweder nur Highbyte oder High und Low). Ich weiß, dreckig, aber praktikabel.
Nur falls es jemanden interessiert, weshalb ich so scharf auf diese zwei Bytes bin: Ich brauche die Werte dringend, weil anhand der Endadresse berechnet wird, ob ich das KERNEL ausschalten muss oder nicht.
Ahh Danke, da habe ich erstmal wieder einen Batzen Register zum Auslesen, der Tag ist gerettet ![]()
Hmh leider haben nach dem Decrunchen die Werte in $AE/AF zumindest nach meinem Dafürhalten/auf Anhieb erkennbar nix mit dem Programmende zu tun, wäre wohl zu einfach/naheliegend ![]()
Wurde evtl. doch gar nicht bewusst abgelegt, weil es zu unwichtig war
Wer sonst außer mir hat mal wieder ne Exomizer-Frage.
Bisher habe ich ja immerhin gelernt, dass die ZP und einige andere Bereiche sauber gef...t werden beim Decrunchen und ggf repariert werden müssen. Aber evtl. kann man aus dem ZP-Totalschaden sogar noch irgendwelche halbwegs nützlichen Informationen gewinnen...?
Jetzt die eigtl/konkrete Frage: Kann man nach dem Decrunchen aus irgendwelchen Vektoren (ähnlich wie bei KERNEL-Load z.B. ZP-Adressen $AE/$AF "Programmende") auslesen, wo das höchstgelegene decrunchte Byte liegt?
ach so spektakuläres hab ich gar nicht vor ![]()
dachte eher an erkennen mittels KERNEL-byte-by-byte-lesen der ersten so-und-soviel Bytes am C64
ja dachte ich mir schon fast, dass für einen reinen header nix verschwendet wird, aber werde mal reinwuseln, vermutlich gibt es irgendeine typische bytefolge im depackercode
Hi! und willkommen in einem meiner Lieblings-Threads, nicht totzukriegen, fragen koscht ja nix.
Heute mal was eher akademisches... kann man eigentlich in einem per
erstellten File nachher anhand eines Headers identifizieren, dass es sich um ein mit Exomizer gecrunchtes File handelt? Habe leider nur wirres Zeug und CPC kram ergoogeln können.
Danke für die Antworten
Dazu jetzt noch eine Competition zu machen, wird leider zu knapp bis zum WE.
Gibt es eigentlich Erfahrungswerte, ab welcher Source-Größe pi mal Daumen Crunchen überhaupt Sinn macht? Habe jetzt beim Crunchen von etwas um die 400 bytes Text erlebt, dass es sich nicht lohnt, weil inklusive Decruncher und Tabellen 550 bytes Compilat rauskommen.
Klar kommt es immer darauf an, was für Daten man vor sich hat, aber bleiben wir der Einfachheit halber mal beim Beispiel "normaler" Text, der nicht nur aus einer endlosen Reihe von "AAAAAAAAA..." besteht