WHB, javított (nem ciripelő ) és sztereó hanggal:
  [ Guests cannot view attachments ]
  [ Guests cannot view attachments ]
Hibák előfordulhatnak, illetve egy biztosan van: a melegindítás nem működik EP64-en.

UI.: már újabb verzió is van itt.

Nem egészen ebbe a topicba tartozik, de ide írom
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

Az átíráshoz nem kell feltétlenül érteni, hogyan működik a tömörítés

,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).

A "dtf -lz" formátum jóval egyszerűbb, mint a RAR, így talán nem meglepő, hogy valamivel nagyobb. Bár nem tudom, hogy aminél 5KB-al nagyobb lett, az Spectrum vagy PC RAR-al készült, illetve hogy azok között mekkora eltérés van. Mindenesetre a RAR-hoz legközelebbi bonyolultságú formátum EP-n az "epcompress -m0".

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ú).
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.
 

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. 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
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?

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á
Ezt a tömörítő algoritmus bonyolultságára írtam

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

Találtam egy hibát A "dtf -cl -lz2" nem mu"ködött. Javított verziót töltöttem fel.

jaja, -a-val csomagoltam, csak a tömörített állományban nem láttam a file-ok neveit

Mert azok is tömörítve vannak De az "epcompress -a" formátumnál valóban csak az egészet egyszerre lehet kitömöríteni (hasonlóan a RAR-hoz "solid" módban).

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.

A "dtf -cr -lz2" kimenete annyiban tér el az "epcompress -raw -m2"-to"l, hogy több file-t is lehet csomagolni (illetve file-t darabolva tárolni), és minden egyes tömörített file/adatblokk elo"tt van két byte, amely az adat méretét tárolja.
"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.