Code3 Cruncher
From Atariki
(Różnice między wersjami)
| Wersja z dnia 17:04, 9 wrz 2005 Miker (Dyskusja | wkład) ← Previous diff |
Aktualna wersja KMK (Dyskusja | wkład) |
||
| Linia 1: | Linia 1: | ||
| Code3 Cruncher (ver. 2.2) Autor: Adam "[[SoTe]]" Bienias | Code3 Cruncher (ver. 2.2) Autor: Adam "[[SoTe]]" Bienias | ||
| - | UWAGA!!! Powyższy paker jest przeznaczony tylko dla tych, którzy posiadają więcej niż 64kB!!! | + | UWAGA!!! Powyższy paker jest przeznaczony tylko dla tych, którzy posiadają komputery wyposażone w więcej niż 64kB pamięci RAM!!! |
| Code3 Cruncher jest typowym pakerem dwuprzebiegowym. Pierwszy przebieg pakuje dane algorytmem znacznikowym, natomiast drugi przebieg jest jedną z odmian Implodingu. Do tej pory po ludzikach krążył znany Cruncher 5.0 Magnusa, jednak biorąc pod uwagę szybkość pakowania oraz depakowania, a także stopień kompresji (nawet do 20% w stosunku do C5.0), Code3 Cruncher bije swego poprzednika na głowę. Pomimo, że C3C obsługuje się prawie identycznie jak C5.0 to można przytoczyć tu parę istotnych spraw: | Code3 Cruncher jest typowym pakerem dwuprzebiegowym. Pierwszy przebieg pakuje dane algorytmem znacznikowym, natomiast drugi przebieg jest jedną z odmian Implodingu. Do tej pory po ludzikach krążył znany Cruncher 5.0 Magnusa, jednak biorąc pod uwagę szybkość pakowania oraz depakowania, a także stopień kompresji (nawet do 20% w stosunku do C5.0), Code3 Cruncher bije swego poprzednika na głowę. Pomimo, że C3C obsługuje się prawie identycznie jak C5.0 to można przytoczyć tu parę istotnych spraw: | ||
| - | *a. ponieważ cruncher używa ramdysku zamiast dyskietki do przechowywania spakowanych danych (tak jak to miało miejsce w C5.0), zalecane jest użycie DOS'a, który nie rozpoznaje dodatkowej pamięci, w przeciwnym razie mogą się dziać dziwne rzeczy z linkerem; | + | *a. ponieważ cruncher używa ramdysku zamiast dyskietki do przechowywania spakowanych danych (tak jak to miało miejsce w C5.0), zalecane jest użycie DOS-a, który nie rozpoznaje dodatkowej pamięci, w przeciwnym razie mogą się dziać dziwne rzeczy z linkerem; |
| *b. istotną informacją jest to, że loader pakera rozpoznaje gęstość Double; | *b. istotną informacją jest to, że loader pakera rozpoznaje gęstość Double; | ||
| *c. C3C pakuje następujące obszary pamięci: $0480-$06FF, $0A00-$CFFF, $D800-$FFFF | *c. C3C pakuje następujące obszary pamięci: $0480-$06FF, $0A00-$CFFF, $D800-$FFFF | ||
| Linia 10: | Linia 10: | ||
| *e. paker nie ma możliwości przechowywania stosu (tak jak C5.0) | *e. paker nie ma możliwości przechowywania stosu (tak jak C5.0) | ||
| *f. średni offset jaki należy używać to: 4 ($0800), ewentualnie 3 ($0400), offset 1 ($0100) wskazany jest dla grafiki i muzyki (tylko) ale nie jest powiedziane, że najlepszy; | *f. średni offset jaki należy używać to: 4 ($0800), ewentualnie 3 ($0400), offset 1 ($0100) wskazany jest dla grafiki i muzyki (tylko) ale nie jest powiedziane, że najlepszy; | ||
| - | *g. paker został napisany na ATARI XE i nie był z żadnego komputera przepisany (gwoli informacji: imploding w C3C posiada jedno drzewo znacznikowe. Drzewo to wybrane doświadczalnie jest trochę podobne do SHANON-FANO i służy do oznaczania długości sekwencji, a do oznaczenia, że dany bajt nie zawiera się w żadnej sekwencji używany jest jeden bit: 0 - sekwencja spakowana, 1 - kolejne 8-bitów to ten właśnie bajt; | + | *g. paker został napisany na ATARI XE i nie był z żadnego komputera przepisany. Gwoli informacji: imploding w C3C ma jedno drzewo znacznikowe. Drzewo to wybrane doświadczalnie jest trochę podobne do SHANON-FANO i służy do oznaczania długości sekwencji, a do oznaczenia, że dany bajt nie zawiera się w żadnej sekwencji używany jest jeden bit: 0 - sekwencja spakowana, 1 - kolejne 8-bitów to ten właśnie bajt; |
| W wersji 3.0 offset jest ustawiony "na sztywno" a procedury (de)pakujące - nieco zmodyfikowane. Niektóre pliki lepiej poddają się kompresji przy użyciu niniejszej wersji. | W wersji 3.0 offset jest ustawiony "na sztywno" a procedury (de)pakujące - nieco zmodyfikowane. Niektóre pliki lepiej poddają się kompresji przy użyciu niniejszej wersji. | ||
| - | Istnieje również wersja C3C, używająca dyskietki jako bufora, nie wymaga więc ona obecności dodatkowej pamięci w komputerze. | + | Istnieje również wersja C3C używająca dyskietki jako bufora, nie wymaga więc ona obecności dodatkowej pamięci w komputerze. |
| + | |||
| + | [[Grafika:Code3_cruncher3_a.gif]] | ||
| + | |||
| + | [[Kategoria:Polskie programy]] | ||
| + | [[Kategoria:Oprogramowanie Atari 8-bit]] | ||
Aktualna wersja
Code3 Cruncher (ver. 2.2) Autor: Adam "SoTe" Bienias
UWAGA!!! Powyższy paker jest przeznaczony tylko dla tych, którzy posiadają komputery wyposażone w więcej niż 64kB pamięci RAM!!!
Code3 Cruncher jest typowym pakerem dwuprzebiegowym. Pierwszy przebieg pakuje dane algorytmem znacznikowym, natomiast drugi przebieg jest jedną z odmian Implodingu. Do tej pory po ludzikach krążył znany Cruncher 5.0 Magnusa, jednak biorąc pod uwagę szybkość pakowania oraz depakowania, a także stopień kompresji (nawet do 20% w stosunku do C5.0), Code3 Cruncher bije swego poprzednika na głowę. Pomimo, że C3C obsługuje się prawie identycznie jak C5.0 to można przytoczyć tu parę istotnych spraw:
- a. ponieważ cruncher używa ramdysku zamiast dyskietki do przechowywania spakowanych danych (tak jak to miało miejsce w C5.0), zalecane jest użycie DOS-a, który nie rozpoznaje dodatkowej pamięci, w przeciwnym razie mogą się dziać dziwne rzeczy z linkerem;
- b. istotną informacją jest to, że loader pakera rozpoznaje gęstość Double;
- c. C3C pakuje następujące obszary pamięci: $0480-$06FF, $0A00-$CFFF, $D800-$FFFF
- d. ciekawe ciapki, które mogą pokazać się po pakowaniu wstępnym oznaczają, że program nie zmieścił się w buforze;
- e. paker nie ma możliwości przechowywania stosu (tak jak C5.0)
- f. średni offset jaki należy używać to: 4 ($0800), ewentualnie 3 ($0400), offset 1 ($0100) wskazany jest dla grafiki i muzyki (tylko) ale nie jest powiedziane, że najlepszy;
- g. paker został napisany na ATARI XE i nie był z żadnego komputera przepisany. Gwoli informacji: imploding w C3C ma jedno drzewo znacznikowe. Drzewo to wybrane doświadczalnie jest trochę podobne do SHANON-FANO i służy do oznaczania długości sekwencji, a do oznaczenia, że dany bajt nie zawiera się w żadnej sekwencji używany jest jeden bit: 0 - sekwencja spakowana, 1 - kolejne 8-bitów to ten właśnie bajt;
W wersji 3.0 offset jest ustawiony "na sztywno" a procedury (de)pakujące - nieco zmodyfikowane. Niektóre pliki lepiej poddają się kompresji przy użyciu niniejszej wersji.
Istnieje również wersja C3C używająca dyskietki jako bufora, nie wymaga więc ona obecności dodatkowej pamięci w komputerze.
