"dtf -cr -lz" esetén az adat végén található két byte azt adja meg, hogy kicsomagolás után mennyivel lesz nagyobb a méret.
De ha a program nem utántölto"s, hanem az összes tömörített adatot a memóriában tárolja (pl. Sorcery+), akkor például az is megoldás lehet, hogy minden egyes file külön tömörítve legyen "epcompress -raw -m2 -9"-el, és aztán azokat INCBIN direktívákkal a programba lehet fordítani, és a programkód címkék alapján tudhatja, hogy az egyes tömörített adatblokkok hol kezdo"dnek és milyen hosszúak.

Köszi, és jól rémlik, hogy azért kell a különbséget eltárolni, mert a kicsomagolás az eredeti adatblokk végéről kezdődik?
Azért gondoltam a kötegelt megoldásra, mert úgy gondoltam, hogy így a fájl mérete kisebb lesz,mintha külön-külön csomagolnám be a 28 file-t.
Jaja, nagyjából így csináltam a Sorcery+-nál is, csak az INCBIN nem jutott eszembe , helyette írtam egy kis assembly rutint, ami egymás mögé másolta őket, lehet mindig meg kéne kérdeznem téged, ha valamire kódot szeretnék írni, egy csomó időt megspórolnék

Fasza a teszt, köfi szépen. Le is mentettem magamnak a teszteredményeket, és a forrásokat is
Nem is lassabb sokkal az -m2, mint a többi kitömörítő, és több file esetén ezzel lehet a legtöbb helyet megspórolni.

Valószínűleg megoldható, bár egyelőre talán csak az -m2 kitömörítő rutint cserélem le az újabbra.

Nekem jó így is , csak eszembe jutott, ha már az EPCompress tudja a -lz-t, akkor megoldható-e, hogy a többi formátumot is az kezelje.
Fasza a gyorsulás, 2-3 tized mp (kivéve a Beach Head-nél), lassan lenyomja a DTF -lz-t is

Olyan EPcompress változat már van, ami a dtf -lz algoritmust is tudja használni, és természetesen tartalmazza az új, optimalizált betöltő kódokat is. Csak le kell fordítani, és feltölteni.
Időközben arra is rájöttem, miért működött hibásan az aPack kitömörítő: 32768 byte-nál nagyobb file esetén fordul elő hiba, amit kb. 5 byte-al nagyobb Z80 kóddal, vagy a tömörítő (amiből már van saját, az eredetinél kis mértékben hatékonyabb változatom is) kisebb módosításával lehetne elkerülni.

Lassan több tömörítő program lesz EP-re, mint PC-re 
Na jó, most semmi új tömörítő algoritmus nem került be a csomagba, de ami van, az tökéletesedik

Már azt hittem eltűnt az oldal, pár napja nem sikerül elérni, gondoltam megpróbálom az enterpriseforever.com-t, s lőn világosság
Tuti már megint nem olvastam el valamit 

Ezt logikailag ide valahova érdemes beszúrni?

Ezen kívül fordítottam 64 bites Linux verziót is, bár ennek valószínûleg nem sok jelentõsége van.

Lefordítottam én is magamnak (UHU 2.2, most 32 bit) a forrásbéli dtf.cpp -t. Ennek sincs túl sok jelentõsége. A létrejött futtatható mérete nálam 372,3 Kb. Úgy néz ki, hogy fut.
A te kész dtf-linux binárisod mérete meg 739,5 Kb.

Az enyim hibás, vagy csak egyszerûen jobban tömörített a fordítóm?
 

Ez gondolom 32 bites ? Az nekem is hasonló méretû (157780 byte), de a 64 bites verzióval az -lz2 tömörítés több, mint 30 százalékkal gyorsabb.

Kiváncsiságból megnézem a gentoo 64-en a sebességét.
Habár az UHU -t jobban kedvelem, de a 64 bites változatához nem tudok nvidia drájvert rakni, ezért használom 32 bites módban.

Köszönjük a részletes leírást!
Plusz kérdés: a PC-s Zip és társai mennyivel bonyolultabbak még ennél?