no dokładnie jest to tak zrobione, 4-bit counter zaimplementowany na latch-ach w PAL/GAL który zlicza właśnie phi2 i generuje przebieg schodkowy (nazwijmy to aproksymowaną piłą), potem DAC typu R-2R (czy tam 2^Dx), komparator i zatrzask w którym znajduje się stan licznika z chwili "zadziałania" komparatora. Nie ma tam żadnego sample&hold, przy tak niskiej częstotliwości próbkowania, jakoś to nawet działa (phi2/16).

W czasach "Code3" zrobiłem sobie coś podobnego również opartego na tej zasadzie działania tyle że u mnie wersja przewlekana, zamiast PAL/GAL był 7493 oraz parę bramek, komparator taki sam tyle że ja miałem wejście na uA741 wraz z low-passem, również nie robiłem S&H, działało. Dopiero gdy udało mi się dorwać ADC0809 zrobiłem sobie wersję na nim opartą, więc miałem 8-bit i stereo ;-)

Zresztą jak się wygrzebię ze spraw bieżących to wrzucę to wszystko na GitHUB-a (w sensie projektów).

Mam jeszcze egzemplarz AD Convertera przekazany mi przez FOX-a (to jego fotki widzicie powyżej)... zrobię temu wszystkiemu ładniejsze zdjęcia, zeskanuje instrukcję i wrzucę na Atariki, ale to jeszcze chwilę potrzebuję.

Co do etykiety to jak wygrzebię sampler to oczywiście zrobię zdjęcie, albo zeskanuję etykietę, nie ma problemu. Jeżeli chodzi o GAL-a to ja mam wersję z 16AS25 i o ile dobrze pamiętam to ten układ nie był był rozpoznawany ani poprawnie odczytywany przez żaden z programatorów którym dysponowałem. Próbowałem kiedyś nawet szukać jakiejś noty katalogowej do tego układu, ale moje poszukiwania spełzły na niczym. Jednym słowem układ Schrödinger-a, niby jest ale go nie ma :) ... wygląda na to że ST się do niego nie przyznaje :)

Posiadam taki cart. Wygląda dokładnie tak jak ten zaprezentowany na Atariki. Moim zdaniem problemem był "błąd równaniach/logice" umieszczonej w GAL16V8 (czy też odpowiedniku od ST czyli 16AS25), tzn. prawdopodobnie zatrzaskiwanie danych w buforze 373 było błędnie realizowane, np. nie po poprawnym zakończeniu konwersji, a np. po każdym zboczu Fi2, ale to mogą być tylko moje błędne przypuszczenia.

Transakcja zakończona pomyślnie. Sądzę że temat można zamknąć.

To jeszcze dwa słowa o pierwiastkowaniu, oczywiście to co wkleiłem ma jedynie znacznie powiedzmy historyczno-sentymentalne, bo "dzisiejsze" rozwiązania są nieco inne, ale aby być fair należy tutaj załączyć dwa linki:

Szybka odwrotność pierwiastka kwadratowego

oraz:

Metody obliczania pierwiastka kwadratowego <--- oczywiście wersja binarna (sekcja #Dwójkowo)

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źć.