Dzięki! Wziąłem z pierwszego postu.

Edit: Mieszkał w Wiśle sum wąsaty...:

$ sha256sum Landscape.xex
fec490cd1eb40132b818d1bf4b64e09b356eda5fdae541343322043fad22ac58  Landscape.xex
$ sha256sum RiverRaid.rom
dc55bef6fa336003772643e68b9bfade7155ff4dde1aad814e1cf56ad818805f  RiverRaid.rom
$ sha256sum conan.gfx
f135b5eaabb3ffc5ed5eae90775c1d9d8cf37b4909f0240de3282467b75b6664  conan.gfx

Edit 2: Rzeczywiście - .zfl to zopfli --deflate -i1000, .dfl to deflater:

 7680 conan.gfx
 1671 conan.gfx.dfl
 1599 conan.gfx.zfl
30653 Landscape.xex
14491 Landscape.xex.dfl
13486 Landscape.xex.zfl
 8192 RiverRaid.rom
 6292 RiverRaid.rom.dfl
 6192 RiverRaid.rom.zfl

Ostatnio edytowany przez mono (2022-10-11 09:00:25)

szok i niedowierzanie... dostepne zrodla na z80....

pewnie w weekend pojawi sie dla Atari :-)

https://github.com/pfusik/upkr6502

241 bajtów. Szybsze od 471-bajtowej depakowaczki Shrinklera.

Ostatnio edytowany przez Fox (2024-05-13 10:11:08)

https://github.com/pfusik/upkr6502/blob/master/Makefile

To wstępna wersja, mogą być błędy. I pewnie da się jeszcze nieco wycisnąć.

Fajnie, że paker ma taki tuning.

-9 = najwyższy stopień kompresji
-b = pobieranie wejścia po bicie, dzięki czemu mamy mnożenie 8x8, bez tego 12x8
--invert-continue-value-bit = oszczędza jeden bajt kodu depakowaczki, nie zmienia rozmiaru spakowanych danych
--simplified-prob-update = upraszcza pewien fragment dekodera, z tego co widzę kosztem kompresji niektórych danych słabszej o promile

236 bajtów i kilka procent przyspieszenia. Co do opcji, spójrz trochę wyżej.

Dopiszesz wyniki i link w pierwszym poście?

dodane :-)

bufor ma 320 bajtów - nieduzo...

Kiedyś napiszę README (prawdziwy programista nie pisze dokumentacji ;)

236 bajtów na kod (może być w ROMie, nie modyfikuje się)
319 bajtów na bufor (najlepiej od granicy strony)
14 bajtów na stronie zerowej, z czego na początku standardowo wskaźniki na spakowane i gdzie rozpakować

Trochę wolne, ale analogicznie jak w Shrinklerze dam dopałkę mnożenia tablicą kwadratów jako opcję.

218 bajtów.

Opcja 305 bajtów kodu z akceleracją mnożenia dwukilobajtową tablicą. 133 ramki zamiast 214 na testowym obrazku.
Bonus: tę tablicę można potem wykorzystać do mnożenia bez znaku.

Edit:
I mnożenie na Lynxie. Uwaga, nie testowałem.

Ostatnio edytowany przez Fox (2024-07-05 20:32:22)

Zrobiłem test dla Lynksa kompresując jakiś losowy obrazek z sieci, wygenerowałem trzy wersje: z pętlą, z tablicami oraz z użyciem sprzętowego mnożenia i prawdę mówiąc "na oko" te dwa ostatnie są bardzo zbliżone. Nie potrafię od ręki policzyć czasu, ale w emulatorze policzyłem wykonane instrukcje i wyszło mi:

loop: 5527257
table: 3172612
math: 3045851

Z tym, że wersję ze sprzętowym mnożeniem można jeszcze podrasować, ale to trzeba testować na prawdziwym Lynksie, do którego nie mam teraz dostępu.

Załączam źródła, obrazek i binarki, teraz skompiluje się wersja z pętlą, łatwo przestawić na wersję z tablicami, ale wersja z mnożeniem wymaga hakowania źródeł, bo faktycznie MADS nie potrafi tego skompilować.

Ostatnio edytowany przez laoo/ng (2024-07-07 00:04:14)

Sprawdziłem najnowszą wersję na najnowszym MADSie. W emulatorze działa. Na oko tak samo, ale jak policzyłem instrukcje to spadło z 3045851 do 2780943. Ostateczny test trzeba zrobić na prawdziwym Lynksie.

Zresztą ściagnij Felixa i podaj mu upkr_math.lyx za argument (albo zrób drag&drop) i zobacz. Jak w tym samym folderze co upkr_math.lyx będzie upkr_math.lyx.lua to wygeneruje Ci trace z dekompresji (w folderze roboczym, czyli teraz tam gdzie jest Felix.exe, muszę to zmienić na folder z obrazem cartridge'a). Tak, w skrypcie jest literówka, muszę to poprawić :)

EDIT: kod miał błąd - nie działał na prawdziwym Lynksie. Dodałem poprawiony niżej

Ostatnio edytowany przez laoo/ng (2024-07-08 08:16:13)

Poprawiony kod, bo był zabugowany i nie działał na prawdziwym Lynksie (A właściwie z oryginalnym ROMem)