To niestety znowu ja... z nową porcją historycznego bałaganu...

Był kiedyś (w latach '90) wydawany taki dwutygodnik, który zwal się PC Kurier. Znajdowały się tam różne artykuły, czasami panował tam okropny chaos, czasami ogromny mętlik, jednak pośród tego wszystkiego dało się znaleźć ciekawe artykuły i ciekawe perełki... często napisanie w sposób "patrzcie jakie to proste!"... gdy tylko magazyn ten wpadł mi w ręce zawsze przeglądałem go w poszukiwaniu ciekawostek i inspiracji.

Był w nim dział "Dla Praktyków", zawsze znalazło się tam coś ciekawego... teraz po latach okazało się że część kserokopii przetrwała... zatem wrzucę to co znalazłem hurtem, pierwszy art będzie związany z "demo effects", bo przecież w latach '90 każdy chciał zrobić swoją wersją "Cubic spline" czy "Bézier curve" i zaprezentować ją światu, a przypadku Slight tą osobą był RZóG, który to zaprezentował ów efekt w demie Overmind ;-)

https://www.youtube.com/watch?v=gcyaTFX45Bo

^^^ efekt o którym mowa jest dokładnie od 4:28

Nie pamiętam niestety czym posiłkował się RZóG, ale przeglądając swoje materiały napotkałem na art. z PC Kuriera, pt. "Krzywe Sklejane". TeBe się pewnie ucieszy bo to z działu "Dla Praktyków: Turbo Pascal", a więc język bardo mu bliski ;), zatem ciekawych jak to wyglądało w latach '90 zapraszam do rzucenia okiem: Dla Praktyków: Turbo Pascal - Krzywe Sklejane

A niejako hurtem że skanowałem już wszystko co było w tym segregatorze to wrzucam od razu skany artykułów dotyczących: Formty graficzne GIF, FLI oraz PCX (uzupełnienie)

ps) Jeżeli znajdę coś w podobnej tematyce nie omieszkam tu umieścić. No chyba że uważacie że to nie miejsce na tego typu linki, wtedy przeniosę to wszystko do wydzielonego wątku. Jeżeli tak, proszę o uwagi i informację zwrotną.

Hej!

W ramach ogarniania chaosu, porządków, reorganizacji przestrzeni, etc. znajduję różne papiery z dawnych lat... nie wiem czy to wszystko jest warte zachowania/udostępniania... jednak przed wrzuceniem tego w niszczarkę postanowiłem zeskanować niektóre z tych materiałów, zdaje sobie sprawę że to już raczej ciekawostka historyczna, jednak nierozerwalnie wiąże się ze sceną i niejako również z "demo effects". Być może ktogoś to zainteresuje, zatem przestawiam skany paru artków z magazynu Amiga z roku '95 poruszającego tematy:

• Textured Vectors

• Cieniowanie (Gouraud)

• Detekcja i wyznaczenie krawędzi

• Porządek czy chaos (o zbiorze Mandelbrota)

• Lepsze Stereogramy

Magazyn Amiga - Software, Programowanie, Grafika - artykuły wybrane.

Jeżeli znajdę coś więcej to oczywiście będę dorzucał. Jak wspominałem wyżej, to właściwie już wiedza historyczna, ale może zainspiruje kogoś do dalszego kopania w sieci i poszukiwania wszystkich części tejże serii, lub zajęcia się jakimś tematem z przedstawionych na tych kartkach.

Wybaczcie jakość, ale to co skanowałem to były  kserokopie, które dostawałem od znajomego mającego wtedy Amigę, a ponieważ wiedział on że interesują mnie takie rzeczy, kserował mi niektóre artykuły.

EDIT: Dorzucam parę skanów starych kserówek z mag. Amiga, tym razem dotyczących przetwarzania dźwięku:

• DSP dla każdego: Filtracja Cyfrowa

• DSP dla każdego: Łyk matematyki

• DSP dla każdego: FFT, Basic i Asembler

• Ulepszanie dźwięku: Wycisnąć gąbkę

• Ulepszanie dźwięku: 14 bitów to jest to!

Magazyn Amiga - Przetwarzanie dźwięku

Szybka akcja! Dzięki za realizację! Za badania i testy i za wnikanie w temat kompresji i za odnalezienie takich ciekawostek! :)

LZ77 "sobie", a to jak są kodowane sekwencje to już wymysł autora danego kompresora/formatu spakowanych danych ;-) Każdy może sobie w sumie nazywać to jak chce ;) równie dobrze można to nazwać LZMA czy jakkolwiek inaczej :) Tak z perspektywy czasu patrząc na to wszystko (w sensie wersji i odmian LZ77) i nad zastosowaniem Huffmana do kodowania len,offset zawsze mi wychodziło że miejsce potrzebne na przechowanie drzewa w przypadku Atari jest "zbyt dużym kosztem", i przy jakichś swoich eksperymentach wybierałem prostsze rozwiązania typu proste "kody prefiksowe", bo sądziłem że jest to lepszą drogą (do czego w owym czasie przekonał mnie PuCrunch czy exomizer).

No ale przyszedł Fox i postanowił zaimplementować "deflate" który to aktywnie korzysta z kodowania Huffmana :) (wcześniej Huffman-a zaimplementowanego na JIL widziałem tylko u Jiriego Bernasek-a w Super Packerze).

btw. jak patrzę na to jak Huffmana zaimplementowano w dekompresorze dla Shrinkler-a... muszę powiedzieć że patrząc na kod dla M68K jestem pod wrażeniem "kompaktowości" tegoż kodu :)

EDIT: ^^^ Przyjrzałem się trochę więcej/bardziej źródłom, to nie Huffman... ale wychodzi na to że użyty został Range Coding, czyli taka integer-based wersja kodowania arytmetycznego. Nie sądziłem że da się to dekompresować w sensownym czasie na 8-bit MCU (szczególnie że potrzebne jest mnożenie). Człowiek uczy się przez całe życie! :)

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.