Az új verzió már letölthető: ezzel kijavítható a Raid over Moscow fagyása a '-cleanup' paraméter használatával (amely a normál betöltésnek megfelelően állítja az 1. és 2. lapot - de a 3.-at még nem, mert a kicsomagoló ott fut - és a veremmutatót), a keret villogtatása pedig kikapcsolható a '-noborderfx' segítségével. Ezen kívül a kitömörítő kód néhány byte-al kisebb lett, és valamivel gyorsabb is, és jobban működik EP64-en.

Feltöltöttem egy újabb kisebb javítást.

Újabb javítás: a Z80-as kicsomagoló kódban volt néhány hiba.

Ezzel a továbfejlesztett kicsomagoló rutinnal bármilyen méretű epcompress-el tömörített adatot be lehet tölteni. A kód, a változók, és az olvasáshoz használt 256 byte hosszúságú puffer bárhol lehet a 0. vagy a 3. lapon, és a kód ROM-ban is futhat, mert nincsenek önmódosító részek. A memóriát egy előre lefoglalt szegmenseket tartalmazó lista alapján lehet használni, de automatikusan is tud foglalni EXOS 24 hívásokkal.
Hátrányok: nagyobb és lassabb, mint az eredeti kitömörítő, amely csak egy fix 64K-s címterületen működött lapozás nélkül; nem veszi figyelembe, ha egy szegmens megosztott. Hibák még lehetségesek.

A decompressData rutin hívásakor a következő regisztereket kell beállítani:

DE: a kicsomagolt adatokat erre a címre írja; a felső két bitnek nincs jelentősége, mert a szegmensszámokat az IY címen található táblázat határozza meg
HL: 256 byte-os puffer a tömörített adatok olvasásához, a 0. vagy 3. lapon. Csak az L változik, és amikor 0, akkor meghívja a readBlock rutint, hogy a puffert újra feltöltse. A readBlock nem változtathat meg semmilyen regisztert, kivéve a HL-t, amelyet új pufferre is beállíthat.
IX: a kitömörítő rutin által használható memória területre (változók stb.) mutat a 0. vagy 3. lapon. Az alsó byte-ot (XL) nem veszi figyelembe, mindig az XH00h-XHA3h területet használja.
IY: a felhasználható szegmenseket tartalmazó táblázatra mutat a 0. vagy 3. lapon. Ha egy szegmens száma 0, akkor azt EXOS 24 hívással lefoglalja, és tárolja a táblázatban; ha 1, akkor hibával visszatér (így korlátozható a lefoglalt memória mérete).

Sikeres visszatéréskor a DE és HL regiszterek az olvasott és írt adatoknak megfelelően módosulnak, az A és a carry bit nulla, a Z bit 1, az IY pedig az utolsó felhasznált szegmensre mutat a táblázatban.
Hiba esetén az A 255, a carry bit 1, a Z bit 0, és az IY arra a szegmensre mutat, amelynél a hiba történt.
Az 1. és 2. lapon található szegmenseket mindkét esetben visszalapozza.

Forráskód z80-asm (egyszerű PC-s Z80 assembler) és FENAS formátumban:

Ez érdekel valakit, vagy letörölhetem ?

Amúgy ha jól emlékszem, Geco is használt valami tömörítést a CPC-s Impossible Mission 2 átírásakor.

Használt, valami Gagyi tömörítést , vagy az ismétlődő byte-okat helyettesítettem 2 byte-tal, első a darabszám, második az érték, vagy csak a nullákat szedtem ki ily móson.

Használt, valami Gagyi tömörítést , vagy az ismétlődő byte-okat helyettesítettem 2 byte-tal, első a darabszám, második az érték, vagy csak a nullákat szedtem ki ily móson.

Ez az ismétlődő sorozatokat tömöríti, azaz az M byte-al korábban előfordult N byte hosszúságú sorozatot lehet másolni (mindkét érték bármi lehet 1 és 65535 között, tehát még 1 byte hosszúságú "sorozatot" is lehet kevesebb, mint 8 bitre tömöríteni, de akkor a távolság csak legfeljebb 8-16 byte lehet). Érdekes eset, amikor N>M, ezt fel lehet használni az egyszerű ismétlődő byte-ok, vagy "abababab..." típusú sorozatok tömörítésére.
A hatásfok hasonló a zip/gzip tömörítéshez, illetve az egyszerű "gzip -9" parancsnál gyakran jobb. A kicsomagolás sebessége jobbnak tűnik, mint például a DTF - a DTF betöltők, amiket eddig kipróbáltam, 2-3-szor lassabbak voltak, de ez lehet, hogy csak azért van, mert nem voltak megfelelően optimalizálva, vagy sok időt töltenek lemezműveletekkel.

az attus.ldr már gyorsabban tölt, mivel ez a legfejlettebb kicsomizómat tartalmazza. 

Igen, ezen meg is lepõdtem a múltkor. Kár, hogy ez anno nem került közforgalomba