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.

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.

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.

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.

no jak to dlaczego? ;-)

^^^ 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 :)

czekamy z utęsknieniem :)

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.

narzad do analizy plikow binarnch:

https://github.com/tebe6502/chkXEX