Odp: Najlepszy Packer dla Atari
@mono: deflater był dobry dwie dekady temu. Teraz robi się tak: https://github.com/pfusik/zlib6502#Compression
Skąd brałeś Landscape.xex i RiverRaid.com? Albo chociaż wklej ich sha256sum.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Silly Venture 2024 SE - stuff Dostępny jest już stuff z zeszłomiesięcznego party Silly Venture 2024
FujiCup FujiCup ma na celu wspieranie sceny gier retro, dając uczestnikom szansę na pokazanie swojego talentu
Echa Silly Venture 2024 SE Są już dostępne wyniki Silly Venture 2024 SE
Uaktualnienie firmware do The400 Poprawki do "fizycznego" emulatora ośmiobitowych komputerów i konsol Atari.
Akcja - Wsparcie w reverse-engineering Wspierajmy tych, którzy do tej pory zrobili wiele!
Strony Poprzednia 1 2 3 4 5 6 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
@mono: deflater był dobry dwie dekady temu. Teraz robi się tak: https://github.com/pfusik/zlib6502#Compression
Skąd brałeś Landscape.xex i RiverRaid.com? Albo chociaż wklej ich sha256sum.
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)
Poproszę dopisać:
Upkr: 1403 (upkr -9) https://github.com/exoticorn/upkr
RiverRaid.rom: 5945
Landscape.xex: 12480
Ostatnio edytowany przez Fox (2024-05-09 13:29:49)
No kod na Z80 wygląda nieźle... Na Lynxa słabiej.
Respect dla TeBe za danie cynku.
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)
dla jakich parametrów kompresowany jest plik? nie udało mi się dokonać dekompresji
https://github.com/pfusik/upkr6502/blob/master/Makefile
upkr -9 -b --invert-continue-value-bit --simplified-prob-update conan.mic conan.upk
działa :)
kombinacja parametrów wyborna
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
wow... ja jestem na ponad 300 bajtow :/ a i to jeszcze nie zle dekompresuje ;-) jeszcze chwile powalcze bez podgladania zeby pocwiczyc umysl...
uzywasz tego do kompresji?
--z80 --big-endian-bitstream --invert-bit-encoding --simplified-prob-update -9
ale fakt jest szybszy od shrinklera i lepiej pakuje... nowy lider
236 bajtów i kilka procent przyspieszenia. Co do opcji, spójrz trochę wyżej.
Dopiszesz wyniki i link w pierwszym poście?
Ładnie to działa:
upkr -9 -b --invert-continue-value-bit --simplified-prob-update conan.gfx conan.gfx.upk
Compressed 7680 bytes to 1403 bytes (18.268229%)
upkr -9 -b --invert-continue-value-bit --simplified-prob-update Landscape.xex Landscape.xex.upk
Compressed 30653 bytes to 12473 bytes (40.69096%)
upkr -9 -b --invert-continue-value-bit --simplified-prob-update RiverRaid.rom RiverRaid.rom.upk
Compressed 8192 bytes to 5953 bytes (72.66846%)
@Fox: Jakie wymagania ma dekompresor? 236 bajtów na kod i półtorej strony na bufor?
No to ten format jest bezkonkurencyjny. Gdyby jeszcze mieć dekompresor strumieniowy... :)
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ę.
224 bajty. Doszła opcja --invert-new-offset-bit - zmniejsza kod o jeden bajt.
Dodałem README. @xxl - przestaw linka w pierwszym poście na https://github.com/pfusik/upkr6502
Ostatnio edytowany przez Fox (2024-05-14 14:23:07)
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)
Znajdę czas to sprawdzę czy i jak działa mnożenie na Lynksie.
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)
Super, dziękuję!
z tablicami oraz z użyciem sprzętowego mnożenia i prawdę mówiąc "na oko" te dwa ostatnie są bardzo zbliżone.
To jest spodziewane. Natomast bez tablic kod jest mniejszy i nie wymaga tych 2 KB na tablice.
wersja z mnożeniem wymaga hakowania źródeł, bo faktycznie MADS nie potrafi tego skompilować.
Ostatnio edytowany przez Fox (2024-07-07 14:54:48)
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)
Zrobiłem release z poprawką literówki i relatywną ściężką trace-loga do pliku ze skryptem.
https://github.com/laoo/Felix/releases/tag/v0.6.3
Ostatnio edytowany przez laoo/ng (2024-07-07 16:14:16)
Poprawiony kod, bo był zabugowany i nie działał na prawdziwym Lynksie (A właściwie z oryginalnym ROMem)
Pozwole sie podpiac z pytaniem.
Istnieje jekis PACKER ktory w miare szybko jest w stanie pakowac dane na 6502?
Czy raczej zewnetrzne narzedzia pozostaja.
Ostatnio edytowany przez willy (2024-07-08 19:35:42)
Strony Poprzednia 1 2 3 4 5 6 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.096 sekund, wykonano 11 zapytań ]