1 Temat przez mono

  • mono
  • Starszy Atarowiec
  • Nieaktywny
  • Skąd: inąd
  • Zarejestrowany: 2007-08-20
  • Posty: 2,942

Mam sobie program, który zajmuje obszar $2000..$A10F. Potrzebuję skompresować ten program tak, żeby zajął maksymalnie obszar $2000..$9C1F.
Procedura dekompresji nie może używać obszaru pod jakimkolwiek ROM-em (ma to działać na Atari 400/800), jak i ekranu - najlepiej gdyby siedziała sobie na stosie, albo na stronie 6.
Ponieważ nie ma miejsca na osobny obszar danych skompresowanych, to najlepiej gdyby dekompresor podczas rozpakowywania nadpisywał obszar danych skompresowanych.
Czy możecie mi coś polecić i ew. objaśnić sposób używania (aż do dzisiaj nie miałem potrzeby używać takich narzędzi)?

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

mono's Strona

2 Odpowiedź przez tebe

  • tebe
  • tebe
  • Starszy Atarowiec
  • Nieaktywny
  • Skąd: Poznań
  • Zarejestrowany: 2002-04-06
  • Posty: 2,930

exomizer, w paczce z mads-em

albo Super Packer http://madteam.atari8.info/uzytki/sp.7z
masz wtedy możliwość przetestowania 3-ech wariantów (Deflater, Ezomizer, LZ4)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

tebe's Strona

3 Odpowiedź przez mono

  • mono
  • Starszy Atarowiec
  • Nieaktywny
  • Skąd: inąd
  • Zarejestrowany: 2007-08-20
  • Posty: 2,942

Dzięki tebe. Exomizer wystarczy w zupełności - robi dokładnie to, czego potrzebuję bez pisania jednej linijki kodu.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

mono's Strona

4 Odpowiedź przez lewiS

  • lewiS
  • lewiS
  • Administrator
  • Nieaktywny
  • Skąd: Slough
  • Zarejestrowany: 2002-03-19
  • Posty: 3,129

Dla potomnych: DJ Packer tez to potrafi (znaczy nadpisywac spakowane dane podczas rozpakowywania)

www.retrolemon.co.uk

5 Odpowiedź przez seban

  • seban
  • seban
  • Starszy Atarowiec
  • Nieaktywny
  • Skąd: -oo
  • Zarejestrowany: 2002-07-13
  • Posty: 2,995

to jeszcze przypomnę o starym pacekerze od SoTe...

http://atariki.krap.pl/index.php/Packer_v2.2

GitHUB: https://github.com/seban-slt

seban's Strona

6 Odpowiedź przez tebe

  • tebe
  • tebe
  • Starszy Atarowiec
  • Nieaktywny
  • Skąd: Poznań
  • Zarejestrowany: 2002-04-06
  • Posty: 2,930

exomizer 3.0

https://bitbucket.org/magli143/exomizer/wiki/Home

zmiana formatu zapisu danych, lepszy stopień kompresji, krótszy/szybszy dekompresor

dla zachowania kompatybilności z exomizer 2.0 należy użyć przełącznika -P0

exomizer mem -P0 -l0xLOAD_ADDRESS -c <INPUT_FILENAME> -o <OUTPUT_FILENAME>
*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

tebe's Strona

7 Odpowiedź przez gorgh Ostatnio edytowany przez gorgh (2018-06-11 13:58:46)

  • gorgh
  • Młodszy Atarowiec
  • Nieaktywny
  • Skąd: Wyszków
  • Zarejestrowany: 2008-02-25
  • Posty: 990

Tak w temacie: Tebe, może ty będziesz wiedział:
Nie za bardzo rozumiem, jak używać Exomizera do rozpakowywania plików z danymi w programie, chodzi mi o to, że najpierw pakuje na PC pliki z danymi i potem chce je wypakować w obszar niedostępny dla DOS. Nie widzę w pliku exodecrunch.asm możliwości ustawienia miejsca w pamięci w który ma się rozpakować plik.
Poza tym nie za bardzo rozumiem, czym jest "LOAD ADDRESS"
edit: chodzi mi o pliki z danymi, bez nagłówków dosowych

moja strona o grach retro
mój blog osobisty

gorgh's Strona

8 Odpowiedź przez tebe Ostatnio edytowany przez tebe (2018-06-11 17:45:24)

  • tebe
  • tebe
  • Starszy Atarowiec
  • Nieaktywny
  • Skąd: Poznań
  • Zarejestrowany: 2002-04-06
  • Posty: 2,930

te informacje odczytuje depacker ze spakowanego pliku, konkretnie z jego końca

load address, dwa bajty nagłówka z adresem pod który mają się ładować dane, normalnie je pomijasz

ins 'filename',2

albo ustawiasz '-l none' i już ich nie ma

p.s.
w załączniku przykład dekompresji dla najnowszej wersji exomizera

Post's attachments

exo3.zip 113.05 kb, liczba pobrań: 8 (od 2018-06-11) 

Tylko zalogowani mogą pobierać załączniki.
*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

tebe's Strona

9 Odpowiedź przez gorgh Ostatnio edytowany przez gorgh (2018-06-11 20:43:52)

  • gorgh
  • Młodszy Atarowiec
  • Nieaktywny
  • Skąd: Wyszków
  • Zarejestrowany: 2008-02-25
  • Posty: 990

mam problem z tym exomizerem
pakuję plik o długości 727 bajtów w ten sposób

 exomizer -l none -c dane.dta -o dane.pck

potem patrzę na ostatnie 2 bajty w pliku wynikowym i jest tam

 7e 06

a powinno być 

 d7 02

Co robię nie tak?
p.s. ten plik to czyste dane bez nagłówka

edit: jak rozumiem z twojego przykładu powinny tam być bajty znaczące długość pliku po rozpakowaniu

moja strona o grach retro
mój blog osobisty

gorgh's Strona

10 Odpowiedź przez tebe Ostatnio edytowany przez tebe (2018-06-12 21:48:17)

  • tebe
  • tebe
  • Starszy Atarowiec
  • Nieaktywny
  • Skąd: Poznań
  • Zarejestrowany: 2002-04-06
  • Posty: 2,930

spróbuj SUBSIZER, podobny stopień kompresji do EXOMIZER-a

subsizer -m -o filename.out filename.in
Post's attachments

subsizer.zip 40.57 kb, liczba pobrań: 6 (od 2018-06-12) 

Tylko zalogowani mogą pobierać załączniki.
*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

tebe's Strona

11 Odpowiedź przez gorgh

  • gorgh
  • Młodszy Atarowiec
  • Nieaktywny
  • Skąd: Wyszków
  • Zarejestrowany: 2008-02-25
  • Posty: 990

thnx

moja strona o grach retro
mój blog osobisty

gorgh's Strona

12 Odpowiedź przez tebe Ostatnio edytowany przez tebe (2018-06-19 10:04:32)

  • tebe
  • tebe
  • Starszy Atarowiec
  • Nieaktywny
  • Skąd: Poznań
  • Zarejestrowany: 2002-04-06
  • Posty: 2,930

z tego co zauważyłem dla kompresji MEM (-m) pakery rozpoznają nagłówek w stylu C64, 2 bajty z adresem pod który mają być ładowane dane, czyli próba kompresji pliku Atari $FFFF,adres,adres+len-1 skończy się obliczeniem adresu $FFFF+.....

musimy spreparować plik, dodać dwu-bajtowy nagłówek z adresem pod którym znajduje się blok danych, po kompresji otrzymamy blok z którego dwu-bajtowego nagłówka odczytamy pod jaki adres musimy załadować spakowany blok

teraz jedynie pozostaje wywołać SUBSIZER przez 'jsr decrunch' wszystkie informacje zostaną pobrane z końca spakowanego bloku, nie trzeba nic modyfikować jak w przykładzie który wyżej załączyłem (post #10)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

tebe's Strona

13 Odpowiedź przez mono Ostatnio edytowany przez mono (2019-04-13 19:42:21)

  • mono
  • Starszy Atarowiec
  • Nieaktywny
  • Skąd: inąd
  • Zarejestrowany: 2007-08-20
  • Posty: 2,942

@gorgh: Przećwiczone i działające (bo akurat potrzebowałem).
Mój plik.dta zawiera w jednym bloku dane i program który docelowo jest w $A000. I to są dane RAW bez żadnych nagłówków (nie używam kompresji raw, bo musiałbym użyć dekompresora strumieniowego, a to mi akurat nie odpowiada tutaj). Dekompresję przeprowadzam z pamięci w miejsce docelowe i ja akurat używam dekompresji wprzód.
Robię:

$ exomizer mem -f -l none -o plik.exo plik.dta@0xa000

A w kodzie wołam procedurę decompress z adresem danych wejściowych w YX:

        ldx #<data
        ldy #>data

decompress:
        stx get_crunched_byte.?addr+1
        sty get_crunched_byte.?addr+2
        jmp decrunch

get_crunched_byte:
?addr   lda $FFFF
        inc ?addr+1
        sne
        inc ?addr+2
        rts

        icl "krilldecr.asx"

data    ins "data.exo"

Dane wylądują w $A000, bo ten adres znajduje się na początku bloku danych (już skompresowanych - wstawia go kompresor).
Uwaga co do krilldecr.asx - adresy na ZPG możesz ustalić jak Ci się podoba.
Exomizer v2.0.11.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

mono's Strona

14 Odpowiedź przez gorgh

  • gorgh
  • Młodszy Atarowiec
  • Nieaktywny
  • Skąd: Wyszków
  • Zarejestrowany: 2008-02-25
  • Posty: 990

o super, podziękował

moja strona o grach retro
mój blog osobisty

gorgh's Strona

15 Odpowiedź przez Nitro

  • Nitro
  • Referent
  • Nieaktywny
  • Zarejestrowany: 2008-09-01
  • Posty: 203

Jeżeli komuś nie zależy na szybkości[jeśli potrzeba dekompresji strumieniowej(realtime depack podczas wczytywania ze stacji dyskietek) to są inne packery] to polecam powalczyć z Exomizerem, na C64 to złoty standard kompresji danych i nic do tej pory go nie przebiło. Myślę, że moją myśl można rozszerzyć na wszelakie platformy z 6502 na pokładzie.