Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1:
      
     CommentAuthorjhusak
   • CommentTime8 Mar 2011 14:03

    
   Mam pytanie, jakich używacie pakerów do pakowania xexów. Jest ich wiele, a nie znalazłem porównania.
   
   Chodzi mi o jak największą prędkość rozpakowywania, pakowanie najlepiej na dużym komputerze.
   
   Chodzi mi też o rozwiązanie możliwie skryptowe (tzn program z wypasionym GUI jest dla mnie mniej atrakcyjny)
   
   No i najlepiej open-source , ale to nie jest wymóg. Powinien działać pod WINE, jeśli jest pod Windows.
2. • 2: CommentAuthorVidol
   • CommentTime8 Mar 2011 16:03

    
   super packer 3.2
   ->link<-
3. • 3: CommentAuthortebe
   • CommentTime8 Mar 2011 18:03

    
   w paczce z mads-em znajdziesz pakery warte uwagi
   
   moim faworytem jest exomizer
4. • 4: CommentAuthor0xF
   • CommentTime8 Mar 2011 20:03

    
   W źródłach Numena jest zipxex, czy jakoś tak.
   
   Z nowych to xebin.
5. • 5:
      
     CommentAuthorpirx
   • CommentTime8 Mar 2011 21:03

    
   1up for exomizer - czyni cuda.
6. • 6:
      
     CommentAuthorjhusak
   • CommentTime18 Mar 2012 17:03 zmieniony

    
   Po przetestowaniu exomizera:
   - prędkość rulez, tak na oko z 5-10 kilo na sekundę, chowają się wszystkie inne, włącznie z pp, który jest tylko nieco wolniejszy. Prędkość exomizera jest taka, że niezauważalna, no, może w przypadku dłuższych gier.
   - niby powinien, a nie za bardzo działa, zapuściłem kilka większych gier, ale nie dał rady.
   - nie czyści pamięci po sobie, czyli niektóre gry na to wrażliwe mogą mieć artefakty.
   - compression ratio jest bardzo wysoka, porównywalna z najlepszymi
   - prosty depacker (<1 strona pamięci)
   - jest wieloplatformowy.
   
   Super nadaje się do pakowania danych w grach (plansz, etc) - ma taki tryb, oprócz xex.
7. • 7: CommentAuthorxxl
   • CommentTime18 Mar 2012 19:03

    
   lepszy od tego:
   ->link<-
   
   ?
8. • 8:
      
     CommentAuthorjhusak
   • CommentTime18 Mar 2012 20:03 zmieniony

    
   No chyba, deflate jest dość wolny w porównaniu (trwa minuty, zanim rozkompresuje). Nie jest optymalizowany na ośmiobitowce, a exomizer jest (zarówno prędkościowo, jak i lepiej radzi sobie z danymi ośmiobitowymi (cokolwiek by to nie znaczyło))
   
   Popraw mnie, jeśli się mylę.
   
   Projekt jest dość ciekawie prowadzony. Zalecam zajrzeć do źródełek.
9. • 9: CommentAuthorxxl
   • CommentTime18 Mar 2012 21:03

    
   w beep'em all 3 dane i player jest dekompresowany w momencie wyboru muzyki, nie zauwazylem spowolnienia. ale moze faktycznie trzeba sie przyjrzec exomizerowi
10. • 10: CommentAuthortebe
    • CommentTime18 Mar 2012 21:03

     
    exomizer wykorzystuje skromniejsze zasoby pamięci w porównaniu do deflatera, exomizer można umieszczać w tym samym obszarze co docelowy obszar rozpakowanych danych
    
    wydajnościowo deflater potrafi lepiej spakować niż exomizer, dzięki ostatniej poprawce wykorzystującej gzipa z 7zip-a, nie jest to jakaś astronomiczna różnica
    
    każdy ma coś do zaoferowania
11. • 11:
       
      CommentAuthorjhusak
    • CommentTime18 Mar 2012 21:03 zmieniony

     
    właśnie przetestowałem drop zone. Depack trwa 5 sekund.
    Jest to też najkrótsza wersja drop zone, niecałe 21 kb.
    
    Musiałem wyciąć fancy loading napis DROP ZONE żeby się spakowało.
    
    Toż to z magneta już niecałe 8 minut się ciągnie :)

    • dz.xex
12. • 12: CommentAuthorat0mic
    • CommentTime18 Mar 2012 22:03 zmieniony

     
    świetnie dobry paker - drop zone to kolejna gra którą najwolęna Atari ;)
    
    czy animka napisu Drop Zone jest na DLI poprzez zmianę lms?
13. • 13:
       
      CommentAuthorjhusak
    • CommentTime18 Mar 2012 22:03 zmieniony

     
    Tebe, ja rozumiem, że deflater to jest majstersztyk; powstał dla najlepiej kompresującego algorytmu, a i tak zmieścić to na 3 stronach to dla mnie wyczyn.
    -- edit -- nikt mnie nie poprawia - 509 bajtów to jest niecałe 2 strony.
    
    Jednakże deflater przeznaczony jest na szybkie komputery i to w dodatku 32/64 bitów, pewnie na takich danych radzi sobie lepiej, niż na "kaszance" ośmiobitowej.
    
    Nie wiem, może to, co piszę (powyższe zdanie) nie ma sensu, ale tak czuję :)
    
    Dlatego cieszy mnie exomizer, że jest i że jest wybór. Poza tym zarówno exomizer jak i deflater spełniają moje oczekiwania co do sposobu użycia :)
14. • 14:
       
      CommentAuthorjhusak
    • CommentTime19 Mar 2012 10:03

     
    @at0mic, nie, jest przez eor, zmieniany jest kolor. I jest do bólu zgodna z zaleceniami tworzenia procek obsługi przerwań. Jest to bodajże przerwanie końca transmisji, czyli co blok zmienia się kolor napisu DROP ZONE.
    
    Polecam sobie sprawdzić drop zone wersja 2 lub 3 (są takie same, jedna magarbage na końcu)
15. • 15: CommentAuthorBrix
    • CommentTime19 Mar 2012 11:03

     
    Może nieco oftopikowo, bo właśnie chciałem przetestować exomizera, gdyż wyniki pakowania były bardzo obiecujące (najzwyklejsze dane binarne, czyli "raw" jeśli dobrze zrozumiałem o co chodzi). Tylko chyba kompletnie zgłupiałem z tym "packed_end" i nie wiem jak podać parametry dla exod_decrunch (exodecrunch.asm). Dodam, że źródło i cel na siebie nie nachodzą.
    
    Pomoże ktoś, jak prawidłowo użyć pakera i depakera w tej sytuacji? :)
16. • 16: CommentAuthor0xF
    • CommentTime19 Mar 2012 11:03

     

    jhusak:

    No chyba, deflate jest dość wolny w porównaniu (trwa minuty, zanim rozkompresuje).

    
    Co za bzdura.
17. • 17:
       
      CommentAuthorjhusak
    • CommentTime19 Mar 2012 23:03 zmieniony

     
    @0xF :)
    
    No właśnie mi o takie konkretne kontrzdanie chodziło :)))))))))))))
    
    A te minuty to chyba nie uwierzyłeś, że to takie prawdziwe minuty?
    Tak chciałem troszkę przejaskrawić :)
    
    Powinienem napisac "lata".
    
    A tak naprawdę to 8 sekund.
    
    Czyli o 60% wolniejszy.
    
    Kod skompresowany porównywalny do 7z (z korzyścią minimini dla 7z) ale depacker dłuższy, więc i plik wynikowy dłuższy o te 200 bajtów.
    
    Jak dla mnie exomizer2.0 wygrywa, przynajmniej na tym przykładzie.

    • dropzonedefl.xex
18. • 18: CommentAuthorBrix
    • CommentTime19 Mar 2012 23:03

     
    Nim tu wybuchnie totalny flamewar, naprawdę bardzo proszę o pomoc jak prawidłowo używać exomizera dla zwykłych danych binarnych :) (opis wyżej) Deflate jest naprawdę trywialnie prosty w użyciu i wcale nie aż tak wolny. Mam w tej chwili podejrzenia, że exomizer może być ciut lepszy, ale nie wiem jak go użyć :)
19. • 19:
       
      CommentAuthorjhusak
    • CommentTime20 Mar 2012 00:03 zmieniony

     
    Brix, nie tylko Ty masz problem z tym, gdzieś wczoraj widziałem wątek, jak ktoś też się męczył, ale jak dla mnie, to robił to po omacku.
    
    Są dwie rzeczy. Exomizer standardowo pakuje/depakuje od końca, oraz ma jakiś switch typu "LITERAL", który trzeba włączyć w depakerze - jest to ficzer, który powstał w wersji 2.0, ale żeby zachować kompatybilność z wcześniejszym 1.x jest możliwość wyłączenia tego "LITERAL".
    
    Flamewar nie wybuchnie, bo exomizer ma porównywalny objętościowo wynik, szybszy prawie dwukrotnie, krótszy depacker, potrzeba niecałe 200 bajtów na bufor do rozkodowania, a nie 3 strony. Twarde fakty.
    
    1 kb różnicy w narzucie pamięciowym na procki. To dużo.
    
    a depacker można na stosie zmieścić i jeszcze zostanie miejsca na stos właściwy.
20. • 20: CommentAuthor0xF
    • CommentTime20 Mar 2012 00:03

     
    Inaczej rozumiem "twarde fakty".
    
    gpl3.txt - 35147 bajtów
    
    exomizer - 12382 bajty + depaker 1 strona =~ 12.3 KB, rozpakowanie 128 ramek (2.6 sekundy)
    
    deflate - 11559 bajtów + depaker 2 strony =~ 11.8 KB, rozpakowanie 179 ramek (3.6 sekundy)
21. • 21: CommentAuthortebe
    • CommentTime20 Mar 2012 08:03 zmieniony

     
    Brix przyjrzałeś się przykładowi dołączonemu do paczki z madsem ?
    
    jest tam exomizer i procedury dekompresji (SuperPacker używa wersji SFX)
    
    w poniższym przykładzie znaki apostrofu są poprzestawiane, znaku \ nie powinno być, ale tak działa tutejsze forum
    
    

    org $2000-2
    
    	ins 'filename.pck',2	; skip 2 first bytes
    packed_end
    
    	org $b000
    main
    
    	mwa	#PACKED_END-4	exod_init_zp+1
    	mwa	#PACKED_END-3	opbase+1
    
    	jsr exod_decrunch
    
    	rts
    
22. • 22:
       
      CommentAuthorjhusak
    • CommentTime20 Mar 2012 09:03 zmieniony

     
    0xF, exomizer miał na celu poprawnie kompresować dane o charakterze 8 bitów/słowo (tak autor przynajmniej na stronie pisze). I tutaj drop zone jest takim przykładem. A co do zwykłego tekstu, to właśnie na zwykły tekst zoptymalizowany jest 7z czy każdy archiver, dlatego otrzymujesz wynik o pół kilo lepszy (ca 5 procent). Sporo. Niemniej jest to jedyny moment, gdzie jest lepiej. Porównaj sobie jeszcze inne gry, a nie tekstowe pliki.
    
    Z drugiej strony nie zamierzam Cię przekonywać :) bo wiem, że Ty wiesz.
    
    Post porównawczy miał na celu pokazanie, że zarówno exomizer jak i deflate są w ścisłej czołówce depakerów.
    
    I jeszcze raz podkreślę, że _dla mnie_ priorytetem jest prędkość, a tu jest spora różnica (w twoim przyklądzie 40%, w moim 60%, ale zawsze toć dziesiąt procent)
23. • 23: CommentAuthorBrix
    • CommentTime20 Mar 2012 09:03

     
    @tebe: aż sobie porównałem oryginalny kod z pakietu exomizer z przykładem w pakiecie mads.
    
    Czy czasem nie chodzi o to, że przykład z madsa jest dostosowany na konkretne użycie komendy exomizer (w pierwszym komentarzu, czego o zgrozo nie zauważyłem), czyli:
    
    exomizer mem -l0xLOAD_ADDRESS INPUT_FILENAME -o OUTPUT_FILENAME ?
    
    Bo sposób przekazania parametrów dla exod_decrunch był dla mnie tak kompletną abstrakcją, że naprawdę zgłupiałem. Ale jeśli to działa, to trzeba będzie spróbować :)
24. • 24:
       
      CommentAuthorjhusak
    • CommentTime20 Mar 2012 09:03

     
    Żeby zmądrzeć, trzeba najpierw zgłupieć :)
    Ten etap masz za sobą :P
    
    Teraz tylko do przodu!
25. • 25: CommentAuthorepi
    • CommentTime20 Mar 2012 20:03 zmieniony

     
    <reklama>
    0xF już wspominał, ale nie dostrzegłem zainteresowania: xebin
    </reklama> :)
26. • 26: CommentAuthorBrix
    • CommentTime20 Mar 2012 22:03

     
    W bólach i mękach chyba uruchomiłem ten depaker exomizera i okiełznałem paker, i wszystko wskazuje na to, że działa - przynajmniej na razie...
    
    Może wszystko jest gdzieś jasno opisane i do znalezienia, jak się człowiek mocno wgryzie w opasłe manuale czy będzie guglał całą noc. Ale jako kompletny amator naprawdę nie wiem co o tym sądzić.
    
    1. Opcja -l nie nadaje się do niczego, a nawet lepiej jak się poda "-l none", bo i dane są poprawnie rozpakowane (?!?!), a i jeszcze jest 2 bajty zysku. Choć możliwe, że gdzieś jeszcze robię błąd, bo w zasadzie dalej nie wiem do czego ta opcja właściwie służy. Pakowanie oczywiście z zalecaną przez depaker opcją "mem", ale nie wiem nic o tych trybach pracy exomizera.
    
    2. Exomizer sam wymyśla (wylicza?) sobie adres docelowy, z natury kompletnie bezsensowny i wstawia do spakowanego pliku (ostatnie dwa bajty). Nie rozumiem sensu takiego zachowania, chyba że znowu gdzieś robię jakiś błąd, albo exomizer nieco fiksuje pod wine.
    
    3. Adres docelowy (początek+długość) trzeba zmienić albo przez edycję hex pliku, albo z dodatkowo z poziomu programu (ostatnie dwa bajty). Tylko że bardziej mi to wygląda na jakiś trik niż celowe działanie.
    
    Na plus, że exomizer rzeczywiście depakuje szybciej i zużywa mniej pamięci.
    
    Ale nic z tego nie rozumiem :/
27. • 27: CommentAuthor0xF
    • CommentTime20 Mar 2012 22:03 zmieniony

     

    epi:

    <reklama>
    0xF już wspominał, ale nie dostrzegłem zainteresowania: xebin
    </reklama> :)

    
    

    jhusak:

    I jeszcze raz podkreślę, że _dla mnie_ priorytetem jest prędkość, a tu jest spora różnica (w twoim przykładzie 40%, w moim 60%, ale zawsze toć dziesiąt procent)

    
    Rozpakowanie gpl3.txt spakowanego xebin/flashpack2 trwa 51 ramek. Depaker ZTCP ma poniżej 100 bajtów, zużywa pamięci w sumie 4 bajty na stronie zerowej i rozpakowuje nieciągłe obszary. Nie można też narzekać, że jest zoptymalizowany pod kątem plików tekstowych.
    
    Stopień kompresji polepszy się, jak tylko Epi doda obsługę flashpack3.
28. • 28:
       
      CommentAuthorjhusak
    • CommentTime20 Mar 2012 23:03 zmieniony

     
    No, i tutaj zaczynamy podawać sensowne liczby. I jeszcze skoro już spakowałeś, podaj rozmiar pliku gpl3.txt po spakowaniu :)
    
    Poza tym 0xF - ja nie narzekam :) Puoszę mi nie imputować :)
    
    Zaglądałem dzisiaj na repo xebina - ale może zbyt krótko, bo nie doczytałem się w dokumentacji niczego o kompresji, z wyjątkiem że flashpack; jednak nie by...
    Zajrzałem jeszcze raz - i znalazłem - zaszyty wewnątrz pliku flashpack.d - dekompresor(y).
    
    potestuję na dropzone.
29. • 29: CommentAuthor0xF
    • CommentTime21 Mar 2012 11:03

     
    Jakieś 24 KB. Wiem, marny wynik. Podsumowałbym tak:
    
    - deflate - najlepszy stopień kompresji na 8-bit, absolutny standard na wszelkich platformach
    - flashpack - najszybsza dekompresja, nadaje się do małych plików (np. intra 1 KB)
    - exomizer - stopień kompresji zbliżony do deflate, zyżywa mniej zasobów
    
    Jest w czym wybierać. :)
30. • 30:
       
      CommentAuthorjhusak
    • CommentTime22 Mar 2012 00:03

     
    Howgh!
    
    (chociaż nie wiem, czy Winnetou jest trendy, passe, kaczi, cool, groovy, freshi, jezzi, edgy, kawaii, on the top, czy jeszcze inaczej)
31. • 31:
       
      CommentAuthorKaz
    • CommentTime18 May 2013 15:05

     
    Odsnieze watek, bo przeciez Tebe zrobil nowe wersje Super Packera 4.0 i 4.1:
    
    ->link<-
    
    

    4.0:
    kod przepisany od nowa, dodana nowa funkcjonalność, undo, redo, możliwość przemieszczania pojedyńczych segmentów góra/dół
    
    program trzyma dane w [USER]/Application Data/
    
    jeśli wystąpi jakiś błąd to najpewniej oznacza problem z parametrami które spowodowały błędy assemblacji, albo z kompresją danych, komunikat błędu będzie wyglądał wtedy mniej więcej tak: 'nie odnaleziono pliku @#seg2.obx'
    
    4.1:
    po poprawce, teraz checkboxy nie znikają pod WinXP
32. • 32:
       
      CommentAuthorxeen
    • CommentTime18 May 2013 22:05

     
    i nawet byla o tym nowinka ;)
    
    ->link<-
33. • 33:
       
      CommentAuthorKaz
    • CommentTime18 May 2013 23:05

     
    A artka porownujacego packery i depackery wciaz nie widze :)
34. • 34: CommentAuthorajcek
    • CommentTime22 May 2013 10:05

     
    Kilka zdań o moich doświadczeniach związanych z pakerami. Niestety nie dotyczą pakerów ze wsparciem dla xex-ow (może za wyjątkiem exomizera) ale może przydadzą się komuś kto tworzy grę lub demo i potrzebuje pakera który wewnątrz programu będzie rozpakowywał dane.
    
    Ten kto chciałby użyć pakera musi odpowiedzieć na pytanie co jest dla niego ważniejsze – stopień kompresji czy czas dekompresji ?
    
    Jeśli ważniejszy jest stopień kompresji to nie ma co szukać – deflater Fox-a nie ma tu żadnej konkurencji i jest najlepszym rozwiązaniem. Jedyny minus to duże zapotrzebowanie na pamięć dla procedury dekompresora (trzy strony buforów plus sam kod to dość sporo)
    
    Dla mnie istotny jest czas depacku i dlatego do tej pory używałem exomizera bo dawał gorszy ale nadal niezły stopień kompresji w stosunku do deflatera dysponując przy tym znacznie szybszym depackiem. Ostatnio postanowiłem przyjrzeć się temu co ma do zaoferowania platforma C64 w tym temacie i znalazłem paker który biorąc pod uwagę szybkość dekompresji ciężko będzie pobić. Paker nazywa się BongoCruncher i został napisany przez polskiego kodera o ksywie Wegi.
    
    Trochę suchych faktów:
    
    Oryginalny rozmiar exo bc
    Test01 – 36354 9661 11047
    Test02 - 14367 5917 6338
    Test03 - 5447 3736 3767
    
    Szybkość depacku dla BC
    test01 – 36 ramek
    test02 – 37 ramek
    test03 – 10 ramek
    
    Szybkość depacku dla exo
    test01 - 143 ramki
    test02 - 66 ramek
    test03 - 16 ramek
    
    Jak widać paker ma „ubicie” o jakieś 10% gorsze od exomizera ale depack od 70%-350% szybszy. Dodatkowo procedura depackera razem z buforami zajmuje niecałe 370 bajtów.
    
    Jeśli kogoś interesuje ten temat to polecam przyjrzeć się innym kompresorom z platformy c64. Rozwiązań jest sporo a to tylko kilka najpopularniejszych: Pucrunch, Byte Boozer, LZWVL, DOYNAX, Level Cruscher.
35. • 35:
       
      CommentAuthorxeen
    • CommentTime22 May 2013 11:05

     
    Dzięki. Akurat w tym momencie jest to dla mnie bardzo przydatne. Nie wiem czy dobrze rozumiem - ewentualne wykorzystanie decrunchera BC na Atari jest trywialne - skompiluje się bez problemu? Znalazłem tylko (tak, nie szukałem za długo) jakąs nakładkę na csdb, masz może źródła? 370 bajtów jest atrakcyjne. Błagam, nie wklejajcie "let mi google it for you" ;)
36. • 36: CommentAuthorxxl
    • CommentTime22 May 2013 12:05

     
    dodam, ze deflater Foxa jest dosc interesujacy nie tylko na stopien kompresji ale rowniez ze wzgledu na to, ze dane do dekompresji nie musza znajdowac sie w pamieci - moga byc pobierne bezposrednio z pliku.
37. • 37: CommentAuthorajcek
    • CommentTime22 May 2013 12:05

     
    Xxl – to akurat cecha prawie wszystkich pakerów z C64. Praktycznie każdy daje wsparcie dla leaderów.
38. • 38: CommentAuthorxxl
    • CommentTime22 May 2013 13:05

     
    dobra cecha, przydalo by sie zeby dekompresory na atari ja mialy.
39. • 39: CommentAuthorseban
    • CommentTime22 May 2013 15:05 zmieniony

     
    Hej!
    
    To ja wtrącę swoje 3-grosze ;) Ale od razu uprzedzam, to będzie opowieść z cyklu "bo ja to w w czterdziestym piątym ..." ;)
    
    Ponad 18-lat temu bawiłem się wszelakimi cruncherami na C64 to mało który potrafił rozpakować stream, większość z nich działa na zasadzie podobnej do naszych atarowskich Cruncherów typu Cruncher 5.0 by Magnus czy Code3 Cruncher by SoTe. Dlatego na C64 powstawały również specjalne wersje tychże samych cruncherów z dopiskiem "level", co miało sugerować że może depakować stream "w locie", tak jak wspominany level-crusher by MMS/Taboo. Jako ciekawostkę historyczną i uwieńczenie mojej walki z różnymi cruncherami z C64 mogę przypomnieć jeden wyników tych eksperymentów:
    
    ->link<-
    
    Ten "release" był spakowany kilkoma cruncherami z C64 (w scrollu crack-intra widać ich nazwy ;] ) oraz do kompletu amigowskim Power-Packerem.
40. • 40: CommentAuthorxxl
    • CommentTime22 May 2013 15:05

     
    pochwaliles sie to ... piszesz atrka :D
41. • 41: CommentAuthorseban
    • CommentTime22 May 2013 16:05 zmieniony

     
    To może zamiast pisać artka, lepiej poszukam jeszcze cruncher-a plikowego którego popełnił SoTe, na początku był on dość wolny przy dekompresji, ale potem powstała wersja Fast-Depacker, gdzie "dane bitowe" były trzymane razem a "dane bajtowe", wyrównane do granicy bajtów. Depacker zamiast więc pobierać 8 bitów ze spakowanego strumienia danych, mógł po prostu skopiować bajt. Nigdy nie porównywałem czasu dekompresji bo w tamtych latach nie bardzo było do czego, ale w porównaniu z ówczesną (1994) znaną mi konkurencją to była błyskawica :)
    
    Przy okazji jakiejś tam większej pracy pisania kodu na atari, miałem popełnić pecetowy port tego crunchera, ale lenistwo wygrało (i F7 w Atari800win), potem znalazłem PuCrunch, potem pojawił się exomizer :) no i skończyło się tylko na planach ;] jedyne co powstało to "zdissasemblowany" i lekko poprawiony depacker w wersji kompilującej się np. pod XASM :)
42. • 42: CommentAuthorbrx
    • CommentTime22 May 2013 21:05

     
    @seban: A słuchaj, czy exomizer (depaker albo dane dla niego) wymaga jakiegoś wyrównania w pamięci czy coś w tym stylu? Bo prawdziwe cuda mi się działy i dzieją, a najczęstsze pojawiające się mi błędy to albo bardzo powolny depak albo kompletne pominięcie dwóch pierwszych bajtów (ostatnich licząc od tyłu). Ostro kombinowałem z opcjami pakowania, wyrównaniami adresów, danych itp., ale końcowy rezultat (szybki i bezbłędny depak) wciąż jest w sumie nieprzewidywalny i dalej nie wiem co robię źle :/
43. • 43: CommentAuthor0xF
    • CommentTime22 May 2013 21:05

     
    Dwa pierwsze bajty programu na C64 to adres wczytywania.
44. • 44: CommentAuthorajcek
    • CommentTime22 May 2013 21:05 zmieniony

     
    Fox był pierwszy :-)
    
    @brx
    Teraz przeczytałem twój post 26. Twój problem to loadaddress. Exomizer w trybie mem (możliwe że w innych też) bezwzględnie tego wymaga. Jest to prosty nagłówek w pliku który składa się z dwóch bajtów zawierających adres pod który należy załadować dane i jednocześnie jest znacznikiem dla kompresora który mówi mu gdzie zdepakować dane. Sama wartość może być zmodyfikowana poprzez swich -l ale nagłówek musi istnieć. W twoim przypadku jako load addres były brane dwa pierwsze bajty pliku i dlatego miałeś ten adres ustawiony na jakieś losowe wartości w skompresowanym pliku.
    
    Exomizer nie wymaga żadnego wyrównania.
    
    Używa się go tak jak napisał Tebe w poście 21 przy założeniu, że procedura depackera pochodzi z pakietu Mads. Tu pojawia się jeszcze jedno ale. Procedura z mads-a ma na stałe ustawiony bufor roboczy na adres exod_tabl_bi = $BC40 co może prowadzić do błędów jeżeli w tym obszarze znajdą się jakiekolwiek dane np.: będziesz tam depackował. Należy to ustawić na adres wolnych 156 bajtów albo zastąpić czymś takim exod_tabl_bi :156 dta b(0).
45. • 45: CommentAuthorbrx
    • CommentTime22 May 2013 23:05

     
    Hm. Jak na złość teraz sporo szczegółów technicznych zapomniałem, musiałbym znowu zrobić parę testów i coś sprawdzić by być pewny tego co powiem. Ale nie wiem, jeśli nikt nigdy nie miał takich problemów z exomizerem jak wyżej opisane, to sprawa wydaje się nieco beznadziejna.
    
    Jeśli to występuje tylko u mnie, to jak dotąd dalej nie mam bladego pojęcia, gdzie robię błąd. Ten kawałek kodu napsuł mi sporo krwi i mam już trochę dość "rozgryzania" go - ale w końcu jako tako to cholerstwo mi obecnie działa, choćby w moim ostatnim projekcie...
    
    Pozostało mi chyba zacząć całą "zabawę" z exomizerem od nowa (czego już mam trochę dość), albo po prostu doklejać na początku danych do spakowania dwa np. zerowe bajty (taki jeden z moich "trików"), jeśli z jakich losowych (?) przyczyn okaże się, że inaczej depaker nie rozpakuje danych w całości, czyli minus dwa bajty :/
46. • 46: CommentAuthorbob_er
    • CommentTime22 May 2013 23:05

     
    1. exomizera używałem w unshaped - i nie miałem z nim żadnych problemów.
    2. dane pakowałem komendą: exomizer mem -l none -c in_file -o out_file
    3. potem już wg manuala rozpakowywałem.
47. • 47: CommentAuthortebe
    • CommentTime23 May 2013 07:05

     
    BRX Super Packer to nakładka dla Deflater i Exomizer, pozwala manipulować różnymi parametrami, ustawić adres ładowania, buforów, ładowanie pod ROM itp.
    
    generuje gotowy plik XEX, który można linkować z własnym projektem
48. • 48:
       
      CommentAuthorjhusak
    • CommentTime27 Feb 2014 10:02 zmieniony

     
    Może offtopicznie (bo nie do xex bezpośrednio), ale dodaję
    ->link<-
    lz4 depacker by xxl, fox
    
    

    xxl:

    unlz4 advantage:
    - three times faster then inflate
    - two times faster than exomizer
    - short decompresor (132 bytes)
    - no buffer
    
    if compressed data are in RAM - I prefer "inflate" - the best decompresor for Atari 8 bit! but if data are located in file I use unlz4 on the fly.