1

Temat: spakowane binarki

czy spakowane pliki binarne do ktorych dodawany jest dekompresor maja ograniczenia dotyczace adresow init i run? przykladowo - moze byc wieloblokowy plik binarny z kilkoma initami? czy mozna czesciowo pakowac taki plik binarny? np. blok 1 i 5 z 10 spakowane.

???

http://atari.pl/hsc/ad.php?i=1.

2

Odp: spakowane binarki

XXL napisał/a:

czy spakowane pliki binarne do ktorych dodawany jest dekompresor maja ograniczenia dotyczace adresow init i run? przykladowo - moze byc wieloblokowy plik binarny z kilkoma initami?

Jeżeli loader jest dobrze napisany i przetwarza dane strumieniowo, to takie ograniczenie nie ma prawa mieć  miejsca. Nie spotkałem loadera który nakładałby ograniczenia na ilość segmentów INIT. Wiele segmentów RUN nie ma sensu, bo ważny będzie tylko ostatni.

XXL napisał/a:

czy mozna czesciowo pakowac taki plik binarny?

A dlaczego miałoby tak nie być? Przykładowym narzędziem umożliwiającym takie coś jest chociażby Super Packer Jiriego Bernaseka. Z dzisiejszych narzędzi to oczywiście Super Packer od TeBe.

Ostatnio edytowany przez seban (2019-01-02 13:14:03)

3

Odp: spakowane binarki

Super Paker - bardzo porzadne narzedzie.

w zalaczniku przyklad test-lz4.atr gdzie dekompresor nie jest dodawany do spakowaneo pliku binarnego - w obydwoch przykladach spakowany zostal blok 2 i 4

roznica jest taka ze lz4 dekompresuje sie w czasie ladowania a exomizer po zaladowaniu

---
budowa pliku aby loader wykryl bloki spakowane:

normal:
0. 2000-2005
1. Init 2000
2. 2010-459F
3. 4800-4AD2
4. 5400-8303
5. Run 5800


0. 2000-2005
1. Init 2000
2. 2010-0000  (blok spakowany)
3. 4800-4AD2
4. 5400-0000  (blok spakowany)
5. Run 5800

Ostatnio edytowany przez xxl (2019-01-02 13:57:31)

Post's attachments

test-exo.atr 90.02 kb, liczba pobrań: 4 (od 2019-01-02) 

test-lz4.atr 90.02 kb, liczba pobrań: 2 (od 2019-01-02) 

test-normal.atr 90.02 kb, liczba pobrań: 1 (od 2019-01-02) 

Tylko zalogowani mogą pobierać załączniki.
http://atari.pl/hsc/ad.php?i=1.

4

Odp: spakowane binarki

exomizer ma pewnie założenia odgórne związane z platformą dla której powstał jako pierwszy, czyli C64. Jeżeli jest z nim jakiś problem, to sądzę że trzeba by porozmawiać z TeBe celem jego rozwiązania. Nie sądzę aby jakimś problemem było dekompresowanie danych spakowanych EXO podczas ładowania (via INIT). Być może trzeba przeorganizować tylko dane trochę (bo być może exomizer /nie sprawdzałem/ depakuje dane od końca, tak jak większość cruncherów z C64/C128 i stąd wynikają pewne ograniczenia).

Były czasy kiedy używało się wielu różnych programów kompresujących z różnych platform (C64, Amiga, Atari ST) i dekompresowało się wszystko w locie podczas wczytywania... jeden z przykładów. Binarka spakowana różnymi cruncherami/packerami, w tym: PowerPacker (Amgia), Fast Cruel (C64), Faces Exploding Cruncher (C64), X-Rated Power Cruncher (C64). Część danych dekompresuje się w locie podczas wczytywania. Pozostałe wtedy kiedy są potrzebne już po wczytaniu. Kod depackerów z C64 przeniesiony 1:1 z minimalnymi modyfikacjami. Do Amigowskiego Power Packer-a zastosowano dedykowany autorski dekompresor. Wszystko zawarte w tej binarce, która załaduje się pewnie z 99% dostępnych loaderów/inicjalizerów, a pewnie i nawet DOS-a o niskim MEMLO.

Ostatnio edytowany przez seban (2019-01-02 14:12:43)

5

Odp: spakowane binarki

ok. ale to znaczy ze dekompresor jest dolaczony i wykonany na INIT. Tu jest inny przypadek.

nie wiem czy prawidlowo rozumiem "dekompresowany w locie podczas wczytywania" napisz skad pobierane byly kolejne bajty spakowanego pliku z jakiego bufora? Ja obserwuje, ze dane najpierw sa ladowane a pozniej dekompresowane, jakis hint dzie moge podejrzec "dekompresowane w locie" ?

Ostatnio edytowany przez xxl (2019-01-02 15:06:59)

http://atari.pl/hsc/ad.php?i=1.

6

Odp: spakowane binarki

no tak. ale w przypadku np. SuperPacker by Jiri, to dekompresor jest tylko raz osadzony (na początku pliku) a potem tylko małe segmenty znanych zawierające konf. dekompresora dla danego segmentu i segmenty init wywołujące procedurę dekompresującą. Pewnie tak samo jest w przypadku LZ4 i SuperPacker by TeBe, ale już w przypadku użycia EXO (o ile dobrze pamiętam) to dekompresor jest dołączany do każdego segmentu danych. I zapewne wynika to ze specyficznych wymagań exomizera, nie mówię że nie dało by się inaczej tego zrobić, ale pewnie tak było szybciej/prościej, etc. Trzeba by zapytać TeBe.

Dołączanie depackera do loadera, nie wydaje mi się dobrym pomysłem... uwiązujesz loader do konkretnych wersji programów kompresujących czy depackerów, etc. Coś się zmieni w LZ4 czy EXO i zaraz będzie problem że XBIOS w takiej to a takiej wersji nie odczytuje poprawnie plików przygotowanych przez LZ4 v.131321 bo musi być LZ4 v.131313 ... a do kompletu o ile dobrze zrozumiałem tworzysz "nowy" format pliku, niezgodny z AtariDOS binary file. Przecież żaden loader nie odczyta segmentu typu $xxxx-$0000, no chyba że ktoś będzie pisał dedykowany loader do tego typu plików.

No chyba że właśnie taki masz zamiar, tzn. przygotować taki hermetycznie zamknięty system/format pliku, który jeżeli zostanie zastosowany w danej produkcji, to uwiąże ją raz na zawsze do Twojego rozwiązania. Jeżeli takie ma być założenie, to możesz robić oczywiście co zechcesz i osoby decydujące się na Twoje rozwiązanie też będą świadome tego. Dla części osób będzie to wada, dla części osób zaleta. Tutaj zapewne będzie tyle opinii ilu użytkowników.

Niestety nie jestem osobą która będzie w tym przypadku będzie mogła zachować jakąś sensowną neutralność wypowiedzi i nie bardzo umiem tutaj stanąć po jakiejś stronie, bo sami jako Slight robiliśmy produkcje "cało dyskowe" w formacie "żadnym" i uwiązanym do loadera znajdującego się na dysku, czy mechanizmów w nim zaszytych. Oczywiście wtedy wydawało się nam że to jedynie słuszna droga... bo i można sobie robić co chcesz na dysku, czytać jak Ci się podoba... i ograniczyć wpływ czynników zewnętrznych, takich jak rodzaj DOS-a czy systemu z którego nasza produkcja zostanie uruchomiona. Wtedy wydawało nam się to sensownym rozwiązaniem, szczególne gdy działo się coś podczas wczytywania... człowiek nie musiał wnikać co się dzieje pod spodem i jakie figle spłata DOS pracujący niżej.... wszystko było w naszych rekach, nawet system operacyjny był wtedy dla nas złem. W tym samym okresie była też druga strona barykady, która nie przejmowała się ładowaniem z dyskietki poszczególnych efektów czy części... nie przejmowano się loaderem, tylko korzystano z dobrodziejstw systemu operacyjnego czy to SIO czy CIO, a nawet i DOS-a... ładowano wszystko do dodatkowej pamięci i już po załadowaniu całej binarki w odpowiednie miejsca daną produkcję czy program odpalało się tylko z RAM nie przejmując się również tym co siedziało nisko w pamięci.

Jeżeli takie demo czy produkcja było w formacie plikowym to załadować się to dało ze wszystkiego właściwie, jedyne ograniczenie było takie że o ile same efekty nie wymagały dodatkowej pamięci, to EXT RAM był wykorzystany jako swego rodzaju RAM DYSK, nie przeszkadzał już żaden OS czy kosmicznie wolne czasy dostępu do danych z dyskietki. Cześć ludzi posiadających wtedy jakieś stacje równoległe (np. Karin MAXI drive) czy HDD mogła takie produkcja ładować nawet spod DOS-a. Prędkość ładowania produkcji z takich urządzeń była nieporównywalnie wyższa.

Patrząc na produkcję z tamtych czasów, każdy robił jak chciał i jak mu było wygodniej. My jako Slight, mieliśmy jakiegoś świra na punkcie pamięci i chcieliśmy aby nasze produkcje dało się uruchomić na komputerze z 64KB RAM. Poza tym dodatkową pamięć wykorzystywaliśmy podczas tworzenia do innych celów (albo jako ramdysk, albo jako przestrzeń w której Freezer zapisywał aktualny stan maszyny). Np. kompilowaliśmy wszystko do RAM-u na "żywca" z pod QA. Przed uruchomieniem efektu (który niszczył całą pamięć, a więc samo źródło, DOS-a i wszystko co się dało jeszcze zadeptać ;] ) wykonywało się "save state" maszyny z poziomu freezer-a do EXT RAM. Po uruchomieniu i stwierdzeniu gdzie są błędy i co trzeba poprawić odzyskiwało się stan maszyny z punktu ostatniego "zamrożenia" i pisało się kod dalej. Takie rozwiązanie powodowało że 64KB pamięci podstawowej stało się dla nas jakby domyślnym środowiskiem w którym będą uruchamiane nasze produkcje.

Jak więc widzisz trudno mi ocenić Twoje rozwiązanie w dobie obecnych "trendów" panujących na scenie, bo purystą i świętoszkiem nie byłem i orałem cały RAM łącznie z OS-em czy DOS-em ;) Czy dziś patrząc na to wszystko zrobiłbym to inaczej... pewnie tak... ale wtedy pewnie nie powstałoby Bitter Reality czy Overmind w takim kształcie w jakim powstały. A że obecnie ciężko je uruchomić i są produkcjami które stwarzają problemy z uruchomieniem... bo trzeba użyć SIO2PC albo rzeczywistej dyskietki i stacji dysków, i do kompletu nie da się tego uruchomić z SIDE czy HDD, etc. takie są koszty postępu chyba... chociaż wydaje mi się że i ten problem jest trochę sztucznie wygenerowany przez nowo zaprojektowany hardware, w którym pominięto możliwość rozwiązania tej "niekompatybilności", tzn. sądzę że na rzecz tego że te 1% produkcji,które nie ruszą na tym sprzęcie po prostu zignorowano możliwość rozwiązania tego problemu.

Tyle że to to nie był jakiś skomplikowany problem do rozwiązania i zapewne jest już rozwiązany jest od "n" lat, przez różnych ludzi i zapewne nie tylko w mojej szufladzie. Ale sprzęt dziś projektuje się tak aby był tani i mało problematyczny w produkcji... bo po co dodatkowe gniazdo, wtyczka, czy kawałek kodu, który będzie rzadko wykorzystany :P Na rzecz pełnej zgodności z przeszłością w i celu zwiększenia prostoty i komfortu używania nowych urządzeń, zrezygnowano z ciągnięcia za sobą historycznego ogona w postaci SIO.

Ostatnio edytowany przez seban (2019-01-02 15:37:50)

7

Odp: spakowane binarki

seban napisał/a:

Dołączanie depackera do loadera, nie wydaje mi się dobrym pomysłem... uwiązujesz loader do konkretnych wersji programów kompresujących czy depackerów, etc. Coś się zmieni w LZ4 czy EXO i zaraz będzie problem że XBIOS w takiej to a takiej wersji nie odczytuje poprawnie plików przygotowanych przez LZ4 v.131321 bo musi być LZ4 v.131313 ... a do kompletu o ile dobrze zrozumiałem tworzysz "nowy" format pliku, niezgodny z AtariDOS binary file. Przecież żaden loader nie odczyta segmentu typu $xxxx-$0000, no chyba że ktoś będzie pisał dedykowany loader do tego typu plików.

zaden loader nie dekompresuje spakowanych segmentow w locie ;-) (w locie - nie ma bufora) wiec to nie jest problem. dedkowany loader? xboot :-) poza tym dlaczego mam ograniczac rozwoj w tym kierunku... ktos bedzie chcial to uzyje nie to nie i nic sie nie stanie ;)

sluszna uwaga co do wersji - dodam identyfikator dekompresora ktorego loader ma uzyc w przypadku spakowanych segmentow

http://atari.pl/hsc/ad.php?i=1.

8

Odp: spakowane binarki

xxl napisał/a:

poza tym dlaczego mam ograniczac rozwoj w tym kierunku... ktos bedzie chcial to uzyje nie to nie i nic sie nie stanie ;)

no jak to dlaczego? ;-)

https://imgs.xkcd.com/comics/standards.png
^^^ src: xkcd

A tak na serio, Ja Ci niczego nie bronię ;) i nie chcę ograniczać niczego ani nikogo... z tyłu głowy miałem po prostu myśl że można osiągnąć to co chcesz w sposób nie wymagający zmiana formatu AtariDOS binary. Ale jeżeli tak jak proponujesz jest Ci wygodniej/lepiej/fajniej/bo tak, etc. to mi nic do tego ... :) XBIOS to Twoje dzieło i będzie podążało w kierunku w którym zechcesz :)

Ostatnio edytowany przez seban (2019-01-02 19:41:08)

9

Odp: spakowane binarki

niestety zbyd duzy kompromis. rozszerzenie standardu jest nieuniknione ;-)


...
nie mowie ze akurat takie :D

http://atari.pl/hsc/ad.php?i=1.

10

Odp: spakowane binarki

czekamy z utęsknieniem :)

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

11

Odp: spakowane binarki

od dawna dane bez naglowka wewnatrz uruchamialnch plikow a teraz spakowane bloki dekompresowane w momencie dostepu.

przegapiles z wimaginowanym przjacielem tyle waznych momentow ;-)

http://atari.pl/hsc/ad.php?i=1.

12

Odp: spakowane binarki

Konwencja Super Packer-a Jiri Bernaska została przeniesiona na PC, stąd nawet nazwa programu nie została zmieniona, aby nikt nie pomyślał że jest to inny program :)

Tak, Seban ma rację, EXO ma w sobie zaszyty dekompresor, ogólnie Super Packer nie ma, nie miał nic wspólnego z dekompresją strumieniową, przypisywaniu mu takich właściwości jest nieporozumieniem, niezrozumieniem konwencji, nadużyciem.

Do dekompresji strumieniowej są oddzielne wersje dekompresorów, są też inne parametry wejściowe podczas kompresji. Nie wszystkie kompresory są do tego zdolne (Deflater, Exomizer). XXL zobaczył na liście LZ4 i uznał że skoro jego jedna z wersji potrafi strumieniowo dekompresować to ta wersja z Super Packera też będzie.

Nie, Super Packer nie wspiera dekompresji strumieniowej i nigdy nie wspierał. Gdyby wspierał byłby tam jakiś 'checkbox' do zaznaczenia typu 'dekompresja strumieniowa'.

XXL usilnie pragnie zaszczepić zwyczaje sceny C64, a w tym pomoże mu bliższa znajomość z LZ4, SubSizer, Doynamite.

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

13

Odp: spakowane binarki

kolejny dekompresor dodany:


http://www.atari.org.pl/forum/viewtopic … 80#p258380

http://atari.pl/hsc/ad.php?i=1.

14

Odp: spakowane binarki

narzad do analizy plikow binarnch:


https://github.com/tebe6502/chkXEX

http://atari.pl/hsc/ad.php?i=1.

15

Odp: spakowane binarki

do paczki z mads-em dołączone są różne dekompresory

tutaj w załączniku dwie wersje dekompresji strumieniowej dla exomizera (ACME albo coś podobnego)

p.s.
Subsizer potrafi też pakować lepiej niż aPLib

Post's attachments

exomizer_stream.zip 5.51 kb, liczba pobrań: 2 (od 2020-02-03) 

subsizer.zip 26.16 kb, liczba pobrań: 2 (od 2020-02-03) 

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

16

Odp: spakowane binarki

subsizer potrzebuje 188 bajtowego bufora.

http://atari.pl/hsc/ad.php?i=1.