Nie wiem czy format był gdzieś opisany, ale dla mnie wynikał z kodu depackera. PP20 to klasyczne LZ77, jedynie kodowanie powtarzających się sekwencji (offset, len) jest kodowane za pomocą specyficznego dla PP20 kodu prefiksowego, nieco podobnego do kodowania  Shannona-Fano.

Spakowane pliki (za pomocą Power Packer 2.2a) do pobrania tutaj. Wybór stopnia kompresji (fast, mediocore, good, very good, best) to tak naprawdę wybór offsetu dla LZ77, czyli tego jak daleko "wstecz" będziemy szukać powtarzających się sekwencji danych... nie zawsze zwiększenie offsetu powoduje lepszą kompresję, bo co prawda przeszukujemy dużo większy obszar, ale również trzeba przeznaczyć więcej bitów na zakodowanie tegoż offsetu, nawet gdy użyjemy kodu prefiksowego może to przynieść gorszą kompresję niż w przypadku offsetu do zakodowania którego wymagana jest mniejsza ilość bitów. PP20 był pomyślany tak aby kompresować o wiele większe pliki niż te które występują w przypadku 8-bit Atari, często jest tak że lepszą kompresję uzyskamy stosując mniejszy "offset".

Ponieważ conan.gfx który dałeś jako przykładowy plik do kompresji był dość mały, postanowiłem dorzucić do przykładu również grę Dropzone, która zawiera o wiele większą różnorodność danych, oraz jest nieco dłuższa.

PowerPacker wyróżniał się w tamtych czasach sporą szybkością kompresji... autor PowerPacker-a zamiast stosować mozolne i długotrwałe poszukiwanie powtarzających się ciągów zastosował algorytm używający "hash table", dzięki której zmniejszył drastycznie ilość potrzebnych porównań i znajdowanie sekwencji nie trwało tak długo jak w przypadku innych algorytmów bazujących na LZ77.

Oczywiście w tym co piszę mogą znaleźć się pewne nieścisłości, ponieważ wszystko co opisuje wygrzebuje z dawno nieużywanych pokładów pamięci, więc proszę brać na to poprawkę.

Coś mi jeszcze świta że różnego rodzaju crunchery, packery, etc. oraz formaty danych mógły być opisane z którymś papierowym magazynie Amigowym z dawnych czasów (Kebab?) ... ale to już naprawdę są jakieś szczątki wspomnień, równie dobrze mogą być to urojenia :P Mogłem mieć również jakieś kserokopie tych artków, ale tego nie jestem pewien. Jak będę miał możliwość to spróbuję to odnaleźć.

Panowie,

Nie chciałbym tu "gasić światła", bo to jest do zrobienia z Atari 8-bit, ale nie w ten sposób. Tube Port w BBC micro to nie jest po prostu czysta/pełna szyna danych... po drodze jest logika z kilkoma FIFO, mechanizm wymiany danych jest bardzo uproszczony. Sam kod dla Tube Pi obsługujący to złącze jest naklepany w ASM i rezerwuje dla siebie jeden z rdzeni, aby wyrobić się w sensownym czasie. ROM BBC wspiera dodatkowe CPU, więc realizacja tego projektu bez dodatkowej logiki była możliwa. W przypadku JIL da się to zrobić jednak trzeba dołożyć trochę glue-logic, ale to wszystko to jest najmniejszy problem... bez softu który by wykorzystał te możliwości to rozwiązanie jest nic nie warte, a tego softu trzeba napisać sporo...

Takim rozwiązaniem powiedzmy podobnym do tego był cart Zenona z 65816 (Weronika)... czy ktoś napisał jakiś kawałek sotfu na to? Doskonale wiecie że nie powstało dla tego rozwiązania zbyt dużo oprogramowania... wokół takiego rozwiązania musi powstać cały ekosystem, dobrze udokumentowany i zachęcający ludzi do tworzenia. Z masą przykładów pokazujących że warto zaangażować swój czas i siły w dane rozwiązanie.

Należy pamiętać również o tym że będzie bardzo trudno zachować odpowiednie zależności czasowe jeżeli chce się zastąpić oryginalny CPU, takim emulowanym w rasp-pi + glue logic. Tu jest wymagane 100% cycle exact, a wiadomo ile czasu zajęło uzyskanie jako-takiej zgodności autorowi chociażby Altirra. Ale zastosowanie rasp-pi jako dodatkowy co-processor pozwoliło by na zachowanie 100% zgodności ze starym softem oraz uruchamianie nowego softu, specjalnie stworzonego dla tego konkretnego rozwiązania...

Sądzę że kolejnym przykładem mógłby tu być Rapidus... no ale tutaj jest ten sam problem co z weroniką... ile powstało softu który wykorzystywałby możliwości tej dopałki? Nawet mimo tego że jest Sparta i całe środowisko dostosowane do tego rozwiązania (DracOS, etc.) nie widzę jakoś aby powstawała masa softu wykorzystująca możliwości Rapidusa. Za to są spory i wojenki przy każdej możliwej okazji.

Nie chcę tu nikogo zniechęcać do niczego i mówić że to niemożliwe, lecz uświadomić że to wszystko wymaga pewnych nakładów pracy i współpracy większej grupy ludzi.

W moim przypadku robiłem eksperymenty z innymi MCU/CPU i efekty były obiecujące, odłożyłem na półkę bo nie mam obecnie czasu/możliwości aby zaimplementować wymaganą funkcjonalność (chociażby podrasowany BASIC który korzystałby z dobrodziejstw FPU).

Cześć!

Używałem PowerPacker-a swego czasu... napisałem nawet do niego własną wersję dekompresora, był opublikowany w Barymag (bradzo krótkie info tutaj: http://atariki.krap.pl/index.php/PP20_Depacker, tylko nie pamiętam czy w barymagu była opublikowana wersja zoptymalizowana czy też nieco wcześniejsza). Moja wersja depackera nie była jakaś super szybka, etc. Ale sam proces pakowania na Amidze pozwolił oszczędzić sporo czasu.  Inspiracją oczywiście byli Bloody Coders. Na AoL masz "file version" Technusa (zrobioną przez CP) która używała m.in. power packer-a (jak również paru kompresorów z C64).

Ponieważ nie miałem dostępu do Amigi, to chodziłem pakować dane do kolegi który posiadał Amigę 500, a pod koniec mojej aktywnej działalności scenowej  popełniłem jeszcze depacker dla Pack ICE 4.20 (który to był dostępny dla Atari ST). W tym wypadku również nie chodziło o wydajność ale o prędkość pakowania danych. Przenoszenie danych pomiędzy Amiga/Atari ST a Atari 8-bit mogłem uskuteczniać dzięki posiadaniu TOMS 720.

Nie pamiętam już co zostało spakowane PP20 czy ICE!, ale na pewno cześć produkcji (być może takich które nawet nie poszły jakoś specjalnie do ludzi) zostało tym potraktowanych. Na pewno parę "release" ze stajni "CP", wykorzystywało PP20 z Amigi, czy inne kompresory z C64. Ale minęło już tyle lat że naprawdę nie pamiętam dokładnie które.

Pora na wymianę folii w klawiaturze, zapytaj np. Duddiego czy nie ma folii do twojego modelu klawiatury. Ja musiałem wymienić folię w swojej 130XE, objawy podobne... próbowałem się bawić w wymianę rezystora, czyszczenie folii, różnej magii, tylko czas traciłem bo problem powracał i tylko rosła moja frustracja. Po wymianie na folii, jak ręką odjął. Wszystko działa idealnie.

Efekt o którym piszesz to norma, wspomina o tym Jer na swojej stronie:

src: Długie "wymóżdżanie" pamięci

File Copier 130XE bez problemu obsługuje magnetofon. Jako urządzenie wejściowe/wyjściowe po prostu podajesz "C:" (bez cudzysłowów), a jak masz Atari 130XE będziesz miał do dyspozycji około 98KB bufora na dane.

no to jeszcze jeden link do kompletu (tym razem opisujący sprzętowe rozwiązanie "problemu"): http://wiki.icomp.de/wiki/VSP-Fix

w tym linku jest link do opisu tegoż efektu, ale u mnie link nie działa więc używając wayback machine można to przeczytać:

https://web.archive.org/web/20160623184 … e_3.14.htm -> sekcja 3.14.6 - DMA DELAY

możliwości i ludzi mają :) nawet jeżeli chodzi o klonowanie krzemu. Obawiam się jednak że po te pieniądze się nie pochylą i jedyne co mogliby zrobić to jakiś emulator na jakimś chińskim ARM typu All-Winner, Rockchip czy inne tego typu konstrukcje.

Nigdy nie posiadałem takiego JOY-a z gumkami, ale wierzę że trwałe to nie jest, bo miałem kilka szajsowatych padów do Sega MegaDrive opartej o tą "technologię" i nie dotrwały do dzisiejszych czasów.

No dokładnie i klasyczne blachy jak 40 lat temu :) Twarde, sztywne i PCB pęknie przy większym nacisku. 40 lat minęło jak jeden dzień i mimo ogromnego postępu technologicznego chinol nadal produkuje to samo. Oryginały się do niczego nie nadawały... to to teraz mam chińską replikę "kultowego" szajsu atarowskiego JOY-a ;-)

Ja chyba powinienem się leczyć, bo naprawdę uwierzyłem że w produkcie za $8 są jakiekolwiek micro-switche ;-)

@dely: jak zobaczyłem Twoje logo (tą pierwszą wersję) to od razu jakoś mi się skojarzyło z tym:

i żeby nie było, nie zarzucam żadnego plagiatu czy coś, bo podobieństwo jest nieznaczne, to po prostu moje skojarzenie które nastąpiło automatycznie ;)

src: https://www.sido-event.com/