Welcome, Guest. Please login or register.


Author Topic: Fájltömörítés Enterprise-on (Read 72854 times)

Offline geco

  • EP addict
  • *
  • Posts: 5088
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 52.0 Firefox 52.0
    • View Profile
Re: Fájltömörítés Enterprise-on
« Reply #315 on: 2018.April.30. 13:14:18 »
Nagyon jól hangzik, legtöbb esetben a tömörített fájl is kisebb, na de a tömörítő mérete mindent visz :)
Most látom, de lehet meg vagyok csúszva :oops: , hogy az emulátor forrása már 2.0.11.2-es , kérhetnék belőle egy winfos installert is? Abban gondolom akkor már az új epcompress is lenne :)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4756
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: Fájltömörítés Enterprise-on
« Reply #316 on: 2018.April.30. 14:13:14 »
Még egy példa, a Bricky Prise pálya adata -m6:F90L,01234567,0123,01234567,01234567 tömörítéssel az eredeti 15229 helyett 13482 byte, és az ehhez a formátumhoz készült rutin csak 67 byte (bár ez nem sebességre, hanem méretre optimalizált):
* brickym6.s (0.99 kB - downloaded 76 times.)

Nagyon jól hangzik, legtöbb esetben a tömörített fájl is kisebb, na de a tömörítő mérete mindent visz :)

A méret elvileg nem változik a fejléctől eltekintve, fordított irányt beállítva (-m6:BG1R,G,,12345678,0123456789ABCDEF) az m6 mindig pontosan 2 byte-tal kisebb mint az m3. Az iránynak nem kellene hatással lennie a file méretére, ez talán arra utalhat, hogy valahol bug lehet az optimalizálásban. :oops: De az átlagos méret így sem változik, gyakorlatilag véletlenszerű, hogy valamivel kisebb vagy nagyobb lesz-e a file. Eltérő kódolással viszont természetesen változik a méret, az adattól függ, hogy mi az optimális.
« Last Edit: 2018.April.30. 14:59:16 by IstvanV »

Offline IstvanV

  • EP addict
  • *
  • Posts: 4756
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: Fájltömörítés Enterprise-on
« Reply #317 on: 2018.April.30. 15:45:01 »
Most látom, de lehet meg vagyok csúszva :oops: , hogy az emulátor forrása már 2.0.11.2-es , kérhetnék belőle egy winfos installert is? Abban gondolom akkor már az új epcompress is lenne :)

Itt található 32 és 64 bites is, bár az epcompress még változhat.

Az m6 formátum definíció leírása:

-m6:ÁLTALÁNOS,HOSSZÚSÁG,TÁVOLSÁG1,TÁVOLSÁG2,TÁVOLSÁG3

Paraméterek nélkül csak az -m6 a forráskódban található decompress_m6.s rutinnal kompatibilis formátumot állít be. Kis- és nagybetűk is használhatók.

Általános paraméterek:

F: normál irány (forward), az LDIR-hez hasonlóan
B: fordított irány (backward), ilyenkor az adatot a végétől visszafelé haladva kell kicsomagolni
9: a tömöríthetetlen byte-ok egyszerűen 9 bitesek lesznek (1b + eredeti byte, a file elején nincs jelzőbit)
G: a tömöríthetetlen byte-okat sorozatként tárolja, először a hosszúság Elias gamma kódolással, majd az eredeti adat. Ezt mindig tömörített sorozat követi, és a file mindig ilyennel kezdődik. Tömörített sorozat után jelzőbit adja meg a következő sorozat típusát (1 = tömörítetlen)
L: a bitenként olvasott adatot balra kell léptetni (SLA)
R: a bitenként olvasott adatot jobbra kell léptetni (SRL)
0: normál jelzőbitek (0..01)
1: invertált jelzőbitek (1..10), a régebbi formátumok ezt használják

Hosszúság:

Ez a tömörített sorozatok hosszúságának a kódolása, ami lehet egyszerűen "G" is, ez a már említett Elias gamma kódot állítja be ('0123456789ABCDEF", 1 és 65535 közötti hosszúságot támogat, 16 '0' bit a file végét jelzi), és többnyire elfogadható eredményt ad. A definíció működése talán megérthető az alábbi példa alapján, "0128" megadásakor:
  1b + 0 bit: 1
  01b + 1 bit: 2-3
  001b + 2 bit: 4-7
  0001b + 8 bit: 8-263
  0000b: file vége

Ha a minimális hosszúság nagyobb 1-nél (lásd lent), akkor minden értéket megfelelően növelni kell.

Távolság1:

Az 1 byte hosszúságú tömörített sorozatoknál a távolság kódolása. Ha üres, akkor az ilyenek nem támogatottak, és a minimális hosszúság 2 lesz. Lehet "I" és "X" közötti karakter, ami egyszerű fix méretű kódot jelent 1 és 16 bit között, például a "K" 3 bites, 1 és 8 közötti távolságot tesz lehetővé. Ebben a módban ha lehetséges, akkor az alsó 8 bitet (illetve "X"-nél a teljes értéket) egyszerű byte-ként írja ki az epcompress. Ez hasznos lehet akkor, ha a sebesség a fontos kicsomagolásnál. Egyébként a fentihez hasonló rendszer szerint írható le a kódolás, de "G" nem használható, és kissé eltér a kimeneti formátum. Például az '1234" ezt jelenti:
  00b + 1 bit: 1-2
  01b + 2 bit: 3-6
  10b + 3 bit: 7-14
  11b + 4 bit: 15-30


Távolság2:
Távolság3:

Az előzőhöz hasonlóak, csak 2 byte, illetve 3 vagy hosszabb sorozatokhoz. Az utóbbi nem lehet üres, viszont ha az 1-es és a 2-es üres, akkor 3 lesz a minimális hosszúság.
« Last Edit: 2018.April.30. 15:50:33 by IstvanV »

Offline geco

  • EP addict
  • *
  • Posts: 5088
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 59.0 Firefox 59.0
    • View Profile
Re: Fájltömörítés Enterprise-on
« Reply #318 on: 2018.April.30. 17:07:39 »
Köszi szépen a leírást is, le is mentettem :)

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13081
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 63.0 Firefox 63.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Fájltömörítés Enterprise-on
« Reply #319 on: 2018.November.15. 11:58:13 »
István!
Az m3-as kicsomagoló rutint lehetne úgy módosítani, hogy a ki és bemenetnél egyaránt figyeljen a lapozásra? Azaz olyan működés, hogy ha a forrás vagy cél szegmensből kifut, akkor vegye a következőt.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4756
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: Fájltömörítés Enterprise-on
« Reply #320 on: 2018.November.15. 14:09:55 »
m2-höz már van ilyen különböző programokban (iplay, uncompress, SIDBasic). Ha ez nem megfelelő, akkor talán célszerűbb lenne az m6 használata, ami az m3-hoz hasonlóan egyszerű lehet, de rugalmasabb és támogat normál irányú adatfolyamot. Ha a csomagolandó adat már létezik, akkor ahhoz lehetne a legjobb formátum paramétereket és rutint választani.

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13081
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 63.0 Firefox 63.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Fájltömörítés Enterprise-on
« Reply #321 on: 2018.November.15. 14:37:20 »
Jó lehet másik verzió is, ami lényeges lenne, hogy ROM-ból is fusson (ne legyen önmódosító), és ha lehet ne kelljen címre igazítva elhelyezni.
Az egyik cél az SD cartridge lenne, itt most nincs ISDOS, mert az alap 7-es szegmensbe már nem fért be, de ott vannak még a plusz lapozható 8K részek. (A normál EXDOS 1.4+ISDOS ROM-ban most m3-al van csomagolva, de simán átcsomagolható más formátumra.)
A másik a ROM-ba írható játékok témája, itt egy EXOS device-ről megy töltés, az USR_Px változókban megadott szegmensekre, egymást követő ROM szegmensekről.
 
Quote
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?

Offline IstvanV

  • EP addict
  • *
  • Posts: 4756
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: Fájltömörítés Enterprise-on
« Reply #322 on: 2018.November.15. 15:06:24 »
Az egyik cél az SD cartridge lenne, itt most nincs ISDOS, mert az alap 7-es szegmensbe már nem fért be, de ott vannak még a plusz lapozható 8K részek. (A normál EXDOS 1.4+ISDOS ROM-ban most m3-al van csomagolva, de simán átcsomagolható más formátumra.)
A másik a ROM-ba írható játékok témája, itt egy EXOS device-ről megy töltés, az USR_Px változókban megadott szegmensekre, egymást követő ROM szegmensekről.

A legjobb lenne talán feltölteni a csomagolandó adathalmazt, illetve hasznos lenne még valamilyen ismert fix memória térkép (pl. 3. lapon a kód, 2. lapon a verem, 1. lapon a kimenet, 0. lapon pedig átmenetileg belapozva a bemenet).

De ha jól értem, ez valójában mind eredetileg 5-ös fejlécű program lenne? Akkor talán célszerűbb lenne először csak a 0-2. lapra másolni a csomagolt adatot, majd lefuttatni a rutint (ami még lehet a ROM-ban) és a 0100h címre ugrani.

Quote
Ez azt jelenti, hogy úgy hívható, mint egy egy normál EXOS fájl olvasás, tetszőleges bájtot/blokkot kérve?

Az m3 formátum az adatot a végétől visszafelé haladva dolgozza fel (mint az LDDR utasítás), az adat legfeljebb 64K méretű lehet és nem blokkos szervezésű. Ez előnyös például önkicsomagoló programoknál, de hosszú (több szegmensre bontott) adatfolyamnál kevésbé praktikus. Az m0, m1, m2 és m4 normál irányú és blokkos felépítésű, a blokkok tetszőleges méretűek lehetnek (legfeljebb 64K), hivatkozhatnak a korábbi blokkok tartalmára, a teljes file mérete jelenleg 64 MB lehet, ami az epcompress korlátozása.

Az m6 normál és fordított irányt is támogat, a formátum a felhasználó által definiálható (emulálhatja az m3-at is megfelelő paraméterekkel), de ez sem blokkos, és jelenleg legfeljebb 1 MB méretű bemeneti adatot fogad el.

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13081
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 63.0 Firefox 63.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Fájltömörítés Enterprise-on
« Reply #323 on: 2018.November.15. 16:07:23 »
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.)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4756
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: Fájltömörítés Enterprise-on
« Reply #324 on: 2018.November.15. 17:04:17 »
Tehát EXOS 6 emuláció a cél, és ilyen paraméterekkel használható lenne?
- tömörített adat kezdőcíme a ROM-ban, szegmens (A) és cím (HL), a szegmens végét elérve a következő szegmensen folytatódik (egyszerűen szegmens szám + 1, vagy táblázat?)
- kicsomagolt adat kezdőcíme a felhasználói RAM-ban bárhol (DE)
- minden más regiszter elrontható
- kód a 3. lapon (nem lehet önmódosító), rendszerszegmens és verem a 2. lapon
- felhasználói RAM szegmensek táblázata a BFFCh-BFFFh területen
- megszakítások tiltva (tehát a 0. lap szegmens átmenetileg kilapozható és BFFCh címről visszaállítható)
- a tömörítésnél valószínűleg -maxoffs 16384 használatára lesz szükség, ami ronthatja a hatékonyságát

Szerk.: ha a programok nem töltenek a 0100h alatti területre, akkor használható a DTF-es RST 28H-hoz hasonló megoldás is, a 0. lap elejét átmenetileg mentve (pl. az EXOS verembe másolva), és a kicsomagoló rutint erre a területre másolva. Így mind a négy felhasználói szegmens belapozható a futása közben.
« Last Edit: 2018.November.15. 18:17:22 by IstvanV »

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13081
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 63.0 Firefox 63.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Fájltömörítés Enterprise-on
« Reply #325 on: 2018.November.15. 19:47:00 »
Igen valami ilyesmi.
Quote
egyszerűen szegmens szám + 1
Igen.

Lehet csatorna RAM-ot is kérni, ahol eltárolhatóak változók, vagy akár a kód (egy része) is átmásolható. Ezt az 1-es lapon adja át az EXOS, IX-el címezve.
És akkor a 3. lapon lapozgatni a forrást, a 0.-on meg a célt.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4756
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: Fájltömörítés Enterprise-on
« Reply #326 on: 2018.November.20. 17:44:46 »
Első próbálkozás, ez egyelőre epcompress -raw -m4 formátumot használ, és még hibás lehet:

* batman.rom (32 kB - downloaded 14 times.)    (:BATMAN parancs indítja)
* decomp.asm (10.21 kB - downloaded 12 times.)    (forráskód, a lényeges rész a resetRoutine alatt kezdődik)
* batman.bin (28.96 kB - downloaded 13 times.)    (BATMAN.APL fejléc nélkül, epcompress -raw -m4 -X paraméterekkel tömörítve)

Jelenleg 3.41 másodperc alatt tölti be alapértelmezett memória várakozással, ami kb. 20% lassulás a decompress_m4.s-hez képest. :oops: Ezen talán még lehetne javítani, bár a kicsomagolás közbeni lapozás miatt nehéz elkerülni a lassulást. Másik lehetőség lenne először az egészet a RAM-ba másolni, és ott futtatni egyszerű (m3-as) rutint a 0. lap elején.

A decompressData rutin használata:
- forrás cím AHL-ben, A = első ROM szegmens, HL = cím a szegmensen belül (bármelyik lapon), hosszú adat a következő szegmens(ek)en folytatódhat
- DE = cél cím a felhasználói RAM-ban, lapozás a BFFCh-BFFFh táblázat alapján
- mindegyik általános célú Z80 regisztert (AF, BC, DE, HL, AF', BC', DE', HL', IX, IY) elrontja, és az 1. lapot is, a 0. lapot a BFFCh címről állítja vissza
- letiltja a megszakításokat, és így is tér vissza, ezen lehetne módosítani ha a hosszú ideig tiltott megszakítás kezelés probléma
- feltételezi, hogy a kód a 3. lapon fut, a 2. lapon a rendszerszegmens látható, és itt található a verem is, ahol legfeljebb 412 byte extra területet igényel táblázatok számára (156 byte + 256 byte-os határra igazítás)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4756
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: Fájltömörítés Enterprise-on
« Reply #327 on: 2018.November.20. 18:00:30 »
Lehet csatorna RAM-ot is kérni, ahol eltárolhatóak változók, vagy akár a kód (egy része) is átmásolható. Ezt az 1-es lapon adja át az EXOS, IX-el címezve.

Ez használható lehetne az EXOS verem helyett, de ha video RAM-ban foglal helyet, akkor kód számára nem lenne ideális.

Ha nem probléma valamivel rosszabb (m3-hoz hasonló) tömörítés, akkor a fenti forráskód könnyen átalakítható lenne m6 használatára. Így elkerülhető a táblázat, és gyorsulna is. Azonban ha a sebesség a legfontosabb, akkor talán a teljes RAM-ba másolás és a 0. lap átmeneti felülírása lenne előnyösebb (de a különbség valószínűleg nem nagy, mert a másolás is időt igényel, és az m6 rutin lapozás nélkül gyorsabb mint a helyben kicsomagolást támogató m3-as).
« Last Edit: 2018.November.20. 18:38:47 by IstvanV »

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13081
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 63.0 Firefox 63.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Fájltömörítés Enterprise-on
« Reply #328 on: 2018.November.20. 19:51:10 »
Köszi!
A sebesség annyira nem számít. Az lenne jó, ha átlag 32K-ba beférne egy játék, így kettő is mehetne egy cartridge-be.

A mostani kód is elég lassú, bájtonként nézi a lapozást :oops:


Offline IstvanV

  • EP addict
  • *
  • Posts: 4756
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: Fájltömörítés Enterprise-on
« Reply #329 on: 2018.November.20. 21:31:54 »
Kisebb módosítások a használhatóság javítására, ez a verzió nem rontja el az IX regisztert (ami a csatorna területre mutathat), és a frissített olvasási pozíciót visszaadja HL-ben az 1. lapon. A szegmens számát a B' regiszter tartalmazza, de a B1h portról is olvasható. A pozíció mentése hasznos lehet, ha több EXOS 6 hívás is történik ugyanazon a csatornán. A Batman kicsomagolása minimális mértékben gyorsult is (most 3.38 másodperc).

* decomp.asm (10.19 kB - downloaded 13 times.)