Ich müsste jetzt nachblättern, aber es könnte sein, dass der 64er Packer mehr kann.
Grade schnell das SH24 rausgeholt, dort steht, der maximale Packbereich ist $01E0-$FFFF.
Falls es nichts dafür gibt, würde ich es so machen, dass ich die Daten ($0350-$FFFF) händisch mit dem Algorithmus "Equal Code" packen würde. Danach dann mit Exomizer. Der Platz unterhalb $0350 sollte für den EC-Entpacker reichen.
Grade schnell das SH24 rausgeholt, dort steht, der maximale Packbereich ist $01E0-$FFFF.
cool! Nur wird der nicht so stark packen wie Exomizer, vermute ich.
Der Packer nennt sich zwar Image Packer, es steht aber nicht drin das er nur Bilder gedacht ist, dafür ist das Programm nur 3 Blocks groß laut Beschreibung .
Ein Versuch ist es wert .
Ach, der 64er Packer ist gar nicht so schlecht! Der packt schon ganz schön was weg, im Vergleich zu den Packern, die in der Crackerszene kursieren, meist sogar deutlich besser. Beim Zwischenkompressor muss man sich allerdings Zeit nehmen, bei einem vollen Speicher sind da schnell mal 5-6 Stunden weg.
Ich hatte vor einiger Zeit schon mal ein Packer-Benchmark gemacht, habe ich nur noch nicht gepostet. Ich muss mal suchen, wo ich die 3,5" Disk hin hab. Habe nämlich so lange Packer laufen lassen, bis die Disk voll war 
Zudem gibt es ja noch die Möglichkeit, dass man z. B. nur den Vorkompressor nutzt und danach den Exomizer (den habe ich übrigens nicht gebenchmarkt, weil Cross-Plattform). Oder Zwischenkompressor, aber das Ergebnis nur des Zwischenkompressors ist normal schon sehr gut.
Der Happy-Packer ist übrigens ähnlich, kann aber weniger - sozusagen 64er Packer light
Zudem gibt es ja noch die Möglichkeit, dass man z. B. nur den Vorkompressor nutzt und danach den Exomizer
Jo, hab ich mir gerade angesehen. So muss man das nicht mal selbst programmieren. Klasse Programm.
Was die Packzeit angeht, könnte man VICE 2.4 mit Warp einsetzen (bei mir 18000%).
Ja, mit Vice ist das durchaus praktisch Ich kenne keinen besseren Packer am 64er. Mich wundert es deshalb immer wieder, dass der so unbekannt ist. Wahrscheinlich, weil er im Eprom laufen will.
Na das ist ja ein krasses Teil 1Byte. Da fragt man sich, was da dahinter steckt. Das Ding gehört schon fast mal untersucht.
Programmtechnisch kann ich nichts dazu sagen, ich habe es noch nicht ausprobiert, einen Blick ist es mal wert .
Programmtechnisch kann ich nichts dazu sagen, ich habe es noch nicht ausprobiert, einen Blick ist es mal wert .
Ich muss mal sehen, ob ich die Tage mal dazu komm, das Ding auseinander zu legen... 64k in 2 Sekunden entpacken, das ist ja fast minimal mehr als das reine Kopieren wäre.
Gibt es einen anderen Packer, der das kann, oder kann man exomizer irgendwie dazu bewegen, es zu können?
probiere doch mal den subsizer von tlr
Ebenso geht es mit pucrunch.
pucrunch ist ein bisschen buggy und der subsizer sfx-entpacker entpackt schneller 
Art Packer (RLE-Kompression) https://csdb.dk/release/?id=198456
War auf der Magic Disk 10/90.
Das Ergebnis dann mit dem Exomizer crunchen.
Exomizer kann für den C64 von $0200-$FFFF entpacken. Schau mal nach "-Di_table_addr=0x2".
So, vielen Dank erstmal an alle
Ich habe inzwischen ein paar Packer getestet. Am besten (also genauer gesagt fehlerfrei) hat es nur der 64´er Packer gemacht. Leider ist in der Vorkompressor-Variante die Datei noch zu gross (216 Blocks). Die Zwischenkompressor Variante hat mir erstmal zu lange gedauert, werde ich aber nochmal testen.
Auf dem 2. Platz war exomizer (der aufgrund des Tipps von Sokrates nun auch ging), aber es gab einen Fehler, der beim Eingeben des Namens in einer Highscoreliste das Eingabefeld blockiert. Ansonsten lief alles...
TheRealWanderer hast Du Dir im SH24 die Doku durchgelesen? Zwischenkompressor Typ C ist auch ein Versuch wert! Wenn Du den Vorkompressor weg lässt, musst Du Typ F wählen, Suchweite 0 (Vorgabe) ist da durchaus zu empfehlen.
Auf dem 2. Platz war exomizer (der aufgrund des Tipps von Sokrates nun auch ging), aber es gab einen Fehler, der beim Eingeben des Namens in einer Highscoreliste das Eingabefeld blockiert. Ansonsten lief alles...
Das exomizer beim packen/entpacken Fehler generiert halte ich für sehr unwahrscheinlich. Kann es sein, dass das Program in dem nicht gepackten/entpackten Bereich $0000–$Programmbeginn bestimmte Werte erwartet, die aber durch die Entpackerroutine geändert wurden?
