Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
RECOIL 6.4.5 RECOIL to przeglądarka retro plików graficznych, obsługująca ponad 550 formatów, dostępna na różnych systemach operacyjnych, z regularnymi aktualizacjami.
ABBUC Software 2024 - wyniki Ukazały się wyniki tegorocznego ABBUC Software Competition
Przeszłość spotyka przyszłość Czwarta edycja festiwalu gier konsolowych i komputerowych z lat 80. i 90.
Czwarta edycja ATASCII Compo! Dziś, 1 października 2024, oficjalnie rozpoczął się okres nadsyłania prac!
Silly Venture 2024 SE - stuff Dostępny jest już stuff z zeszłomiesięcznego party Silly Venture 2024
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.zflOstatnio edytowany przez mono (2022-10-11 09:00:25)
Poproszę dopisać:
Upkr: 1403 (upkr -9) https://github.com/exoticorn/upkrRiverRaid.rom: 5945
Landscape.xex: 12480
Ostatnio edytowany przez Fox (2024-05-09 13:29:49)
szok i niedowierzanie... dostepne zrodla na z80....
pewnie w weekend pojawi sie dla Atari :-)
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.upkdział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?
dodane :-)
bufor ma 320 bajtów - nieduzo...
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.099 sekund, wykonano 12 zapytań ]