Valóban, az eddigi információk alapján már sikerült egyszerû DTF tömörítõ és kitömörítõ programot írni PC-re :)Tudom, a DTF kifejezetten EP-ra készült, de azért érdekelne, a RAR-hoz vagy a ZIP-hez viszonyítva milyen hatékonysággal tömörít. Ha majd ott tartunk, lehetne errõl pár szó?
Tudom, a DTF kifejezetten EP-ra készült, de azért érdekelne, a RAR-hoz vagy a ZIP-hez viszonyítva milyen hatékonysággal tömörít. Ha majd ott tartunk, lehetne errõl pár szó?Ezt te magad is kipróbálhatod! Kicsomagolsz egy DTF-fel tömörített programot és újratömöríted PC-n amivel akarod, aztán összehasonlítod őket.
Talán a ZIP-et meg lehetne próbálni átírni EP-re isCsak kéne valami részletes bájt-bit szintû algoritmus leírás...
, bár sok gyakorlati haszna ma már nem lenne.Azért jó lenne egy olyannal kompatibilisnek lenni, ami manapság is ismert a PC-s világban.
Csak kéne valami részletes bájt-bit szintû algoritmus leírás...:smt026 Még nem próbáltátok ki ezek szerint a lemezes betöltőmben lévő tömörítőt!
Ha már van Z80-as forrásszöveg, az se baj :-)
Az oroszoknál láttam emlegetni ZIP-et Spectrumra, nem tudom, hogy az tényleg az, vagy csak annak neveztek el valami saját tömörítõt...Azért jó lenne egy olyannal kompatibilisnek lenni, ami manapság is ismert a PC-s világban.
Egy pl 840K-s lemezek lementése image-be. Ezt utána be kéne zippelni, hogy egy 720-ason át lehessen vinni PC-re.
batman.apl 44288
batman.dtf 38298 (ATTUS.LDR EP-n)
batman2.dtf 38176 (dtf.cpp PC-n)
batman2.gz 30684 (gzip -9)
batman.exo 30037 (exomizer 2.0 beta6, PC-ről 8 bites gépekre tömörítő program)
batman.gz 29936 (7za a -tgzip -mx=9 batman.gz batman.apl)
batman.m1 29721 | ezek mind az én PC-ről 8 bites gépekre tömörítő programom
batman.m2 29705 | különböző algoritmusokat választva; a "0" típusú formátum
batman.m0 29189 | megegyezik az epimgconv által használt tömörítéssel
batman.lzma 27879 (az LZMA a 7-zip alapértelmezett tömörítési algoritmusa)
Természetesen más file-ok esetén eltérő eredmények lehetnek.Csak kéne valami részletes bájt-bit szintû algoritmus leírás...A ZIP kitömörítést elvileg meg lehet oldani EP-n, illetve már van ilyen program pl. C64-re. Az epimgconv által használt formátum kb. hasonló bonyolultságú, tehát a zip (Deflate) is hasonló mértékben lenne lassú, de valószínűleg némi optimalizálással lehetne javítani a sebességen. A tömörítés már nehezebb, valószínűleg csak a PC-s programoknál gyengébb hatásfokkal lehetne tömöríteni, és így is lassan.
Ha már van Z80-as forrásszöveg, az se baj :-)
Az oroszoknál láttam emlegetni ZIP-et Spectrumra, nem tudom, hogy az tényleg az, vagy csak annak neveztek el valami saját tömörítõt...
A tömörítés már nehezebb, valószínûleg csak a PC-s programoknál gyengébb hatásfokkal lehetne tömöríteni, és így is lassan.Szerintem gyengébb hatásfok is bõven elég az EP programokhoz. Sõt, ha csak minden tömörítés nélkül átrakja ZIP-be, az is. (A PC kompatibilis EP formátum lenne a poén.) A kicsomagolás meg azért lenne jó, mert akkor a netrõl letöltött EP játékok egybõl mehetnének az EP-be - már ha van erre igény. (Viszont Laci programjai RAR-ban vannak fent, de ha esetleg lenne EP-s ZIP kitömörítõ, szerintem tutira kicserélné mind a párszáz programot ZIP-re. :smt043 )
A game crackerek meg ezt használják. :lol: (http://thor.hu/download.php?view.6514)
Az epcompress programot próbálta valaki ? Bár valószínûleg nem igazán hasznos :)Az a baj, hogy túl sok nagyméretû 5-ös fejlécû program nincs...
Az a baj, hogy túl sok nagyméretû 5-ös fejlécû program nincs...Valóban, a legtöbb program több kisebb file-ból áll, még akkor is, ha ezeknek a mérete együttesen is kisebb, mint 47.75K. Nem tudom, hogy a DTF-ben van-e erre valamilyen automatikus megoldás, vagy minden programhoz külön kellett egyedi betöltőt készíteni ?
Amit így hirtelen találtam: Nodes of Yesod, Starstrike 3D, Beach Head, ezek mûködnek szépen.Ezeken kívül még a korábban már említett Batman is működik, mert a batman.apl külön is futtatható, illetve az alábbi egy file-osra átalakított Sorcery változat is (bár az ilyen átírás kissé nehézkes megoldás). Természetesen az epimgconv-al konvertált képek is tömöríthetők ezzel a programmal; a hatásfoka valamivel rosszabb, mint az epimgconv beépített tömörítésének, viszont a kicsomagolás gyorsabb.
Ugyanebbe a sorozatba tartozik a Raid over Moscow, itt viszont a fõ program lefagy kitömörödés után :-( végigpróbáltam 1-9-ig a tömörítési fokokat, néha van, hogy a kockás induló kép még bejön.Itt az okozta a problémát, hogy a játék nem inicializálja a veremmutatót induláskor, hanem feltételezi, hogy az a 2-es lapon az EXOS veremre mutat (pl. 0B217h). A kitömörítő azonban megváltoztatja a lapozást (ami még nem lenne probléma, mert ezt a játék még újra beállítja, 128K-s gép esetén F8,F9,FA,FA-ról FC,FD,FA,F8-ra), és a verem a 3-as lap végére kerül.
de a kitömörítõt is meg lehetne változtatni (kisebb méretnövekedés árán), hogy a "normál" betöltés utáni állapotot a lehetõ legpontosabban visszaállítsa.Ez egy szimpatikus ötlet! (esetleg berakni egy paramétert, hogy melyik betöltõt csapja hozzá)
Ez egy szimpatikus ötlet! (esetleg berakni egy paramétert, hogy melyik betöltõt csapja hozzá)Valóban, esetleg az is választható lehetne, hogy legyen-e keretszín effektus, vagy hogy a kitömörítő sebességre vagy méretre legyen optimalizálva. Az egyébként fontos, hogy a 3-as lapon milyen szegmens van egy program indításakor ?
esetleg az is választható lehetne, hogy legyen-e keretszín effektusGondolatolvasó vagy másodállásban? :ds_icon_cheesygrin:
Feltöltöttem egy újabb kisebb javítást.Újabb javítás: a Z80-as kicsomagoló kódban volt néhány hiba.
Hibák még lehetségesek.Egyet már találtam is :). Javított, és jobban tesztelt változat (kipróbáltam több mint 600K tömörítetlen méretű file-t is, ezt kb. 40 másodperc alatt csomagolta ki):
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 :D , 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. :D
Ez érdekel valakit, vagy letörölhetem ? :)Naná, hogy érdekel!!! Csak még idõm nem volt elmélyedni a témában :-(
Használt, valami Gagyi tömörítést :D , 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. :DEz 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 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.A DTF nem a lemezművelet miatt lassú, hanem azért, mert bitenként dolgozza fel a statisztikai tömörítésű adatfolyamot és ezek kitologatása pedig időigényes. Ki kell tolni az éppen aktuális számú bitet, és az aktuális táblázatából keszedni a neki megfelelő bájtot, majd így tovább. Hiába a statisztikai elv így követeli meg, igyekeztem optimalizálni, de csak ennyire futotta. :oops:
az attus.ldr már gyorsabban tölt, mivel ez a legfejlettebb kicsomizómat tartalmazza. :roll:Igen, ezen meg is lepõdtem a múltkor. Kár, hogy ez anno nem került közforgalomba :-(
Igen, ezen meg is lepõdtem a múltkor. Kár, hogy ez anno nem került közforgalomba :-(Bocsi, hogy ráültem. :oops:
A DTF nem a lemezművelet miatt lassú, hanem azért, mert bitenként dolgozza fel a statisztikai tömörítésű adatfolyamot és ezek kitologatása pedig időigényes. Ki kell tolni az éppen aktuális számú bitet, és az aktuális táblázatából keszedni a neki megfelelő bájtot, majd így tovább. Hiába a statisztikai elv így követeli meg, igyekeztem optimalizálni, de csak ennyire futotta. :oops:A bitenkénti léptetés valóban időigényes, ezért hasznos lehet az a megoldás, amikor a tömöríthetetlen byte-okat egészben lehet beolvasni bitenkénti léptetés nélkül, és csak a jelzőbiteket stb. kell bitenként olvasni. Bár az epcompress által használt formátum egy már létező formátum továbbfejlesztett változata, tehát az ötlet nem az enyém, de a fenti trükköt a bitenkénti olvasás elkerülésére használja.
A DTF betöltők a DTL kicsomizót használják, az attus.ldr már gyorsabban tölt, mivel ez a legfejlettebb kicsomizómat tartalmazza. :roll:
Pláne, hogy a fejlesztések nem állnak le, lásd TVC emu, IVIEW; ki tudja, mi lesz még itt, amit esetleg jó lesz tömöríteni. 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.Az IVIEW formátumban már lehet ilyen tömörítést használni, bár nem tudom, hogy az előbbi Z80 kód mennyire használható a fejlesztéshez, vagy hogy esetleg célszerűbb lenne-e más formátumot választani.
mert így a gyakori byte-ok rövidebbek is lehetnek, mint 8 bit, a ritkábbak pedig 9 bitesek (mert egy bit jelzi, hogy tömörítetlen).A statisztikai bites tömörítésnek pont ez a lényege, amit írsz. Az, hogy osztályozzuk az előforduló bájtokat gyakorisági sorrendben, és jó esetben a leggyakrabban előforduló két bájtot akár 1 bittel is lehet értelmezni. Ha megfigyeled az attus.ldr tömörítését, akkor ő kiírja az általa optimálisnak talált tömörítési rendszert, mivel matematikailag meghatározható a tömörítés végrehajtájta előtt a leendő fájl hossza, minden tömörítési módszer esetén. A tömörítési módszerek száma, már amit a progim végignéz nem túl sok, lehet, hogy van optimálisabb is az adott fájl összetételére nézve, mint amiket végigpróbál.
Az, hogy osztályozzuk az előforduló bájtokat gyakorisági sorrendben, és jó esetben a leggyakrabban előforduló két bájtot akár 1 bittel is lehet értelmezni.Erre jó példa a Morse-kód. Ott a leggyakrabban előforduló betűknek a legrövidebb a kódja, a ritkábbaknak pedig hosszabb.
Erre jó példa a Morse-kód. Ott a leggyakrabban előforduló betűknek a legrövidebb a kódja, a ritkábbaknak pedig hosszabb.Klassz példa! :smt041
jó esetben a leggyakrabban előforduló két bájtot akár 1 bittel is lehet értelmezniCsak akkor lehet mindkét leggyakrabban előforduló byte-ot 1 biten tárolni, ha a karakterkészlet mérete 2. :)
Ne haragudjatok, de tulajdonképpen mi ez az epcompress? (arra rájöttem, hogy tömörítő :))PC-n lehet vele tömöríteni 5-ös fejlécű EP programokat, IVIEW képeket, és ezen kívül bármilyen egyéb (nem csak EP specifikus) adatot.
Csak akkor lehet mindkét leggyakrabban elõforduló byte-ot 1 biten tárolni, ha a karakterkészlet mérete 2. :)Na jó. Szélsõséges voltam. :ds_icon_cheesygrin:
de egyszerűen lehetne írni olyan programot vagy bővítőt, amely a file-t EP-n kicsomagolja.Az alábbi bővítő az első ilyen jellegű próbálkozás :) A használata:
A programokból önkicsomagoló, önállóan futtatható file-t készít, szintén 5-ös fejléccel, és a bemeneti file mérete legfeljebb 63.25K lehetA THELYRA2.COM kifogott a rendszeren :-) Lehetne egy olyan paraméter, amivel fejléctõl függetlenül meg lehet mondani, hogy "nyers" formátumot csináljon?
Egyéb adatfile-t fejléc nélüli, "nyers" formátumba tömörít
A THELYRA2.COM kifogott a rendszeren :-) Lehetne egy olyan paraméter, amivel fejléctõl függetlenül meg lehet mondani, hogy "nyers" formátumot csináljon?Új verzió feltöltve :) A -raw paraméter használatakor figyelmen kívül hagyja az EXOS fejlécet. Ezen kívül a csomag tartalmazza a Z80-as kicsomagoló minden változatát, és az előbbi "uncompress" bővítést is (.ext és .rom).
A Lyra 2 tömörítve:Összehasonlítás néhány más tömörítővel, és kicsomagolási idők EP-n (384K-ra bővített memóriával):
Úgy látom már a 7z-vel is felveszi a versenyt, ami szép teljesítmény! Gratulálok!A 7z-vel nem igazán, mert több, mint 10% a különbség, de a például a RAR file méretével közel azonos lett. Ez azonban a file típusától is függ, más adatokkal nem biztos, hogy ugyanennyire jól működne. De a zlib-et használó programokkal (pl. gzip, Info-ZIP) általában rosszabb esetben is kb. hasonló méretet ér el.
PC-n lehet vele tömöríteni 5-ös fejlécű EP programokat, IVIEW képeket, és ezen kívül bármilyen egyéb (nem csak EP specifikus) adatot.Köszi a választ!
Egyéb adatfile-t fejléc nélüli, "nyers" formátumba tömörít, amit a fenti Z80 assembler rutinnal lehet kicsomagolni.Melyikkel? Én nem találom, de lehet, hogy csak én vagyok béna.
Köszi a választ!A legújabb epcompress (http://enterpriseforever.com/dlattach.html;topic=358.0;attach=1835) verzióban a "z80_asm" könyvtárban található kicsomagoló kód Z80-ra, az "uncompress"-ben pedig az uncompress bővítés .ext és .rom formátumban, (nem túl szépen megírt :)) forráskóddal. A Z80-as kitömörítőnek három változata van:
Melyikkel? Én nem találom, de lehet, hogy csak én vagyok béna.
Kipróbáltam az uncompress.ext-et is a thelyra2-t próbáltam kitömöríteni vele, de alapgépen (128k) nem megy, mert kevés a memória. (mondjuk ez annyira nem volt meglepő) Mekkora a memóriaigénye a programnak?A jelenlegi verzió az egész file-t a memóriában tömöríti ki, és mivel 3 szegmens (a 0. lap, a rendszerszegmens, és a bővítő) már foglalt, egy 128K-s gépen csak 80K marad (illetve 96K a ROM verzió használatakor). A program módosításával azonban megoldható lenne, hogy a kitömörített adatot azonnal a lemezre írja, és így csak 64K memóriát kellene lefoglalni (mert legfeljebb 65535 byte-al korábban előfordult sorozatot lehet tömöríteni, tehát ekkora a "szótár" mérete). Kisebb hátrány, hogy így megszűnne az eredeti file felülírásának a lehetősége.
A program módosításával azonban megoldható lenne, hogy a kitömörített adatot azonnal a lemezre írja, és így csak 64K memóriát kellene lefoglalni (mert legfeljebb 65535 byte-al korábban előfordult sorozatot lehet tömöríteni, tehát ekkora a "szótár" mérete). Kisebb hátrány, hogy így megszűnne az eredeti file felülírásának a lehetősége.A módosított verzió:
Mekkora veremre van szüksége a kicsomagoló rutinnak?A "CP-M emulálási célokra fenntartott" terület 160 byte, ez biztosan elég (az önkicsomagoló kód csak 20 byte területet foglal a veremnek, de a bonyolultabb decompress.s/f kitömörítő is jóval kevesebbet használ, mint 160 byte). Azonban szükség van még memóriára a változóknak is, ez az egyszerűbb változatnál 156 byte (a megjegyzés, amely szerint 152, hibás :oops:) és nem keresztezhet 256 byte-os határt.
Én pl. 5-ös fejlécű programnál 100H-ra szoktam beállítani. Ha saját programban felhasználom a kicsomagoló rutint, elég lesz-e neki a verem?
Más: próbálgattam a tömörítő programot, és érdekes, hogy nem mindig a -9 paraméterrel tömörít a leghatékonyabban (de az biztos, hogy az a leglasabb :)). Volt olyan, hogy pont a -1-el tömörített fájl lett a legkisebb.Ez valóban előfordul :)
A méret elvileg bármekkora lehet, de a tömörítő program jelenlegi verziója a gyakorlatban nagyon lassú és sok memóriát használ az eredetileg tervezett 64K-nál lényegesen nagyobb file-ok tömörítésekor. :oops:A legújabb verzió ezen javít valamennyit.
thelyra2.com 325781 (eredeti file)
thelyra2.dtf 179224 (attus.ldr EP-n)
attus.ldr:
DISK: -> DISK: ~112 s
FILE: -> FILE: ~63 s
thelyra2.dtf 177899 (dtf.cpp PC-n, kompatibilis az attus.ldr-el)
thelyra2.zip 114205 (Info-ZIP 2.32)
thelyra2.exo 108927 (exomizer 2.0b7)
thelyra2.zip 107220 (p7zip 4.57)
thelyra2 105160 (epcompress)
uncompress.ext:
DISK: -> DISK: ~79 s
DISK: -> FILE: ~27.5 s
FILE: -> FILE: ~21 s
thelyra2.rar 104272 (rar 3.80)
thelyra2.7z 93203 (p7zip 4.57)
Olyan változatot lehetne csinálni, mint PC-n az önkicsomagoló cuccok?Az megfelel erre a célra, ha az UNCOMPRESS-t kiegészítem az ep128emu_roms.bin-hez (ami több file-t tárol legfeljebb 28 karakter hosszú és könyvtár nélküli nevekkel, igaz, fejéc nincsen) hasonló formátumű file-ok kicsomagolásával ?
Vagyis több fájl van egyben, a neveik is eltárolva, EP-n futtatva megkérdezi hova csomagolja ki.
Az megfelel erre a célra, ha az UNCOMPRESS-t kiegészítem az ep128emu_roms.bin-hez (ami több file-t tárol legfeljebb 28 karakter hosszú és könyvtár nélküli nevekkel, igaz, fejéc nincsen) hasonló formátumû file-ok kicsomagolásával ?Jó lehet így is. Meg lehetne spékelni azzal, hogy ha EOF-ra fut a forrásfájlban, akkor kéri a következõ darabot? Vagyis billentyû nyomás után meg próbálja megnyitni a következõ fájlt, aminek a nevét lehetne generálni a PC-n is szokásos növekvõ számos kiterjesztéssel.
Ez a továbbfejlesztett UNCOMPRESS verzió már elvileg minden új funkciót tudNagyon jól hangzik!
de még tesztelni kell:Igyekszem :oops:
"Darabolt" file készítéséhez a -V paramétert kell használni, például 720K-s floppyhoz "-V 712".Ez tetszõleges érték lehet?
Ez tetszõleges érték lehet?4K egész számú többszöröseit lehet használni, más értékeket felfelé kerekít (pl. -V 349 helyett 352 lesz).
Nem tudom, hogy érdemes lenne-e, de talán a wiki-t ki lehetne egészíteni az EPcompress/UNCOMPRESS leírásával. Esetleg még az EPsndconv/SNDPLAY-el is, bár azok is hamar feledésbe merültek :)
Ez most akkor mûködik bármilyen programra? Vagy módosítani kell az eredeti betöltõt hozzá?
További újdonság, hogy tömörített program készítésekor a bemeneti file-ok darabolhatók, pl.:
dtf -cp -lz MAGICBAL.BIN Magicbal.com BALL1::0x08DC,0x0D5B,0x28A3,0x0482,0x0406,0x0480,0x4FBC,0x1811,0x085F
Itt a Magicbal.com és a BALL1 a két bemeneti file, és a BALL1-et 9 részre darabolva (a betöltésnek megfelelõen) tárolja. Az -lz paraméter nélkül a program "normál" DTF file-t készítene.
Ez most akkor mûködik bármilyen programra? Vagy módosítani kell az eredeti betöltõt hozzá?
Megfontolandó lenne viszont, hogy más kiterjesztést adni az új DTF-nek a kavarodások elkerülése végett!
bármilyen más kiterjesztés is megfelel, és a formátumot az EXOS fejléc alapján is fel lehet ismerni.
De ennek túl nagy jelentõsége nincsen, mert nem valószínû, hogy elterjedne a használataEzt nem tudni, lehet, hogy kiderül, a PC teljesen használhatatlan az egyre több vírussal meg mindennel szemben, és globálisan egy régi számgéphez fognak visszatérni. :D
Ha esetleg tényleg változtatásra kerül sor, én pl. a TTF ("triplán tömörített file") vagy az ITF (István-féle tömörített file) kiterjesztést javaslom.
Felmerülhet, hogy ezek magyar szavak rövidítései (nem pedig angol), de ennyi talán a külföldieknek is kell. :D
Ezt nem tudni, lehet, hogy kiderül, a PC teljesen használhatatlan az egyre több vírussal meg mindennel szemben, és globálisan egy régi számgéphez fognak visszatérni. :D
Feltöltöttem egy új "DTF (http://enterpriseforever.com/dlattach.html;topic=358.0;attach=3566)" verziót, amely a hagyományos DTF formátum mellet egy új, EXOS 64h ('d') fejlécet használó formátumot is támogat. Ez a formátum jobb tömörítési hatásfokot és gyorsabb betöltést tesz lehetővé.
Nekem nem akar hagyományos DTF-t betölteni :(
Nekem nem akar hagyományos DTF-t betölteni :(
Hamarosan elkészül a DL2 új verziója, amellyel a hagyományos Attus DTF formátumot, annak a DTF.EXE által a -p 1 5 paraméterrel létrehozható továbbfejlesztett változatát, és az új formátumot is be lehet tölteni.
Elkészült, és fel is töltöttem (bár nagyon valószínűtlen, hogy bárkit is érdekelne :)).
Ha jól nézem érdemes lenne a ZT-ban lecserélni a tiédre :oops:
Azért én beraktam az Util programcsokorba (http://ep128.hu/Ep_Util/Util.htm).
Egy rövid összehasonlítás a különböző betöltőkről:
Egy rövid összehasonlítás a különböző betöltőkről:
EXOLON.DTF 35243 byte DL2.COM 9.724 s
WRIGGLER.DTF 39845 byte DL2.COM 11.824 s
EXOLON.DTF 8.958 sAz EXOLON.DTF az a Attus puredtf-ben lévõ 35243 bájtos fájl?
WRIGGLER.DTF 10.920 s
Az EXOLON.DTF az a Attus puredtf-ben lévõ 35243 bájtos fájl?
WRIGGLER.DTF-em viszont nincs :-(
Floppyról 2x ennyi ideig tölt, viszont még így is gyorsabb 50%-al a DL-nél! :smt038
EXOLON.DTF 8.958 s
WRIGGLER.DTF 10.920 s
Érdemes lenne igazi gépen is kipróbálni, hogy mekkora hátrányt jelent a kis bemeneti puffer használata floppy esetén.
Azért én beraktam az Util programcsokorba (http://ep128.hu/Ep_Util/Util.htm).
Floppyról 2x ennyi ideig tölt, viszont még így is gyorsabb 50%-al a DL-nél! :smt038
Így akkor egyértelmûen lecserélendõ az a elavult vacak :oops:
Utántöltõs programok (pl Laser Squad :) ) számára lehetne valami egyszerûen beépíthetõ verziót csinálni?
Úgy képzelem el, hogy lenne egy kis forráskódocska amit hozzácsapna az ember a programjához, és aztán a betöltõ EXOS 6-ok helyett CALL KITOMORIT és kész. Lusta programozók számára konyhakészen :oops:
esetleg egy "nyers" módot engedélyező paraméterrel, amely a 16 byte-os EXOS fejlécet is letiltja
Utántöltõs programok (pl Laser Squad :) ) számára lehetne valami egyszerûen beépíthetõ verziót csinálni?
Így látatlanban jól sejtem, hogy így viszont a normál (tömörítetlen) pályákat nem tudja beolvasni a program?
a B00h-BA4h területre került, amelyet remélhetõleg nem használ semmiEP64 módban lehet gond, ha nem módosult az EXOS határ meg az LPT létrehozás.
EP64 módban lehet gond, ha nem módosult az EXOS határ meg az LPT létrehozás.
Ez nem tudom biztosan, hogy minden pályánál így van-e, mert nem ismerem a formátumot.A pálya elején egy Z80-as ugrótábla van, így C3H-val kezdõdik mind.
A pálya elején egy Z80-as ugrótábla van, így C3H-val kezdõdik mind.
"Attus kompatibilis" memória lapozást állítanak be, azaz az 1.-3. lapra FD, FA, FB szegmensek kerülnek.De ugye szabályosan elkéri ezeket az EXOS-tól?
De ugye szabályosan elkéri ezeket az EXOS-tól?
Igen érdeklõdve olvasgatom, hogy milyen klassz dolgokat mûveltek. :)
Mivel, most csak az ep128emu-2.0.7 linuxosításával, foglalkozom, csak arra lettemm figyelmes, hogy a hozzá csatolt zozotools DL -je nem minden régen betömörített DTF progimat képes kitömöríteni, valamint lassabb az én öreg attus.ldr betöltõmhöz képest. Remélem, ezeket is helyre kerülnek egyszer.
István tömörítési hatásfok növelésétõl el vagyok képedve. :shock:
A DL2-t próbáltad ? Az remélhetõleg gyorsabb, mint a DL, és talán a kompatibilitása is jobb. Zozosoft már ajánlotta, hogy beépíti a ZozoTools következõ verziójába, de ha mégsem, akkor a "Multiplay" ROM-ba is kerülhet. A DL-nek egy elõnye azért van, a 16K-s bemeneti puffer, de a DL2 meglepõ módon még a "hagyományos" 256 byte-os pufferrel is gyorsabb lemezes igazi gépen, ha nem is annyira, mint emulátoron.Õt még nem. Csak a rövid idejû uhu pakk tesztelési fázisában a az alap ZozoTools DL -jét.
zozotools DL -je nem minden régen betömörített DTF progimat képes kitömöríteniOtt lehet még játszani a rendszerváltozóval is, ami szabályozza a memóriafoglalást, ill. az István által is emlegetett kötött memóriakezelés miatt vannak programok amik csak 128-as módban mennek. Ekkor DL-ben le kell tiltani a gyorsító szegmenst, mert a játék felülirná, vagy pedig ha bõvített gépen EXOS 2.3-al csináltuk a 128-at, akkor megadhatunk egy létezõ de így nem beláncolt RAM szegmenst fixen a gyorsításhoz.
valamint lassabb az én öreg attus.ldr betöltõmhöz képest.Igen, ezt irtam is múltkor, hogy ha anno közkézen lett volna az ATTUS.LDR, akkor nem álltam volna neki DL-nek meg Anti DTF-nek :)
Ilyen a pl. Desolator és a Drakkar.
A Big demót tömörítés nélkül kéne meghagyni, így a Big demo és Small demo címe a méretét is tükrözné. :D
* duct (http://enterpriseforever.com/dlattach.html;topic=404.0;attach=3745) (25.35 KB - downloaded 3 times.)
Ezek jól összementek :-)
A Small Demo-ban volt valami saját tömörítés is, legalábbis volt valami keretcsíkozós rész :-) ez is le lett cserélve?
A javított PART-1-bõl lehetne egy hagyományosat is kérni az archívum részére?
A Big Demoban a második részben (Cybernoid zene, scroll) a középsõ scroll "maszatos".Csináltál hideg resetet betöltés elõtt? Ha jól emlékszem ez is azon programok közé tartozik, amik nem nullázzák ki a felhasznált memóriát, hanem csak számítanak rá, hogy nulla van benne.
A Big Demoban a második részben (Cybernoid zene, scroll) a középső scroll "maszatos".
Csináltál hideg resetet betöltés elõtt? Ha jól emlékszem ez is azon programok közé tartozik, amik nem nullázzák ki a felhasznált memóriát, hanem csak számítanak rá, hogy nulla van benne.
Itt a hibát már az eredeti verzió is tartalmazta, a digitális hang egy rövid része hiányzott (igaz, ezt valószínűleg nehéz észrevenni).
Ez nincs az ep128.hu-n :oops:
Be tudodnád tömöríteni az t a változatot ami nálam van kint?
Abban már nem kell SINCLAIR és KEMPSTON feliratú csatlakozókat keresgélni gépünkön...
Az Ork Demo 2 nekem nem indul el. Megjelenik a cím, tölt tovább, aztán nothing
Ha RL NEW-el kiírtjuk, hogy csak WP,EXDOS,IDE maradjon, akkor se megy?
Ha kevesebb max particióra van fordítva az IDE.ROM, az tán segíthet...Ez jól hangzik! :-)
De majd az lesz a megoldás, hogy 128K-nál több RAM esetén saját szegmenst foglal az IDE, így akkor nem veszik el az értékes hely a rendszerszegmensbõl.
ha anno közkézen lett volna az ATTUS.LDR, akkor nem álltam volna neki DL-nek meg Anti DTF-nek :)Nagy vagy Zozo!
Nekem csak DTF&TOM TÖLTÖ-m volt, abból is ki tudja mikori verzió, az nagyon lassú volt.
Otthon megnézem! Mely programokra gondolsz?
Itt a nemdtf csomag:
Wizard of Wor (a billentyűzet konfigurálásánál a Space kiírása javítva):
A betöltőképet esetleg ki lehetne hagyni :?: Úgy látom, az ep128.hu-s csomagban nincsen, és a file nagy részét az teszi ki.
A betöltő kép maradhat, aki akarja, betölti, aki nem az nem, ha a WOW-ot indítod, akkor a betöltőkép kimarad, az maradt az eredeti 5-ös fejlécű betöltőprogram.
Mindig alkotsz valami érdekeset. :)
A "wow" file a betöltőképpel indításkor valójában nem kell, és a Multiplay ROM :DL2 parancsa a wow2.prg-t közvetlenül is be tudja tölteni.
Betetted a loadert (WOW) a betöltőképbe?
Nem, a WOW.PRG-ben van. De ez talán nem meglepő, mert egyébként nem működne a betöltőkép nélkül :)Na most megkavartál.
A "wow" file a betöltőképpel indításkor valójában nem kell, és a Multiplay ROM :DL2 parancsa a wow2.prg-t közvetlenül is be tudja tölteni.Ezek szerint az eredeti betöltő (wow) nincs is szükség, mert a WOW.PRG-be be lett építve ami kell, és az egy 5-ös fejlécű program?
Na most megkavartál. Ezek szerint az eredeti betöltő (wow) nincs is szükség, mert a WOW.PRG-be be lett építve ami kell, és az egy 5-ös fejlécű program?
De meg lehetett volna oldani azt is, hogy az egész játék egy nagy .com file legyen, és az lett volna a jobb megoldás, csak a "DTF-szerű" file-ok készítése egyszerűbb :oops:Részemről nem probléma ;), nekem szimpatikus ez a megoldás :), meg úgy az egész file-t előbb be kell tölteni, és csak utána jöhet a móka.
Közben leesett, csak egy cigi kellett hozzá :DAkkor az avatárodon az unicumos üveg helyett egy hamutálat kéne elképzelni?
Betöltőkép külön:
* wow.com (http://enterpriseforever.com/dlattach.html;topic=404.0;attach=3937) (28.4 KB - downloaded 4 times.)
* wow (http://enterpriseforever.com/dlattach.html;topic=404.0;attach=3938) (0.64 KB. 123x2 - viewed 5 times.)
* wow.prg (http://enterpriseforever.com/dlattach.html;topic=404.0;attach=3939) (17.34 KB - downloaded 4 times.)
A "wow" file a betöltőképpel indításkor valójában nem kell, és a Multiplay ROM :DL2 parancsa a wow2.prg-t közvetlenül is be tudja tölteni.
Itt szintén hiányzott a betöltőkép, ami azonban ezúttal nagyobb probléma volt, mert ugyanaz a file a karaktetkészletet is tartalmazta. Mivel az eredeti file-t nem találtam sehol, újat készítettem az ep128.hu-n talált screenshotból (EPimgconv segítségével) és a CPC ROM karakterkészletéből.
* dexter2.com (http://enterpriseforever.com/dlattach.html;topic=404.0;attach=3965) (0.64 KB. 126x2 - viewed 2 times.)
* dexter.prg (http://enterpriseforever.com/dlattach.html;topic=404.0;attach=3966) (31.59 KB - downloaded 1 times.)
És ez még visszaolvasható TPT nélkül is! Ez a betöltési idő már Commodore floppy-ról sem rossz... :twisted:
Wriggler (tömörített), TPT alapértelmezett turbóval: 1:47 (!)És ha úgy turbósítunk, hogy turbó tape betöltõ is kell hozzá, akkor elbírja még a gép a hosszabb programoknál is, hogy a kitömörítõ és a turbóbetöltõ is a memóriában legyen egyszerre?
És ha úgy turbósítunk, hogy turbó tape betöltõ is kell hozzá, akkor elbírja még a gép a hosszabb programoknál is, hogy a kitömörítõ és a turbóbetöltõ is a memóriában legyen egyszerre?
(amelynek azonban egy már tömörített programnál nem sok értelme van, mert csak kis mértékben növeli a méretet)
A fenti érték kikapcsolt TPT-s tömörítéssel értendő. Ezt elfelejtettem odaírni...
készítettem egy részletesebb leírást a tömörített program betöltõ legegyszerûbb változatáhozKöszönjük!!!!! :smt038 :smt038 :smt038
A csatornaszám mindig 1Miért pont 1? Ha nulla lenne, akkor lehetne pár bájtot még spórolni :-)
készítettem egy részletesebb leírást a tömörített program betöltõ legegyszerûbb változatához.Azt hiszem, ez az eddigi leghosszabb hozzászólás a fórumon, ráadásul kõkemény Enterprise-os témáról. :smt041
Persze ez a program is elveszett...:( Kár...
valószínûleg nem érdekel senkitEjnye! :smt039
Az EPcompress esetében a statisztikai tömörítés az adott file-ra optimalizált.Mint az én néhai DTF-em, csak nálad tökéletesebben.
a hosszúság, és a távolságRagyogó ötlet.
A hosszúsághoz tömörített sorozatnál egyet hozzá kell adni, mert a legrövidebb sorozat, amelyet ez a tömörítõ ismételni tud, 2 byte-os. Ezen kívül a 2 byte-os sorozatok a távolságnál más kódolást használnak, amellyel a legnagyobb lehetséges érték 65535 helyett csak 510, ehhez viszont általában egy bittel kevesebb is elég, és így valamivel jobb tömörítési hatásfokot tesz lehetõvé:A helyzet, és a tömörítés fokozódik.
esetleg gyorsabban kirajzolná a pályát.Gyorsabb biztos nem lenne. Pláne BASIC-ben... :-)
Gyorsabb biztos nem lenne. Pláne BASIC-ben... :-)Ja, közben nekem is eszembe jutott ez. :D
Akkor talán érdemes lenne még az EPcompress és DTF formátumokról is részletes leírást készíteni ? :)Igen, igen, igen!!!
Úgy látszik, mégsem :)Kis türelmetlen! :smt064
Az optimális kódolt byte méret elvileg kiszámítható a gyakoriságból (log2(1/f) bit, ahol 'f' az elõfordulási gyakoriság 0 és 1 között; tehát például ha egy byte 25% valószínûséggel fordul elõ, akkor azt 2 biten érdemes tárolni, ha viszont csak 0.1% a valószínûsége, akkor kb. 10 biten).Az RLE tömörítés után a tömörítõm a fájlban lévõ bájtokat elõfordulási rangsorba állítja.
Egy egyszerû példa programok tömörítésére::smt038 :smt038 :smt038
Ha több adatblokk (EXOS 6 hívás) lenne a .prg file-n belül, akkor azoknak a méretét vesszõvel elválasztva kellene megadni.És ha több külön fájl van (SCR, PRG, ROM, stb), akkor azt hogyan lehet egybe rakni?
WEC Le Mans (CPC átirat):
(Attachment Link)
(Attachment Link)
Kisebb hiba az átiratban: külső joystick használatakor a "fel" irány egyszerre gyorsít és balra kanyarodik, a "bal" irányra viszont nem történik semmi; ez nehezítheti az irányítást :) A billentyűzet/beépített joystick azonban jól működik.
UI: a reset ebben a verzióban nem mûködik :oops:És a hiscore második lapja is kicsit szétesik :oops:
És a hiscore második lapja is kicsit szétesik
István! A Subacuaticban ezt a tömörítõt használják: aPack (http://www.ibsensoftware.com/products_aPACK.html)
Itt van a hozzátartozó Z80 kicsomagoló is.
Ez mit tud? Érdemes lenne inkább lecserélni Epcompressre?
Ez a kupac screen van tömörítve vele.
csak a betöltőképet - amelyet egyébként dither nélküli változatra cseréltem - és az utolsó adatblokkot lehetett tömöríteni.
Sorcery+:A játék eredetileg titkosítva volt, egy egyszerű kivonós xorolós megoldással, a tömörítést már én hajtottam végre rajta, hogy az főkód kivételével mindent be lehessen tölteni a +64K-ba, belefért 48k-ba :D, és a DTF -LZ-thasználtam, nagyon jó :) A Kódot és a betöltőképet nem tömörítettem, azon a pár kb-n nem múlik már semmi, becsomagoltam ZIP-pel és csak 8k-val lett kisebb :D
Nem sokkal lett kisebb, gyakorlatilag csak a betöltőképet - amelyet egyébként dither nélküli változatra cseréltem - és az utolsó adatblokkot lehetett tömöríteni. Lehet, hogy a játék már eddig is valamilyen tömörített, vagy "titkosított" formátumban volt, amelynek a dekódolásával talán kisebb méretet is el lehetett volna érni.
UI: a reset ebben a verzióban nem működik :oops:
A játék eredetileg titkosítva volt, egy egyszerű kivonós xorolós megoldással, a tömörítést már én hajtottam végre rajta, hogy az főkód kivételével mindent be lehessen tölteni a +64K-ba
A fájltömörítés azért nem műxik, mert a hiba rutin 0090h-ra került, és a megszakításkiegészítés meg 0028h-ra
Érdekes, hogy a RAM3.BIN még bír tovább tömörödni, mivel az a apackkal tömörített screenek összefûzve.
Gondolom valami hasonló van elrejte az EXOS meg a BASIC ROM-ban is, mert simán nem lehet megtalálni a hibaüzeneteket.
Meg is találtam EXOS 2.1-ben: 1-es szegmens E3D5h, az adat FE72h
Köszi, ez komplexebb mint gondoltam! Az, hogy a betûket, hogyan kell csoportosítani vajon õk találták ki, vagy ez már egy régóta ismert módszer volt akkoriban?
Nem egészen ebbe a topicba tartozik, de ide írom :D
Nemrég belefutottam egy olyan Spectrum programba, aminek egy része a TRD disk image-en tömörítve volt 4 file-ban, először az volt gyanús, hogy a kiterjesztése RAR volt, de nem akartam elhinni, hogy ilyen létezik, ezért a disk image-ből kivágtam a file-t, majd Windows Commader alatt nyomtam egy entert, és meghökkentem, kiadta a file-listát, tehát valóban RAR file-t találtam a TRD image-en, és a program menet közben ki is csomagolta, amire szüksége volt.
Nem hagyott nyugodni a dolog, és ma meg is találtam a RAR 0.32, és UNRAR 0.60-s programokat, amik Alone Coder nevéhez fűződnek.
Valóban lehet használható RAR kitömörítőt írni Z80-ra, bár feltételezem, hogy a formátum nem minden lehetőségét támogatja, azaz valószínűleg csak -md64 -mc- paraméterekkel létrehozott file-t tud kicsomagolni (normál LZ77+Huffman algoritmus 64K szótár mérettel, ami nem sokban tér el a ZIP-től, illetve az EPcompress -m0-al tömörített .com file-októl). Esetleg át lehetne írni Spectrumról EP-re is :)Nem értek én hozzá kérem szépen :) ,csak leesett az állam, amikor ezt megláttam :), aztán mégjobban, amikor a kitömörített fájlokat betömörítettem DTF -lz opcióval, és 5 kbyte-tal nagyobb lett a mérete (a becsomagolt fájl 211kb volt).
Nem értek én hozzá kérem szépen
:) ,csak leesett az állam, amikor ezt megláttam :), aztán mégjobban, amikor a kitömörített fájlokat betömörítettem DTF -lz opcióval, és 5 kbyte-tal nagyobb lett a mérete (a becsomagolt fájl 211kb volt).
Az EPcompress-t egyébként szintén lehet EP-s programokban használni, az epcompress.7z-ben található decompress_simple.s (az -m2 formátumhoz) és decompress_sfx_m0.s (-m0-hoz) file-okban van olyan "decompressData" rutin, amely a HL címto"l kezdo"do" tömörített adatot a DE-to"l kezdve elo"re haladva kicsomagolja (a DTF -lz-nél ez fordított irányú).Azt nem tudtam, hogy az DTF -lz mennyire bonyolult, nekem szimpi volt, mert néha verte a ZIP-et :) , meg könnyen kibueheráltam a kitömörítő rutint a forrásból. :D Mennyivel hatékonyabb az EPcompress -m2, mint a DTF -lz, és mennyivel az -m0, csak azért kérdem, mert a -lz kicsomagoló rutinja nagyon rövid, a -m2 még szimpi hosszra, és gondolom a sebesség is nagyon jó, az -m0 nagynak tűnik, és kéne nem tudom mennyire sínylené meg a program sebessége a kitömörítőét. Mondjuk a hatékonyságot könnyen ki tudom deríteni egy kicsi csomagolással :)
Azonban a memóriaigény nagyobb, az -m2-höz verem nélkül kb. 440-450 byte kell, az -m0-hoz pedig kb. 1350 byte, és az utóbbi lassabb is.
Az átíráshoz nem kell feltétlenül érteni, hogyan működik a tömörítés :)Ezt tudom, a -lz kitömörítőjét is úgy sikerült kiszedni a forrásból, hogy nem értettem hozzá :D
Azt nem tudom, hogy a RAR PC-n készült-e, viszont ha PC-n készült is túl bonyolult algoritmust nem használhattak, csak olyat, amit még Z80-on ki lehet csomni, nem?
EPcompress által kötegelt fájlok tömörítéséből ki lehet a fájlokat egyesével nyerni?
Az EPcompress az -a paraméter használatával tud több file-t tömöríteni, ilyenkor a tömörített adat elején egy táblázat található a file-ok nevével és méretével. De ezt programokban talán kissé nehézkes lenne használni (viszont az EP-s :uncompress /a parancs kicsomagolja, igaz, az -m0-t nem tudja). A -raw pedig egyszerre csak egy file-t tömörít, és a kimenet a decompressData rutinokkal feldolgozható adat (tehát több file esetén azokat össze kellene fűzni, és a betöltőnek tudnia kell az egyes blokkok méretét).
De már van olyan DTF verzióm, amit még ma feltöltök, és az új -lz2 és -lz0 paraméterekkel az EPcompress algoritmusait is támogatja, azaz minden parancsnál, ahol eddig -lz használható volt, most lehet -lz2 is (az -1..-9 pedig itt is a tömörítés mértékét állítja). Több file/blokk esetén a -cr -lz2 kimenetében minden blokk előtt egy két byte-os érték található, ami a tömörített adat mérete, ezt követi a decompressData segítségével kicsomagolható adat.
Köszi szépen, már le is töltöttem :)
jaja, -a-val csomagoltam, csak a tömörített állományban nem láttam a file-ok neveit
Akkor nagyjából úgy néz ki, mint a régi -lz, csak az ATTUS.LDR marad le a file-ok elejéro"l, meg a compressed data végéro"l két byte, amire már nem emlélszem, hogy mi is, de kellett a kicsomagoláshoz.
http://zxsoft.zxby.org/ (http://zxsoft.zxby.org/)Itt van az a HRUST nevû cucc is, amibe én futottam bele egy készülõ átiratnál. Ez önkicsomagoló modulokat készít, betöltés után meg kell hívni a cucc elejét, aztán kicsomagolja magát az eredeti címtõl kezdve.
"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.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?
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.
Talán érdemes lenne az EPcompress csomagot frissíteni az új, 22 (vagy akár 33 ha SIZE_OPTIMIZED módban van fordítva) byte-al kisebb önkicsomagoló kóddal. Esetleg a "dtf -lz" algoritmust is be lehetne építeni -m3 módnak.Szerintem ez egy nagyon jó ötlet. Nagy meló lenne a DTF-et és az EPCompresst összegyúrni egy programmá?
Valószínűleg megoldható, bár egyelőre talán csak az -m2 kitömörítő rutint cserélem le az újabbra. :oops: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.
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.:smt041 :smt041 :smt041
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.
Feltöltöttem az új verziót:Szuper, már le is töltöttem, remélem hétvégén lesz időm, és eljutok odáig, hogy a file-okat tömöríthetem.
- a "dtf -lz" formátumot az -m3 paraméterrel lehet választani; ez csak legfeljebb 65535 byte méretű adatot támogat, és figyelmen kívül hagyja az -1..-9, -minlen, -maxoffs, és -blocksize paramétereket
- az -m2 formátumú .com file-ok alapértelmezett beállításokkal (-borderfx -nocleanup) 30 byte-al kisebbek lettek, az .ext file-ok mérete pedig 36 byte-al csökkent; a betöltés gyorsult is valamennyit, elsősorban a .com file-oknál (.ext-nél engedélyezett a SIZE_OPTIMIZED)
- -m3 formátumot választva .com file-t a 100H-FFFFH területre lehet tölteni, .ext-et pedig C00AH-FF83H-ra
- -m2-nél a használható terület 100H-FE3EH (korábban 100H-FE22H volt), illetve C00AH-FE6AH (C00AH-FE46H volt)
- a csomag tartalmaz programokban használható Z80 "decompressData" rutint (sjasm-hez) az -m0, -m2, és -m3 formátumhoz is
Lehet, hogy valójában nem is érdekel senkit :)Engem érdekel, ezek a komolyabb tömörítõs dolgok mindig misztikumok voltak számomra :oops: az írásaid alapján kezdem kapisgálni a dolgokat!
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.
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.
ROM-ba fordításnál problémát jelenthet még az önmódosító kód. A decompress_m3.s-ben egy helyen találtam ilyet, de ez könnyen javítható lenne.Ez az, igaz?
Érdekes olvasmány! Még egy kicsit emésztenem kell, hogy teljesen felfogjam :oops:Én csak az elejét értettem. :D De az jó!
Pontosan mi az, ami nem érthető? A leírás ugyan valószínűleg meglehetősen rossz :oops:, de talán lehetne javítani rajta.Lehet, hogy ha adnál valami pszeudokódot is a magyarázathoz, akkor könnyebben megfogható lenne programozói szemponból.
epcompress teszt a programba építhető rutinokkal az aktuális GitHub forráskód alapján:Már pont gondoltam rá, hogy kéne ilyen teszt! :smt038
Még egy teszt a gunzip (https://enterpriseforever.com/programming/unzip-deflate-tool-for-z80-machines-any-interests/msg50670/#msg50670) módosított változatával, ez egy sebességre optimalizált de meglehetősen nagy méretű (4287 byte kód + ~6000 byte adat) Deflate/zlib kicsomagoló rutinAkkor ehhez a sima ZLib méretek tartoznak?
az epcompress honnét tölthető le (nem a forrás, hanem a futtatható)?Az ep128emu csomagban benne van, szóval ha felraktad a legfrissebb emut, akkor ott van a könyvtárában :-)
nekem még valami ősrégi változat van meg
Az ep128emu csomagban benne van, szóval ha felraktad a legfrissebb emut, akkor ott van a könyvtárában :-)á, és tényleg :-D
Egyelőre csak a RAID2.PRG-t néztem, a program EXOS veremmutatót (B2xxh) tételez fel az indulásakor, -cleanup paraméterrel kell tömöríteni (+11 byte).Köszi!
Ha a rutin ROM-ban fut, akkor még problémát okozhat az is, hogy néhány helyen önmódosító kódot használ.Ez megoldódott RAM-ba másolással.
TVC-sek csináltak egy nagy EPROM-os (kapcsolóval lapozható) cartridge-et, és felmerült, hogy a gyári ROM-okon kívül több játékot is be kéne rakni.TVC-hez is használható az EP tömörítő? Nem semmi!
TVC-hez is használható az EP tömörítő?Bármihez jó amiben Z80 van :-)
Bármihez jó amiben Z80 van :-)
Nem tudom, érdemes-e beépíteni, mindenesetre a formátumon talán lehetne egy keveset fejleszteni, mivel valószínűleg nem lényeges a Plus/4-es változattal való kompatibilitás.Szerintem igen :)
A BALL1 az lehet, hogy csak a XOR-olós titkosítás miatt lett jobb, ha jól emlékszem, a program egyszerű növekvő sorozatot használ erre a célra.Ha még ez is számít, akkor akár lehetne a tömörítési folyamat része is a xor-olós "titkosítás", ha így jobban össze lehet tömöreríteni a programot.
Már van ilyen (https://github.com/istvan-v/ep128emu/blob/master/util/epcompress/z80_asm/decompress_m4.s), de még változhat. Ez jelenleg 212-218 byte méretű a beállításoktól függően, lehet nem önmódosító és akkor használja az IX regisztert, egyébként csak az AF, BC, DE és HL-t.Szuper, le is töltöttem :) , látom az EPCOMPRESS forrása is megváltozott, van befordított winfosos verzió is?
Most már vanKöszi!
Most már van (64 bites):
(Attachment Link)
m1 rutin (még fejlesztés alatt, ez a régi decompress_m2_new.s módosított változata):
(Attachment Link)
További méretcsökkenés (https://github.com/istvan-v/ep128emu/blob/master/util/epcompress/z80_asm/decompress_m4.s), most 209 byte a legnagyobb m4 rutin (önmódosító, nem IX-es, keretcsíkozással). Még tesztelni kell, és talán lehetőség lehet további optimializálásra is. Néhány byte könnyen megtakarítható lenne kisebb lassulás árán. Az m1-es rutint is valószínűleg érdemes lenne átírni erre a megoldásra.Cool :) ,úgy látom az M1 is módosult, le is töltöttem azt is :)
Hasznos lehet nagyon kis programokban, ahol az m3-as rutin is túl bonyolult és nagy méretű.Ez jól hangzik! :smt038
támogat normál irányú adatfolyamot.Ez azt jelenti, hogy úgy hívható, mint egy egy normál EXOS fájl olvasás, tetszőleges bájtot/blokkot kérve?
De ha jól értem, ez valójában mind eredetileg 5-ös fejlécű program lenne?Nem mind. Az elsők valóban ilyenek voltak (egy fájlos 5-ös fejléc, Nodes, Raid és társai, ezek végül önkicsomagoló tömörített formában kerültek be), aztán lettek normál több fájlosak, ahol az eredeti pár száz bájtos betöltőt másolja az indító parancs 100h-ra. A betöltőben meg módosítva lett a fájlnév, hogy a ROM-ban lévő EXOS device-ről töltsön. (Itt viszont most csak akkor van tömörítés, ha a játék gyárilag tömörített fájlokat használ.)
egyszerűen szegmens szám + 1Igen.
Ez pedig a konvertáló Lua script, még fejlesztés alatt:Sikerült futtatni :ds_icon_cheesygrin:
Viszont úgy látom, a játék sok adatot tölt be karakterenként EXOS 5 hívásokkalIgen ez a képernyő effekt időzítése :oops: Persze ki lehetne írtani :-)
Ha fontos a 64K alatti méretEz lenne a cél, hogy egy sima cartridge-be beférjen. Szerintem elfogadható kép nélkül is :-)
De végül is ha a 64K-ba belefért, akkor már elértük a célt.
A legjobb lenne azonban a :DIR parancshoz hasonló funkció, bár az több helyet foglalna.Nem tudom mennyi helyet foglalna, ha lenne egy lista készítve az 5-ös fejlécű fájlokról, amiből egy indító menü készülne, pl:
Nem tudom mennyi helyet foglalna, ha lenne egy lista készítve az 5-ös fejlécű fájlokról, amiből egy indító menü készülne, pl:
Igen, vannak ilyen rendetlen programok :-(
Ezek közül a Star Sabre betöltőképek közül melyik a használhatóbb? Az alsó több helyet foglal, de talán még elfér.Mindkettő jó, de a felső jobb, mert kevésbé szemcsés.
Mindkettő jó, de a felső jobb, mert kevésbé szemcsés.Szerintem is.
dtf -d rickdng2.prg rick2.com rom_rick2.prg
Ezek helyett érdemesebb lenne mást beépíteni. :oops:Az valóban praktikusabb lenne :-)
Találtam még megoldhatatlan pályákat is, amelyeknek nincs kijárataMost lebuktunk, hogy nem játszottunk sokat ezzel a játékkal. Én mondjuk mindig csak az első néhány pályáig bírtam.
A Swap az eredeti változat legyen, vagy az EnterMice-os? A Quadrillion is lehet a 4K-s, a Crillion (https://enterpriseforever.com/konvertalas/quadrillion/msg72230/#msg72230) (C64-es pályák), vagy a digitális zenét tartalmazó verzió (nagy méretű).
A SWAP szerintem az egér támogatással az igazi. A Qudrillion "nagyméretű" belefér egy 64K epromba?
Ha csak a Quadrillion kerül a ROM-ba, akkor igen, akár a Quadrillion és Crillion is együtt. Akkor előnyös a digitális hang hiánya, ha az a cél, hogy a legtöbb játék férjen el egy ROM-ban.
Ezekből lehetséges lenne romverziót csinálni? :)
ATOMIX
Még néhány programot átalakítottam: Alien 8, Atomix, Crillion, Quadrillion 4K, Skramble, Swap. További teendő a Bricky Prise (talán betöltőkép nélkül elfér), Exorcist és Quadrillion Full.
A Bricky Prise ROM első próbálkozásra 71309 byte méretű lett. :oops: A pályák teljes újracsomagolásával talán elférne, bár ez nem tűnik könnyen megoldhatónak, vagy ilyen betöltőképpel biztosan:Szerintem, ha már ROM, akkor vagy a full betöltőkép ( a zene szólhat a fekete képernyő alatt is :D ), vagy akár az első digi zene is áldozható, elküldjem a forrást?
(Attachment Link)
Egyébként felmerült bennem egy hardverötlet: 512K-s ROM mellé kb 4 db 74xxx IC kéne, és akkor lehetne olyan, hogy az 4-5-6 szegmens fix (gyorsteszt, Basic, ROMFS), a 7-re meg lehetne lapozni a ROM bármely lapját, így akkor 464K helyre lehetne játékokat rakni.
elküldjem a forrást?
Ez pontosan hogyan lenne lapozható?A 6-os szegmens végére (3. lapon Fxxxh) írt érték menne egy lapozó regiszterbe, ami adná az A18-A14 címvezetékeket 7-es szegmens használata esetén a ROM IC-nek. Vagyis 00-1Fh értékekkel lehetne elérni a teljes 512K-t, ebből 00-02 lapok a hagyományos 04-06 szegmensek tartalma, a többi lenne használható ROMFS számára.
egeresített változatot használtam.Ezt jól tetted, a Bricky prímán játszható egérrel!
Köszönöm, a forrás valóban segítség lehet nagyobb átalakításnál, bár a betöltőkép nélküli verzió már kész van. De talán sikerülhetne helyet felszabadítani legalább egy rosszabb minőségű kép számára. Esetleg problémát jelenthet még, hogy az itt (https://enterpriseforever.com/enterprise-devcompo-1-37/enterprise-program-bricky-prise/msg59772/#msg59772) található egeresített változatot használtam.Este csatolom :)
Szerk.: a Crillion hibás, csak 291 soros az LPT, ezt holnap javítom.A Midis változat? Ha igen, akkor javítom a forrásom én is.
Igen. Egyébként a Nodes of Yesod is 301 soros, ez nem tudom, probléma-e.Érdekes, nekem a Nodes anno egyik tévén se futott.
Igen. Egyébként a Nodes of Yesod is 301 soros, ez nem tudom, probléma-e.A klubban egyszer volt egy monitor, amin a Nodes képe el volt csúszva függőlegesen, miközben más programok jók voltak. Lehet, hogy ezért.
start.asm EXOS 29 fagyás elleni védelemmelEzt a :FILE-be is érdemes lenne beletenni?
Ezt a :FILE-be is érdemes lenne beletenni?
Még néhány programot átalakítottam: Alien 8, Atomix, Crillion, Quadrillion 4K, Skramble, Swap. További teendő a Bricky Prise (talán betöltőkép nélkül elfér), Exorcist és Quadrillion Full.
Az ATOMIX rom verzióját fel tudnád tenni?
A GitHub-on frissítettem a különböző Z80 kicsomagoló rutinokat a mostanában feltöltöttekreKöszönjük!
A teljesség kedvéért összegyűjtöttem a ROM készítésnél használt egyéb programokat:Ezt is!
Rövid epcompress leírás (https://wiki.enterpriseforever.com/index.php?title=EPcompress_le%C3%ADr%C3%A1s) a wiki-n, bár nem valószínű, hogy volt rá igény. :)De, van rá igény! Köszi!
Nem töltöttem fel új verziót. :) Csak a wiki-t szerkesztettem, bár nem tűnik valószínűnek, hogy sokan olvassák.Én szoktam :-) Jó, hogy össze vannak gyűjtve egy helyre a dolgok, mert a fórumban előbb-utóbb elsüllyednek.
Nem töltöttem fel új verziót. :) Csak a wiki-t szerkesztettem, bár nem tűnik valószínűnek, hogy sokan olvassák.Azt töltöttem le :D
Rövid epcompress leírás (https://wiki.enterpriseforever.com/index.php?title=EPcompress_le%C3%ADr%C3%A1s) a wiki-nNem találom :-(
Nem találom :-(History fülön keresztül még elérhető. Rá kell kattintani az utolsó előtti változat dátumára, és akkor megnyílik.
History fülön keresztül még elérhető. Rá kell kattintani az utolsó előtti változat dátumára, és akkor megnyílik.Köszi! Gyorsan elmentettem.
az IVIEW.ROM-ban a helyére kerülhetne például a MIDI lejátszó egyszerű, kijelzés nélküli változata.Ahol teljesen fekete a képernyő? Végülis lehet az is, de nem lehetne valami minimális vizualizáció? Vagy akár olyasmi, hogy megmarad a betöltés előtti képernyő, és a zenéből kilépéskor "ok" üzenettel visszadob oda. Netalán a háttérben szólhat a zene pl. basicben programozgatás közben, esetleg lejátszási listákat is kezelne.
Ahol teljesen fekete a képernyő?
Ez a változat fér el. :oops: A mididisp.com-hoz még mást is törölni kellene.Nem tudom, ki mennyit hallgat midiket EP-n. De végülis jó lehet akár a sötét képernyős változat is, ha elfér.
az m2 tömörítésre miért írja azt a wikis leírás, hogy "elavult és általában nem ajánlott a használata"?Megpróbáltad visszanézni a leírás korábbi változatait? Hátha valamelyikben meg lehet találni az okát.
ahogy nézem, az m2 kisebb fájlokat állít elő, mint az m3 (raw mode)
adatfájlokat tömörítéséről lenne szó
Viszont egyszerű rutinnal olvasható az adat byte-onként, és nem kell az egészet kicsomagolni. Talán van olyan alkalmazás a zenén kívül, ahol ez hasznos lehet, ha nem is tűnik valószínűnek.Éppenséggel tudok ilyet, ahol ez jól jönne: Flash ROM fájlok, pl SD illesztőhöz, illetve különböző kártyákon (Pl a Pear féle EXDOS) előfordulnak 256-512K Flash ROM IC-k. Itt pont az jönne jól, ha bájtonként jön az adat, amivel aztán lehet hívni a bájtbeírás rutint.
Érdekességként készítettem a program olyan változatát is, amivel zene helyett tetszőleges adat tömöríthető, bár a formátum korlátai miatt nem igazán hatékony. Viszont egyszerű rutinnal olvasható az adat byte-onként, és nem kell az egészet kicsomagolni. Talán van olyan alkalmazás a zenén kívül, ahol ez hasznos lehet, ha nem is tűnik valószínűnek.Valamikor már lett volna szükségem rá, lehet pont zene volt az is, de szerintem ez egy nagyon hasznos, hiánypótló funkció :) Amúgy eszembe jutott, hogy esetleg grafikánál lehet még használni, pl vertikális scrollnál, egy-egy oszlop eltárolására, ha kisebb, vagy nem sokkal nagyobb outputot generál, mintha tile-okból lenne összerakva a graf. Van is egy konvertálandó ötletem, sztem majd le is tesztelem rajta, igaz odébb lesz, mert most a Renegade van a menün :)
Ez csak a zene konvertáló és lejátszó egyszerű átalakítása, amint említettem, nem jó a hatásfoka (az alábbi példa epcompress -m6 formátumban is csak 7998 byte lenne 13665 helyett, bár a kovertált file még tömöríthető 7937-re):Szerintem ez jó, pl pálya adatok külön be vannak még csomagolva, az aktuális ki, azt lehet bájtonként kirakni a képernyőre, nekem ez teccik.
Szerintem ez jó, pl pálya adatok külön be vannak még csomagolva, az aktuális ki, azt lehet bájtonként kirakni a képernyőre, nekem ez teccik.Nem annyira ide tartozik, de a pályaadatokról jut eszembe, hogy a Squirm című Plus/4 játék pályáinak egy része ki van mentve txt formátumba, de már ez nagyobb, mint maga a program. Biztos tömörítik a pályákat benne valahogy. Gondolkoztam, basicben DATA sorokban tárolva nagyobb pályákat könnyen elfogy a hely. Nem tudom, basicben ilyenre lehet-e valami jobb, kisebb helyet igénylő megoldás.
Nem annyira ide tartozik, de a pályaadatokról jut eszembe, hogy a Squirm című Plus/4 játék pályáinak egy része ki van mentve txt formátumba, de már ez nagyobb, mint maga a program. Biztos tömörítik a pályákat benne valahogy. Gondolkoztam, basicben DATA sorokban tárolva nagyobb pályákat könnyen elfogy a hely. Nem tudom, basicben ilyenre lehet-e valami jobb, kisebb helyet igénylő megoldás.mivel a pálya adatok esetében sok az ismétlődés, BASIC-ben is lehetne egy egyszerű RLE tömörítést használni:
Bonyolultabb/bitenként olvasott formátum hatékonyabb lehetne.Valamelyik ilyen módszernél meg lehetne oldani azt, hogy egy CALL legyen azon a ponton amikor elkészült egy bájt? Valami olyan fomában, hogy híváskor a cél cím helyett a rutin cím lenne átadva. (SD-nél két külön féle rutint kell hívni az első 48K és a lapozható 8x8K írásához.) Illetve, hogy egy szegmenslista alapján korlátlan memória méretből folytatólagosan dolgozzon? (Azaz amikor elfogy egy szegmensnyi tömörített adat, akkor lapozza magának a következőt. Itt gondolom jelentősen bonyolítja a dolgot, hogy bitenkénti feldolgozásnál szegmenshatáron átnyúlás is lehet :oops: )
mivel a pálya adatok esetében sok az ismétlődés, BASIC-ben is lehetne egy egyszerű RLE tömörítést használni:Viszont ha nem ilyen kedvező az adatok struktúrája, valamilyen bináris tömörítést ASCII kódolásban még mindig lehet csinálni. Ha például a 33-tól 96-ig kódú karaktereket vesszük, akkor egy jelben 6 db 1 bites (= kétféle elem), 3 db 2 bites (= négyféle elem) vagy 2 db 3 bites (= nyolcféle elem) adatot kódolhatunk egyszerűen.
pl.: nyers pálya adat: AAAABBBAAAACCAA (15 byte)
tömörítve: 4A3B4A2C2A (10 byte)
Viszont ha nem ilyen kedvező az adatok struktúrájaEgyelőre olyanra gondoltam, mint az Entersnake, meg az ilyen pacman jellegű játékok, ahol leginkább csak fal van és szóköz a pályán. Erre Povi módszere jónak tűnik. Még a sorok végén gondolkozom, hogy ha sok fallal végződik egy sor, és a következő sor elején is fal van, akkor azt is egyben lenne jobb letárolni, de ezen már talán úgyse lehet jelentősen sokat spórolni.
pl.: nyers pálya adat: AAAABBBAAAACCAA (15 byte)ez csak egy nyers elméleti példa.
tömörítve: 4A3B4A2C2A (10 byte)
(mondjuk így már szerintem pont nem DATA soronként lenne érdemes tárolni, nem hiszem, hogy a DATA 65,66,67 sor az nyers "ABC"-ként fog eltárolódni a RAM-ban :-) )Csak hát szipucsunak pont az volt a szíve vágya, hogy BASIC-ben, DATA sorokban lásson megoldást adattömörítésre. Amire az első megoldásod szerintem kiváló volt, míg ez utóbbi azért küzdhet problémákkal. Ha teljesen bináris adatokat akarnánk használni, azt szerintem jobb lenne külön fájlból betölteni és direkt memória olvasásokkal kezelni a BASIC programban.
(mondjuk így már szerintem pont nem DATA soronként lenne érdemes tárolni, nem hiszem, hogy a DATA 65,66,67 sor az nyers "ABC"-ként fog eltárolódni a RAM-ban :-) )Tuti nem :)
vagy a stringes megoldást érdemes használniA stringes megoldás is jó. A pályaszerkesztő mindegy, mibe menti a pályát. De DATA után is lehet stringként tárolni a pályaelemeket, vessző nélkül. De még vesszőkkel is nagyságrendekkel kisebb helyet foglalna, mint tömörítés nélkül, szerintem.
Ilyen célra nem lenne használható a korábban készített ROM: eszközhöz (romfsdev.asm) hasonló megoldás?Igen, jó lehetne annak egy módosulata is. Esetleg az is segíthet ez esetben, hogy nem ROM-ból futna a kicsomagoló kód, hanem a nullás lapon, így van lehetőség eltárolni változókat, vagy esetleg önmódosító kódot használni.
Tuti nem :)
100 ALLOCATE 100
110 CODE ADAT=HEX$("50,29,1a,00")
120 LET CIM=ADAT
130 DO
140 LET C=PEEK(CIM)
150 LET CIM=CIM+1
160 IF NOT C THEN EXIT DO
170 FOR I=1 TO INT(C/8)
180 PRINT CHR$((C BAND 7)+65);
190 NEXT I
200 LOOP
0x50 = 80 = 10 * 8 + 0
0x29 = 41 = 5 * 8 + 1
0x1a = 26 = 3 * 8 + 2
az m2 tömörítésre miért írja azt a wikis leírás, hogy "elavult és általában nem ajánlott a használata"?
Mivel a nem m3 formátumokat eddig is többnyire csak én használtam, nem tartottam érdemesnek ezeket kiadott verzióba beépíteni.Én használtam őket :-)
A 2.0.11.2 emulátor csomagban található epcompress már nem tartalmazza a régi formátumok többségét, csak az m3-at és az m2 lebutított (gyorsan tömörítő, de kevésbé hatékony) változatát. Az utóbbira a snapshotok és az ep128emu_roms.bin file miatt van szükség kompatibilitási célból. Mivel a nem m3 formátumokat eddig is többnyire csak én használtam, nem tartottam érdemesnek ezeket ...En is hasznaltam, sot hasznalom is, mostanaban a legtobbet az m4-et, de volt egy m0-s is, es ha jol emlexem, az egyik tvc programban m6-ot hasznaltam. M3-at a legritkabban :-)
epcompress.exe -raw -m6 file.bin file.pck
Olyan mintha szándékosan el akarta volna tűntetni az információkat hogy ne legyen "public domain" többé.Igen, István megsértődött, hogy nem érkezett elég pozitív hozzászólás, nem használták elég sokan, ezért letörölt egy csomó mindent. És az emulátoros csomagban is lebutította az epcompress-t. Ha teljes tudású változatot szeretné az ember, akkor előbb egy régebbi ep128emu-t kell telepíteni, abból elmenteni az epcompress-t, és aztán frissíteni a legújabb emura, és abba visszamásolni az elmentett teljes tudású epcompress-t.
Igen, István megsértődött, hogy nem érkezett elég pozitív hozzászólás, nem használták elég sokan..
Igen, István megsértődött, hogy nem érkezett elég pozitív hozzászólás, nem használták elég sokan, ezért letörölt egy csomó mindent.
Megtaláltam a gépemen azt a 2018-ban letöltött 2.0.11.2 ep128emu-t, amiben még teljes az epcompress.Jól tetted, hogy feltetted :)
enterprise.iko.hu/ep128emu-2.0.11.2-teljes.zip (http://enterprise.iko.hu/ep128emu-2.0.11.2-teljes.zip)
Úgy emléxem, hogy én is feltöltöttem ide a ZIP fájlt anno, de lehet rosszulAbban csak maga az epcompress.exe van. Ezek a teljes ep128emu telepítők, ami felrakja a forrásszövegeket is, amibe benne vannak a Z80-as kicsomagoló kódok is.
Abban csak maga az epcompress.exe van. Ezek a teljes ep128emu telepítők, ami felrakja a forrásszövegeket is, amibe benne vannak a Z80-as kicsomagoló kódok is.
Illetve ott van a teljes emu forráskód is, valaki aki ért hozzá, visszacsempészhetné ezekre a github, sourceforge akármi oldalakra a teljes verziót :oops:
Megnéztem, hogy a windows-os installer, amit linkeltetek, milyen epcompress forrásokat installál: nem teljesen ugyanazt, mint ami ezen a tag-en van. Az eggyel korábbi commit tartalmával (commit hash: 024973f) viszont egy az egyben megegyezik.Valószínűleg amit találtam az nem az utolsó volt. Emlékszem, hogy István többször írta, hogy miket optimalizált még a különböző tömörítéseken. És amikor ezekre nem érkezett elég gyorsan, elég sok reakció, akkor jött a törlés...
Találtam még egy 2019.03.21-es verziót, amiben még teljes, de ebből csak az x64 verzió van meg.Asztem csak a forrást keressük :)
Asztem csak a forrást keressük :)
Az "epcompress.exe" PC programmal be lett tömörítve egy fájl a következö paraméterrel:Code: [Select]epcompress.exe -raw -m6 file.bin file.pck
Letöltöttem a legutolsó EP128 emulátort, de nem tudom kicsomagolni a könyvtárban lévô epcompress.exe programal, mert (szertintem) nem ismeri a "-m6" formátumot, csak m3-ig tud.
Valaki tudna segíteni, honnan tudnám beszerezni a legutolsó verziót?
Úgy látom, hogy a forrás, amit feltöltöttem, az egyik utolsó lehetett, ha nem az utolsó, ami tartalmazta a teljes EPCOMPRESS-t, mert a fájlok 04.17-esek.Na egy pendriveon megtaláltam hozzá a telepítőket is :ds_icon_cheesygrin: