Persze ez a program is elveszett...

Kár...
Biztos nincsenek meg valahol a kazetták/lemezek, ahol az eltûntnek vélt programjaid vannak? Nem keveredtek pl. az audió kazetták közé vagy valami?

Amúgy az érdekesség kedvéért kiváncsi lennék, hogy a Hungry Creature címû játékomban basicbõl a DATA sorokban lévõ pályákat mennyire lehetne betömöríteni. Nyilván ahol egynél több fal vagy "nem fal" jön egymás után, ott "összenyomná" az adatokat, de lehetne ennél többet is? Gyakorlati haszna talán nem túl sok lenne, max. kisebb lenne vmivel a fájl és esetleg gyorsabban kirajzolná a pályát.
Ahogy elkezdek rajta elmélkedni, egy olyan esetben, amikor vízszintesen csupa fal van, ez lehetne a DATA sorban: 38,x. Egyéb DATA sorok talán valahogy így néznének ki: 1,y,12,x,1,y,3,x,1,y,10,x,1,y (x=fal, y="járat"). Van olyan is néha, hogy fal és járat sûrûn váltogatja egymást, erre lehetne mondjuk "z" jelölést használni, és akkor az lenne a DATA sorban, hogy 7,z. És meg lehetne nézni, a fal és a járat kombinációiból milyen esetek fordulnak elõ gyakran. Kár, hogy erre régebben nem gondoltam. Szerintem igen jelentõs helyet meg lehetett volna spórolni a DATA sorokban. És talán azért is egyszerû, mert max. két-három karakter (fal, járat, akadály) válthatja csak egymást. Ahol 127 karakter fordulhat elõ valamilyen adathalmazban, azt sokkal bonyolultabb lehet tömöríteni, ebbe belegondolni sem tudok, hogyan lehetne.
Tudtok esetleg még valamit, amivel még jobban össze lehetne nyomni a pályákat a HC-ben? Pl. a szimmetrikus, tükrözhetõ pályákat biztos még jobban lehetne tömöríteni, de szerintem sokkal bonyolultabb eljárás kell ahhoz, hogy ne csak az egymás mellett lévõ karaktereket vegye figyelembe.

Egyébként egy érdekesség: a Dot collector címû játékban turkálva kiderült, hogy mindegyik pályánál a pálya körül lévõ falat (keretet) is külön tárolja a program. Ennek nincs sok értelme, mert minden pályánál ugyanaz. Még kisebb is lehetett volna így a Dot collector játék. (Hát még ha a pályákat is tömörítve tárolják. ) Én a HC-nél úgy csináltam, hogy a keretet ne tárolja már a program külön DATA sorokban.

esetleg gyorsabban kirajzolná a pályát.

Gyorsabb biztos nem lenne. Pláne BASIC-ben...

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!!!

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.
A tömörítõm az adott tömörítendõ fájlra ezt az optimum számítást el is végzi.  Méghozzá többféle tárolási bitszám kombinációkkal és ezekbõl a legkisebb fájlméretet adó tárolási rendszert választja és úgy végzi el a tömörítést. Mivel azonban elvileg elég sokféle kombináció elképzelhetõ, ezért csak egy értelmes tárolási módszer esetet analizál. Ezért az esetek döntõ többségében szinte mindig ugyan azt a rendszert választja. Persze csináltam extrém fájlokkal is próbát, mint például csak 10 -20 féle bájtot tartalmazó fájlokkal, ezeknél már más módszer a célravezetõbb, mint például egy statisztikailag "kaotikusabb" Z80 kód esetében.

Egy kis adalék a DTF születéséhez. 
Kezembe akadt egyszer egy könyv tömörítési eljárásokról, amiben le volt írva többek közt a stasztikai tömörítés elve is. Akkortájt kevés és drága volt a floppy lemez, hogy több átirat ráférjen, valamint hogy valami hasznosat is programozzak és ne csak spectrum átiratokat gyártsak, nekiálltam a megvalósításnak. Persze a "helyszûke" manapság már nem oly mérvadó, mint akkor volt, a hardver legyõzte a szoftvert, de mégis még manapság is fejlõdnek tömörítõk a Terabájtos vinyók korában. Viszont a matematikai, szellemi kihívás azért nem semmi!!

Köszönöm István, hogy te tökéletesítetted a megvalósítást és a statisztikai tömörítés hatékonyságát!

Persze ez az elv nem minden tömörítendõ anyaghoz a leghatékonyabb, hisz speciális fájlokhoz jóval hatékonyabb eljárásokat is kitaláltak már. Például hanghullám fájloknál az ogg, mp3, vagy képeknél a jpeg, vidóknál az mpeg. Érdekes, hogy ezek is állandóan fejlõdnek (MPEG2 - h264 a DVB világában) Azonban, ha már minden más tömörítési algoritmus csõdöt mond, akkor az utolsó szalmaszál a statisztikai mód. Ennek eredménye már a teljes bitkáosz, vagy "fehérzaj", ami már tovább tömöríthetetlen. 

WEC Le Mans (CPC átirat):
  [ Guests cannot view attachments ]
  [ Guests cannot view attachments ]

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.

Joystick javítva:
  [ Guests cannot view attachments ]
A wecleman.com file (azaz tömörített program betöltő) ugyanaz, mint az előbbi változatban.

Javított tömörítetlen PRG (csak egy 00h 08h 10h 08h 20h byte-sorozatban cseréltem a második 08h-t 18h-ra):
  [ Guests cannot view attachments ]

Nekem egyébként volt betöltőkép EP64-en (magnó+FileIO konfiguráció).

Sorcery+:
  [ Guests cannot view attachments ]
  [ Guests cannot view attachments ]

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