Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
atari.area forum » Programowanie - 8 bit » inflate
Zaloguj się lub zarejestruj by napisać odpowiedź
Zoptymalizowałem procedurę dekompresji inflate. Teraz zajmuje ona niecałe dwie strony pamięci (poprzednio prawie trzy) i wykonuje się nieco szybciej.
Można pobrać ze strony:
http://atariarea.krap.pl/x-asm/inflate.html
Polecam, bardzo ładna, zgrabna, i kolorrrrowa :)
Fox, to nowsze niż to co mi podsyłałeś?
Aha, jeśli się komuś przyda, mini programik do kompresji danych do rozpakowywania procką Foxa: http://eru.nutki.com/a8/zipper.c.
Kompilujemy z -lz ofkorz (linux/cygwin/mac).
Szacuneczek :)
ps. ja tylko dodam ze pakowac mozna na uniksoidach zwyklym gzipem (opcje -9n), po czym odciąć 10 bajtów z przodu pliku i 8 z konca :)
np takim skrypcikiem:
#!/bin/sh
# zipper.sh
# usage: zipper.sh input_filename output_filename
set -e
if [ $# -eq 2 ]; then
TEMPFILE=$(mktemp /tmp/zipper.XXXXXXXXXX)
gzip -c9n $1 | dd of=$TEMPFILE bs=1 skip=10
dd if=$TEMPFILE of=$2 bs=1 count=$(expr $(stat -c %s $TEMPFILE) - 8)
exit 0
fi
echo "zipper.sh input_filename output_filename"
exit 1Pewnie niespecjalnie przenośny jest, ale działa na linuxach :)
Chętni sobie przerobią na bsd czy cotam....
Eru: tylko dwa bajty krótsze, poza tym to samo. Programik do kompresji jest dołączony, działa identycznie jak Twój.
jakie parametry kompresji należy ustawić dla 7z aby można było to dekompresować przez INFLATE ?
mój przerobiony zipper.sh Mikeya:
#!/bin/sh
# zipper.sh
# usage: zipper.sh input_filename output_filename
_7Z=/sw/bin/7z
set -e
if [ $# -eq 2 ]; then
TEMPFILE=$(mktemp /tmp/zipper.XXXXXXXXXXXX).gz
cat $1 | $_7Z a -tgzip -mx=9 -si $TEMPFILE
dd if=$TEMPFILE of=$2 bs=1 skip=10 count=$(expr $(stat -f "%z" $TEMPFILE) - 18)
exit 0
fi
echo "zipper.sh input_filename output_filename"
exit 17z -tgzip robi gzipa, ale trzeba to robić przez pipe ('|') bo inaczej ponoć są dołączane nazwy plików, a tego nie chcemy.
haczyk polega na tym co robi to 'dd' - wycina pierwsze 10 i ostatnie 8 bajtów.
moje wcześniejsze posty dotyczące problemów z najnowszym INFLATE należy uznać za nie byłe, podejrzałem w końcu jakie nagłówki znajdują się w pliku i zrozumiałem gdzie leży problem, umieszczałem spakowany plik tuż za INFLATE.ASM, który rezerwuje sobie pamięć dla INFLATE_DATA przez ORG*+ i w ten sposób spakowane dane wczytywane były w obszar $c000,$d000 co niespecjalnie się udawało ;)
w ramach zadośćuczynienia popełnie nakładke na 7z aby wypluwał pliki spakowane GZIP-em z metodą DEFLATE 7z (dla Windows-a)
proponuje zastąpić ORG *+ przez EQU, wtedy można łączyć INFLATE z jakimkolwiek programem bez potrzeby ponownego ustawiania ORG-a
; Data for building trees
literalSymbolCodeLength equ inflate_data
controlSymbolCodeLength equ literalSymbolCodeLength+256
; Huffman trees
nBitCode_clearFrom equ controlSymbolCodeLength+CONTROL_SYMBOLS
nBitCode_totalCount equ nBitCode_clearFrom
nBitCode_literalCount equ nBitCode_totalCount+2*TREE_SIZE
nBitCode_controlCount equ nBitCode_literalCount+TREE_SIZE
nBitCode_literalOffset equ nBitCode_controlCount+2*TREE_SIZE
nBitCode_controlOffset equ nBitCode_literalOffset+TREE_SIZE
codeToLiteralSymbol equ nBitCode_controlOffset+2*TREE_SIZE
codeToControlSymbol equ codeToLiteralSymbol+256
inflate_data_end equ codeToControlSymbol+CONTROL_SYMBOLShttp://madteam.atari8.info/uzytki/def7z.7z
Autonomiczna nakładka na program 7-Zip realizująca kompresję plików do formatu GZIP z użyciem nowej wydajniejszej wersji algorytmu DEFLATE (dodatkowo z pliku wynikowego usuwane są nadmiarowe bajty). Dekompresji dokonujemy procedurą INFLATE.ASM
Autonomiczna tzn. że nie potrzebuje być uruchamiana w towarzystwie jakichkolwiek innych programów, kompresor 7z.exe zaszyty jest w środku programu, na czas kompresji jest on zapisywany do katalogu z którego uruchomiono def7z.exe, wykonywany jest odpowiednio spreparowany BAT
p.s.
uaktualniłem plik DEF7Z.EXE, teraz nie wystąpią problemy związane z użyciem pliku przez inny proces, można kompresować z poziomu BAT-a wiele plików do nowego formatu DEFLATE, nie wystąpią też żadne nadmiarowe komunikaty związane z dokonywanym procesem kompresji i kasowaniem plików pomocniczych
tebe: Rozumiem, że def7z.exe wykonuje skrypt eru pod windowsem? (tak pytam, bo nie wiem czy beszczelnie używać tego co napisał eru czy męczyć Ciebie o składnie polecenia której użyłes w tym generowanym bat)
tebe: Rozumiem, że def7z.exe wykonuje skrypt eru pod windowsem? (tak pytam, bo nie wiem czy beszczelnie używać tego co napisał eru czy męczyć Ciebie o składnie polecenia której użyłes w tym generowanym bat)
tak, ogólnie DEF7Z wywołuje taki BAT
7z.exe a -tgzip -mx9 output_archive input_file
potem usuwane są nadmiarowe bajty z początku i końca archiwum 7z i tak powstaje plik gotowy do użycia z INFLATE Fox-a
Po 10 latach przerwy dzisiaj parę ulepszeń:
- procedura skrócona z 509 do 501 bajtów
- zainicjalizowane dane są teraz stałe, łatwiej jest więc umieścić procedurę w ROMie
Do pobrania: https://github.com/pfusik/zlib6502
Wersja w cc65 została uszkodzona pół roku temu. Zgłosiłem i jest już poprawiona. Planuję zaktualizować procedurę w cc65.
Przyda się! Dziękuję!
Dzięki! :)
Dzisiaj:
- urwałem jeszcze dwa bajty
- zaktualizowałem procedurę w cc65
- znalazłem narzędzie "Zopfli", które przy pobieżnych testach daje stopień kompresji wyższy niż 7-Zip i KZIP, a w dodatku potrafi zapisać goły strumień DEFLATE - szczegóły na https://github.com/pfusik/zlib6502
az milo czytac. kawal porzadnie napisanego softu przy okacji przydatnego :-)
Dzisiaj zgłoszono pierwszy błąd w 17-letniej historii tego kodu. Błąd ujawnia się tylko w przypadku szczególnych danych. Wydaje mi się mało prawdopodobne, żebyście natrafili na takie dane przypadkiem. Błąd poprawiłem, przy okazji skracając kod o 7 bajtów. Ale nie za darmo: poprawiony kod jest trochę wolniejszy - zmierzyłem 3% na GPL v3 skompresowanej zopfli.
Polecam aktualizację: https://github.com/pfusik/zlib6502
Czy ta procedura wchodzi w skład xunzipa? Można liczyć na uaktualnienie?
Tak, ta procedura jest podstawą xunzipa. O uaktualnienie trzeba pytać Epiego.
Dzisiaj poprawiłem drugi błąd, też mało prawdopodobny. Ta poprawka kosztowała 16 bajtów kodu, 1 bajt niezainicjalizowanych danych i 8% szybkości.
Mam pewne wątpliwości co do pogarszania sprawności dekompresora, aby mógł poradzić sobie ze strumieniami, których nikt przez 17-lat jego istnienia nie napotkał.
Czy byłaby szansa, aby wyróżnić w kodzie zbiór ficzerów pozwalających na warunkową kompilację włączającą lub wyłączającą wsparcie dla tych egzotycznych danych wejściowych? Może nawet dałoby się napisać narzędzie, które analizując skompresowany strumień generowałoby odpowiednie makra, coś jak optymalizacja RMT.
To tylko 11% wolniej. Gdzie Ci się spieszy? W Numenie było jeszcze wolniej i jakoś nie wiało nudą między efektami.
Między efektami nie... ;-)
w sumie to można wyobrazić sobie taki ficzer który skróci dekompresor i uprości go ekstremalnie na podstawie danych jakie ma dekompresować ;)
Hej, cieszę się, że tu jesteście z przyjaciółmi. Używałem tego pompowania wielokrotnie z programowaniem. Pracowałem z niektórymi optymalizacjami, aby przyspieszyć napompowanie dużymi fragmentami pamięci.
To właśnie próbowałem i wydaje się zmniejszać czas nadmuchiwania.
getWord
jsr getByte
tax
; Read 8 bits
getByte ; Using this version of get byte + get next input byte is a huge speed up.
lda #$80
getBits_loop
lsr getBit_buffer
bne no_get_next_input_byte
jsr Get_Next_Input_Byte
no_get_next_input_byte
ror @
bcc getBits_loop
rts
; Read one bit, return in the C flag
Get_Next_Input_Byte
pha
lda (inputPointer),y
inw inputPointer
sec
ror @
sta getBit_buffer
pla
rts
Gdzie jest etykieta „fetchCode_nextBit” dodaj:
fetchCode_nextBit
lsr getBit_buffer
bne GetBit_End_Fetch
jsr Get_Next_Input_Byte
GetBit_End_Fetch
Hej, cieszę się, że tu jesteście z przyjaciółmi. Używałem tego pompowania wielokrotnie z programowaniem. Pracowałem z niektórymi optymalizacjami, aby przyspieszyć napompowanie dużymi fragmentami pamięci.
To właśnie próbowałem i wydaje się zmniejszać czas nadmuchiwania.
getWord
jsr getByte
tax
; Read 8 bits
getByte ; Using this version of get byte + get next input byte is a huge speed up.
lda #$80
getBits_loop
lsr getBit_buffer
bne no_get_next_input_byte
jsr Get_Next_Input_Byte
no_get_next_input_byte
ror @
bcc getBits_loop
rts
; Read one bit, return in the C flag
Get_Next_Input_Byte
pha
lda (inputPointer),y
inw inputPointer
sec
ror @
sta getBit_buffer
pla
rts
Gdzie jest etykieta „fetchCode_nextBit” dodaj:
fetchCode_nextBit
lsr getBit_buffer
bne GetBit_End_Fetch
jsr Get_Next_Input_Byte
GetBit_End_Fetch
Have not been here in awhile. I did manage to speed up inflate times by reducing some of the JSR calls and placing a MACRO that does the some job. But it does take up slight larger space. I believe I removed getByte, GetBit, etc. Used Assembler Options with a flag depending how much I wanted to speed up things. For small chunks it does not make much of a difference. But If I want to compress a large game onto a 16K ROM, that deflates to 25K RAM. It shaves a few seconds off.
SPEEDUP_1 = 1
:
:
IFT SPEEDUP_1 = 0
jsr getBit
ELI SPEEDUP_1 = 1
lsr getBit_buffer
bne no_get_next_input_byte
jsr Get_Next_Input_Byte
no_get_next_input_byte
ELI SPEEDUP_1 = 2
lsr getBit_buffer
bne no_next_byte_for_get_bit
pha
lda (inputPointer),y
inc inputPointer + 0
bne ip_l1
inc inputPointer + 1
ip_l1
sec
ror @
sta getBit_buffer
pla
no_next_byte_for_get_bit
EIF
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Programowanie - 8 bit » inflate
Wygenerowano w 0.034 sekund, wykonano 73 zapytań