dekompresor jest dosc szybki, malo zajmuje (zalezy - ok. 140 bajtow), dane zrodlowe nie znajduja sie w pamieci tylko w pliku, dekompresor nie potrzebuje tez bufora, i wlasciwie nie zajmuje tez strony zero :-)
Jako że w temacie kompresji (i dekompresji tudzież) utknąłem w pewnym momencie, a nie było jeszcze tej metody na A8, to zapytuję. Jaki jest stopień kompresji np. plików graficznych i tekstowych i ileż cykli potrzeba na dekompresję np. plik tekstowy czysty 760 bajtów. (jakikolwiek). No i czy jest jakaś wersja depakera LZ4 do osadzenia w 1 pliku z danymi i programem. (do dowolnego dosa)
Właśnie pracuję teraz nad ładowaniem core'a FPGA Rapidusa z flashu, którego jest 256 kB, a rdzeń zajmuje 340884 bajty :) Wymyśliłem do tego celu dedykowany format kompresji, ale zapałałem teraz nadzieją, że to będzie lepsze. Niestety nie jest. Może dlatego, że moja kompresja specjalizuje się w kompresowaniu dużych połaci bajtów $00 i $FF przy stosunkowo dużej powtarzalności blisko sąsiadujących bloków (takie są rdzenie FPGA). Mam dwa różne rdzenie, które mój kompresor (którego można jeszcze podrasować o parę procent) kompresuje do 39993 oraz 40437 bajtów. LZ4 zrobił z tego 44098 oraz 44731 bajtów. Dekompresja (332 kB) trwa dokładnie 2.5 sekundy. Używa 5 zmiennych na stronie zerowej oraz 256 bajtów bufora na "notatki". Podejrzewam jednak, że ten LZ4 wyjdzie na prowadzenie, gdy zawartość rdzenia się bardziej skomplikuje i będzie w środku mniej jednolitych bloków.
stopien kompresji przykladowo: druid z 7684 do 5870 jaskinia z 7684 do 4934 loading z 7684 do 871 mostek z 7684 do 3942 portret z 7684 do 5832 spoon z 7684 do 1090
pod linkiem, ktory dalem masz LZ4 pod windowsa mozesz sprawdzic. w testach wychodzi ze ma jeden z najszybszych dekompresorow.
Poprawiam się i zwracam honor :) Zauważyłem, że kompresor ma opcję "High compression", która kompresuje do 32724 oraz 32895 bajtów.
XXL: jakbym podesłał Ci pliczek byłbyś w stanie określić jak szybko twój dekompresor by go rozpakował? Dekompresja jest uproszczona, bo trzeba zapisywać do jednego rejestru, więc odpada zabawa w przesuwanie wskaźnika wyjściowego (ale to oznacza, że nie ma się historii rozkompresowanych danych).
Tak właśnie myślałem, że potrzebuje jednak jakiegoś bufora :) Teoretycznie można byłoby dzielić rdzeń na bloki po np. 16 kB i trzymać rozpakowany wynik w pamięci, ale to już bardzo komplikowałoby sprawę i obniżało poziom kompresji.
W każdym bądź razie wysłałem Ci info na maila. Przyjrzę się temu formatowi. Może da się coś z niego wycisnąć.
... przepraszam, że wtrącę niepotrzebną dygresję w ten wątek ale uważam że w znacznej części użycie dekompresora w przypadku A8 to (nie biorąc pod uwagę SIO) to strata czasu. Załadowanie takiego obrazka może zająć w najgorszym przypadku 0.1s (PBI). Chyba, że komuś faktycznie zależy, by ugnieść się w 64k i by chodziło to sensownie ze stacji. W takim przypadku tematu nie było ;)
Z tym dekompresorem na twoim sprzecie nadal bedzie sie ladowal w 0.1 s, ale oprocz tego zmiesci sie na karcie, a jak ktos bedzie chcial to i na dyskietce a przy okazji zaladuje sie szybciej :)
Podziękowania za udostępnienie depakera lz4. W zamian załączam testy kilku cruncherów na moim wrednym pliku. Do odtworzenia przykładów z d64 potrzebny będzie Hoxs64 lub Vice z włączoną true drive emulation. Co do krótkości depakera nadmienię że to trochę ściemnianie, bo np. Do bongo najkrótsza wersja zajęła mi zdaje się $d4 bajtów i dalej można by go skracać gdyby założyć że dane są RAW. Niemniej jednak gdzieś trzeba podać depack addres, ustawić pointery. Czy robi to depaker, czy user i tak zejdzie na to kilka bajtów, ja wolę wygodę i jak mam plik spakowany, to już się nie interesuję gdzie go zdepakować, to zmartwienie depakera.
