Operacja Bałwan by Kaz 2009-11-18 01:17:02
Tomasz "TeBe" Biela podzielił się nie tylko nową wersją
programu graficznego "Graph2Font", ale także demkiem - animacją pod
tytułem The Snowman. Zanim zaprezentuję to demko chciałbym
jednak zacząć ab ovo, od osoby, która miała pomysł i od czasu, w
którym narodziła się idea przeniesienia tego słynnego z Atari ST
dema na Atari XL/XE.
Otóż w połowie października tego roku Tomasz "Irwin" Bogdanowicz, który od dłuższego czasu zajmuje się tematem animacji na Atari, a nawet z tego powodu "zamęcza" tematami Atari różnych twórców komodorowskich programów, wpadł na pomysł realizacji dema The Snowman na małym Atari. Oddaję Irwinowi głos, który tak wtedy pisał do mnie w mailu na temat nowego pomysłu:
"Kiedyś dawno temu na początku lat 90-tych, gdy miałem komputer zwany Amiga 500, w łapy wpadło mi demo zwane "The Snowman". Całkowicie sie różniło od wszystkich innych przede wszystkim tym, że było po prostu zdigitalizowanym filmem animowanym, z samplowaną muzyką. Niezbyt tego typu demka lubiłem (z innych znanych to Control/Coma (fajna muza) i 242/Fairlight), ale to miało w sobie coś - znakomitą historię, opowieść przedstawioną - jak już dziś wiem - w 74 różnych obrazkach. A przede wszystkim muzykę - była fantastyczna, nastrojowa, wręcz stworzona do tej animacji. Ileż godzin spędziłem przeczesując specjalistycznymi programami w celu znalezienia upragnionego skrótu M.K (oznaczenie muzyki w MOD). Niestety poległem i nic nie znalazłem.
Ostatnio, jakieś 3 miesiące temu, po blisko 20 latach usłyszałem fragment tej muzyki w TV i przypomniałem sobie owe demko. Wpadła mi myśl - a co, gdyby zrobić wersję na Atari? Postanowiłem poszperać po necie, aby znaleźć owe amigowe demko. Niestety nie znalazłem... Na największym tego typu schronisku dem wszelakich ;) czyli na Pouet.net nie ma tego demka, ale... jest wersja na Atari ST! Wygląda identycznie i brzmi identycznie jak wersja na Amigę. I nic dziwnego, gdyż to właśnie wersja na Atari ST jest tą pierwszą, oryginalną.
Jest też wersja na PC która jest niemal wierną kopią tych powyższych, korzysta nawet z tego samego pliku, w którym są nagrane klatki animacji, a jedyna różnica to dźwięk w formacie WAV, gdyż autor nie wiedział jak się zabrać do dziwnego dla niego formatu SPL - który nie jest tak straszny jak się okazuje, to zwykły RAW 8-bit 8khz mono (poniekąd wyjaśniło się dlaczego na Amidze nie mogłem znaleźć modułu). Wersja na PC używa OpenGL, więc klatki mimo, że w 16 kolorach mają ich poprzez bilinerany antialiasing znacznie więcej. Skontaktowałem się z autorem wersji dla PC i okazało się, że kiedyś miał Atari 65XE i życzył mi sukcesu w konwersji demka. Podał mi parę uwag - zaproponował użycie trybu GTIA 80x200 w 16 odcieniach, ale niestety ja miałem inną wizję ;). Podesłał mi harmonogram czasu trwania poszczególnych klatek, ale z uwagi na całkowity galimatias w pliku wideo z Atari ST - niezbyt przydatny (klatki w pliku snowman.neo z AtariST są nagrane w przypadkowy sposób, nie po kolei, więc na przykład oznaczenie 2,2,2,41,41,65,65 nic mi nie mówiło). Po tych wstępnych badaniach przystąpiłem do akcji zwanej Operacja Snowman ;).
Wersje Atari ST, amigowa i PC używają tego samego trybu, tego samego pliku z obrazkami to jest 320x200 w 16 kolorach, z tym że same obrazki są w 160x100 w 16 kolorach i sama animacja jest wyświetlana w dwóch różnych miejscach na ekranie. Klatki animacji są zapisane w atarowskim formacie NEO, bez nagłówka i w jednym pliku snowman.neo mającym 600000 bajtów (75 obrazków x 4 bity (pół bajta) x 160 x100 = 600000). Jeden obrazek nie jest wykorzystany w animacji, stąd wspomniane wcześniej 74. Wersje na Atari ST i Amigę wymagają 1MB RAM, na PC z uwagi na Windows troszkę więcej.
Na Atari 8-bit oczywiście można pokazać to tak jak w oryginale, jednak trzeba obniżyć rozdzielczość, gdyż tryb 320x200 hires w Atari jak dla mnie to do niczego sensownego się nie nadaje. Tak więc pozostały rozdzielczości:
Pierwszy odpadł TIP Animator, gdyż nie lubię interlace'u i nigdy nic w tym nie stworzę. Następnie odpadł GTIA - mając do dyspozycji 80x200, rozdzielczość obrazka miałaby 40x100 (bo są dwa ułożone jak szachownica). Jakbym nie próbował, napisu "Snowman" nie da rady zrobić w 40 pikselach. Na to zwrócił uwagę również autor wersji dla PC.
Pozostał więc tryb 160x240 czyli 80x120 dla obrazka - jednak w 4 kolorach. Początkowo zrobiłem więc wersję właśnie w 80x120, a właściwie 80x100, gdyż korzystałem z oryginalnych obrazków z wersji Atari ST, przeniesionych do piksli 2x1 i 4 kolorów. Nie wyglądało to zbyt dobrze bo było dwa razy mniej piksli, a przecież przy 4 kolorach musiałem użyć ditheringu, co z kolei dodatkowo obniża rozdzielczość, oczywiście nie realnie, ale subiektywnie. Ponadto częśc znaków była używana na te napisy obok animacji - a szłona to dość dużo w każdym foncie. Ostatecznie wyglądało to niespecjalnie, a nadto zajmowało dość dużo miejsca w pamięci.
Postanowiłem więc zrobić inaczej - jedno miejsce, gdzie będzie wyświetlane wideo, a poniżej napisy - font z napisami będzie jeden i nie będzie się "wtryniał" w ten z wideo. Oczywiście teraz mogłem zwiększyć rozdzielczość do 256x160 (128x160). Klatki z oryginału przeskalowałem do tej rozdzielczości. Obraz trochę poprawił się w ostrości, jednak z uwagi na przeskalowanie nadal nie było to tak jak chciałem. Ponadto zdałem sobie sprawę z faktu, że nie ma żadnych szans, aby to demko ruszyło na 64 KB. Dlaczego? Gdyż sama tylko samplowana muzyka zajmuje w oryginale 165 KB (a po przeróbce do 4bit 6khz będzie zajmować 62KB (1 bank pamięci) lub 8bit 6khz 124KB (2 banki pamięci). Tak więc to, że demko będzie wymagać na przykład 210 KB czy 320 KB nie ma znaczenia, gdyż i tak nie ruszy na normalnych maszynach bez rozszerzonej pamięci. Poniekąd zrozumiałem autorów "Bomb Jacka" i teraz trochę inaczej patrzę na kwestię rozszerzeń sprzętu (choć nadal jestem antyVBXE).
Oczywiście w tej sytuacji obrazki z Atari ST w 160x100 stały się już zbędne, bo nie ma żadnego sensu skalować do 320x240 (a właściwie 160x240 z uwagi na piksele 2x1). Postanowiłem poszukać oryginału, prawdziwego oryginału. Znalazłem go na Youtube - trwa 30 minut i ma rozdzielczość 320x240. W rzeczywistości jest on tam wrzucony trzy razy, podzielony na trzy części ze względu na limit 10 minut na Youtube. Dwie wersje, mimo iż w 320x240, to wyglądają tak jak najgorsze nagranie z kasety VHS przegrane/obejrzane tysiąc razy w czasach giełdy wymiennej z Wrocka z końca lat 80tych, gdzie często się bywało :). Link do jedynej zdatnej do oglądania wersji dałem powyżej. Ale i ta wersja ma wadę: na górze są ze dwie, czasami trzy czarne linie - to powodowałoby, że w każdym zestawie znaków trzebaby z miejsca poświęcić 30-40 znaków na tą linię. Uznałem więc, że obetnę trochę z góry i dla równowagi z dołu, a docelowa rozdzielczość będzie wynosić 320x224. Następnie zgrałem całą animację z Youtube za pomocą "Virtualdub" do tysięcy klatek BMP. Po otwarciu pierwszej klatki z animacji Atari ST zacząłem jej szukać w tym ogromnym zbiorze plików BMP. Tak znalazłem wszystkie 74 klatki. Dzięki rozdzielczości 320x224 i filtrom sharpen oraz contrast udało się uzyskać dość wyraźny obraz. W międzyczasie udało mi się wymóc na TeBe dodanie opcji we wspaniałym "Graph2Font" dotyczącej powtórzeń danej klatki, co znacznie zmniejsza objętość pliku wideo.
Klatka w 320x224 (160x224) w 4 kolorach zajmuje w "G2F" 10 fontów + dane o ułożeniu fontów = 11 KB. Możemy ją zoptymalizować korzystając z opcji Optymizing i tak średnio dane fontów każdej klatki spadają do wartości 8-9 fontów + dane o ich ułożeniu = razem 9KB. To nadal za dużo. Możemy ją skompresować korzystając z programu Algorithma "CSAM" - jednak efekt jest taki jak widać poniżej na porównaniu. Nie wygląda najlepiej, ale zajmuje jedynie 3-5 fonty na klatkę + dane o ich ułożeniu = 4-6KB.
Możemy ją też skompresować ręcznie, to jest samemu analizując, które miejsca w klatce są ważne dla ludzkiego oka (twarze, ciało, elementy istotne jak dom, płatki śniegu które dadzą wrażenie ruchu), a które mniej - jak tło, pokrycie dachu, płotu. Tego automatyczny w swym działaniu program nie zrobi, gdyż on działa na podstawie różnic, metodą brute force, nie patrząc że ludzkie oko wyczulone jest na pewne szczególy, a inne pomija, lub nie przywiazuje do nich wagi. Oczywiście wtedy cała czarna robota spadłaby na mnie, ale myślę że warto to zrobić, gdyż 95% klatek uzyskanych tą drogą używa jedynie 2 zestawu fontów (a niektóre nawet 1, choć jest i parę, które mają 3 zestawy), a jakość nie odbiega od oryginału - patrz ostatni obrazek w porównaniu powyżej.
Na początku szło jak po grudzie i nad pierwszymi obrazkami siedziałem po 2-3 godziny, nierzadko zaczynając od nowa, potem gdy nabrałem wprawy to czasem w 15 minut i wgrywałem następny. Badając oryginał z Atari ST zacząłem sam układać listę/harmonogram czasu trwania poszczególnych klatek. Praktycznie jest on identyczny z oryginałem, jednak z uwagi na muzykę postanowiłem trochę dodać tu i ówdzie w czasie trwania niektórych klatek, tak aby cała długość animacji wyniosła 1 minutę i 24,6 sekundy czyli dokładny czas 4-krotnego powtórzenia sampla, tak aby animacja po rozpoczęciu od nowa ładnie się zapętliła - w oryginale muzyka dość nieszczególnie się urywa.
Ogólnie wszystkie obrazki używają 154 zestawy fontów i to liczonych już po przeróbce w "G2F". Niestety, mimo iż używałem w każdym foncie jedynie 127 znaków to i tak G2F czasami sam z siebie doda jakiś zestaw - na przykład mam 15 obrazków, które wiem, że używają 30 fontów, każdy po 127 znaków, a po eksporcie G2F informuje, że użyto 32 fontów... Dane obrazka (gdzie dany znak ma wystąpić), zajmują 75 obrazków x około 1KB = 80KB (u mnie jest jeden dodatkowy obrazek, na samym końcu, z info o autorach tej wersji. Ogólnie z uwagi na ograniczenia G2F (limit fontów w zestawie: 127, limit rozmiaru pamięci: 64KB) podzieliłem animację na pięć części i łącznie zajmują one 240 KB + dane audio, które zajmują 62KB. Razem około 300KB czyli 4 banki wideo + 1 bank audio. Limit 320KB nie jest przekroczony! :)"
W dalszej części tej historii do akcji wkracza właśnie TeBe, o czym Irwin pisał następująco:
"Tebe zainteresował się tematem i co chwila coś robi w tej sprawie, podrzuca mi nowe wersje, które są coraz lepsze. Przede wszystkim dźwięk już gra dobrze na przerwaniach IRQ w 4khz. Nie brzmi tak jak na Atari ST, ale jak na warunki małego Atari to wręcz fenomenalnie. TeBe skorzystał tu z procedury grającej sample z gry "Space Harrier" (nadal w produkcji). Odnośnie grafiki - nie da rady zrobić tak, aby jednocześnie mieć ANTIC i sample. Jak to TeBe napisał: "POKEY napastowany jest przez ANTIC stąd te zniekształcenia, rozdzielenie POKEY-a od ANTIC-a zagwarantuje czysty dźwięk, ale to oznacza zmianę sprzętu typu: 1. VBXE + POKEY lub 2. ANTIC + COVOX".
Tak więc TeBe przerobił orginalne obrazki z wersji Atari ST na 4 kolory. Teraz animacja ma 160x100 w 4 kolorach z jakimś ditheringiem typu Floyd (nie moim ulubionym ordered). Jest w trybie GRAPHICS 13 w trybie bitmapy (ANTIC nie jest napastowany ;) na całym ekranie i powiem szczerze -wygląda to lepiej niż moja wersja mimo przeszło 2-krotnie mniejszej rozdzielczości (160x100 zamiast 160x224). Widać TeBe dodając różne opcje ditheringu do "AIS" wprawił się i nawet ładnie to wygląda. Mimo, iż to mniejsza rozdzielczość niż u mnie to całość zajmuje więcej - 300KB przeciwko moim 240KB (to jest jedna z tych zalet ręcznej kompresji). Niby niewielka różnica, ale dodając kod i sample mamy teraz plik ważący około 370 KB (305 KB było u mnie). To oznacza, że rozszerzenie pamięci 320KB to zbyt mało. Jednakże TeBe do swojej wersji dodał kompresje Huffmana i dane wideo spadły z 300 KB do około 200 KB. Teraz plik ma około 260KB, a jest rozpakowywany sukcesywnie w czasie rzeczywistym, więc na rozszerzeniach do 320 KB już działa. A ponieważ jest w bitmapie, a nie na znakach, działa na każdym rozszerzeniu 320KB, to jest także na najbardziej rozpowszechnionym Rambo.
Oczywiście jeszcze nie ma dokładnego planu odtwarzania, klatki są odtwarzane ze stała częstotliwością, bez zapętleń, w kolejności w jakiej są zapisane w pliku DAT wersji AtariST (a to nie jest porządek wyświetlanej animacji). Ponadto animacja jest bez buforowania i klatki się rysują na ekranie zamiast być wyświetlane. Wysłalem więc ów plan kolejności odtwarzania danej klatki, czasu jej trwania jak i zapetlenia zarówno ten ustalony przeze mnie, aby pasował do sampli, jak i ten który otrzymałem od autora wersji na PC - teraz TeBe wprowadzi je do animacji.
I to tyle narazie, prace trwją, TeBe stał się nie tylko autorem kodu, ale i samej konwersji animacji, tak więc moj udział z demka został całkowicie wyłączony. Mnie to absolutnie nie przeszkadza, sam zresztą to TeBe-mu zaproponowałem. Jeśli ma to być zrobione lepiej to jestem całkowicie za wersją TeBe. Ja będe zadowolony z tego, że udało mi się zainteresować TeBe-go zarówno tym demkiem (jakże innym od typowych produkcji scenowych, z wyjątkowo wspaniałą opowieścią i równie piękną muzyką), jak i samplami (kto wie, czy dzieki temu gra "Pang" nie dorobi się sampli ;). Tak więc jest nadzieja, że oprócz wersji na Atari ST Amigę i PC The Snowman pojawi się na jeden stareńki 8-bitowy komputer - i nie będzie to C64, a nasze Atari :)."
Dzisiaj wiemy, że marzenie Irwina się spełniło, bo TeBe zaprezentował demko "The Snowman" pisząc o nim tak:
.png)
.png)
.png)
.png)
"Klatki są w trybie znakowym (160x96 piksli), piksel proporcjonalny 2x2 hires (GRAPHICS 13 BASIC-a), 5 kolorów, odcienie szarości, każda klatka to 4 zestawy znaków (próba dla kompresji każdej klatki oddzielnym zestawem znaków - z kompresją powtarzających się znaków wykazała 276 różnych zestawów, jednak trudniej było tym zarządzać, buforować, itp., dlatego zrezygnowałem z takiej wersji).
Pomysł procedury przerwania IRQ odgrywającej sampel przy aktywnych przerwaniach DLI, NMI - autora konwersji gry "Space Harrier" Sheddy-ego (źródło AtariAge). Są dwie wersje:
Sampel zajmuje 4 banki pamięci, 4-bitowy (oryginalnie 8-bitowy), czyli w 1 bajcie zapisane są dwie próbki, inaczej musiałby zajmować 8 banków pamięci.
Było bodaj z 8 różnych wersji, podejść do tej animacji, m.in. w trybie bitmapy (4 kolory) i w trybach znakowych, różne wersje kompresji, buforowania, itp. Wersje finalne są kompromisem między szybkością dekompresji, zajętością pamięci a jakością obrazu. Dither niewątpliwie wyglądał lepiej, kiedy zwiększyłem rozdzielczość pionową dwukrotnie, jednak wtedy nie dało się tego zmieścić w 16 bankach, a kompresja stratna znaków (z którą też eksperymentowałem) nie dawała zadawalających rezultatów dla każdej klatki. Wersja DF7 to dłuższy czas działania dekompresora, SQZ wersja szybsza, jednak w ostatecznym rozrachunku dzięki buforowaniu klatek szybkość nie ma takiego znaczenia.
Pliki XEX nie dadzą się już zbytnio spakować, SQZ co najwyżej do rozmiaru pliku DF7. Tak czy siak dyskietka 180KB (DD) tutaj nie wystarczy."
Jak widać, czasem pozornie proste rzeczy (tutaj: przeniesienie "jakiejś tam" animacyjki) wymagają nie tylko masy czasu na eksperymenty, ale i ogromnej wiedzy, a także wielu kompromisów... Miejcie to na względzie przy ocenianiu i krytykowaniu ludzi, którzy robią coś na retrokomputerach. A oto pliki demka. Za zainteresowanych mam też podesłany przez Irwina pakiecik - demko w wersji Atari ST, Amiga i PC oraz jego niedoszła wersja dla małego Atari.
Otóż w połowie października tego roku Tomasz "Irwin" Bogdanowicz, który od dłuższego czasu zajmuje się tematem animacji na Atari, a nawet z tego powodu "zamęcza" tematami Atari różnych twórców komodorowskich programów, wpadł na pomysł realizacji dema The Snowman na małym Atari. Oddaję Irwinowi głos, który tak wtedy pisał do mnie w mailu na temat nowego pomysłu:
"Kiedyś dawno temu na początku lat 90-tych, gdy miałem komputer zwany Amiga 500, w łapy wpadło mi demo zwane "The Snowman". Całkowicie sie różniło od wszystkich innych przede wszystkim tym, że było po prostu zdigitalizowanym filmem animowanym, z samplowaną muzyką. Niezbyt tego typu demka lubiłem (z innych znanych to Control/Coma (fajna muza) i 242/Fairlight), ale to miało w sobie coś - znakomitą historię, opowieść przedstawioną - jak już dziś wiem - w 74 różnych obrazkach. A przede wszystkim muzykę - była fantastyczna, nastrojowa, wręcz stworzona do tej animacji. Ileż godzin spędziłem przeczesując specjalistycznymi programami w celu znalezienia upragnionego skrótu M.K (oznaczenie muzyki w MOD). Niestety poległem i nic nie znalazłem.
Ostatnio, jakieś 3 miesiące temu, po blisko 20 latach usłyszałem fragment tej muzyki w TV i przypomniałem sobie owe demko. Wpadła mi myśl - a co, gdyby zrobić wersję na Atari? Postanowiłem poszperać po necie, aby znaleźć owe amigowe demko. Niestety nie znalazłem... Na największym tego typu schronisku dem wszelakich ;) czyli na Pouet.net nie ma tego demka, ale... jest wersja na Atari ST! Wygląda identycznie i brzmi identycznie jak wersja na Amigę. I nic dziwnego, gdyż to właśnie wersja na Atari ST jest tą pierwszą, oryginalną.
"The Snowman" z Atari ST
Jest też wersja na PC która jest niemal wierną kopią tych powyższych, korzysta nawet z tego samego pliku, w którym są nagrane klatki animacji, a jedyna różnica to dźwięk w formacie WAV, gdyż autor nie wiedział jak się zabrać do dziwnego dla niego formatu SPL - który nie jest tak straszny jak się okazuje, to zwykły RAW 8-bit 8khz mono (poniekąd wyjaśniło się dlaczego na Amidze nie mogłem znaleźć modułu). Wersja na PC używa OpenGL, więc klatki mimo, że w 16 kolorach mają ich poprzez bilinerany antialiasing znacznie więcej. Skontaktowałem się z autorem wersji dla PC i okazało się, że kiedyś miał Atari 65XE i życzył mi sukcesu w konwersji demka. Podał mi parę uwag - zaproponował użycie trybu GTIA 80x200 w 16 odcieniach, ale niestety ja miałem inną wizję ;). Podesłał mi harmonogram czasu trwania poszczególnych klatek, ale z uwagi na całkowity galimatias w pliku wideo z Atari ST - niezbyt przydatny (klatki w pliku snowman.neo z AtariST są nagrane w przypadkowy sposób, nie po kolei, więc na przykład oznaczenie 2,2,2,41,41,65,65 nic mi nie mówiło). Po tych wstępnych badaniach przystąpiłem do akcji zwanej Operacja Snowman ;).
Wersje Atari ST, amigowa i PC używają tego samego trybu, tego samego pliku z obrazkami to jest 320x200 w 16 kolorach, z tym że same obrazki są w 160x100 w 16 kolorach i sama animacja jest wyświetlana w dwóch różnych miejscach na ekranie. Klatki animacji są zapisane w atarowskim formacie NEO, bez nagłówka i w jednym pliku snowman.neo mającym 600000 bajtów (75 obrazków x 4 bity (pół bajta) x 160 x100 = 600000). Jeden obrazek nie jest wykorzystany w animacji, stąd wspomniane wcześniej 74. Wersje na Atari ST i Amigę wymagają 1MB RAM, na PC z uwagi na Windows troszkę więcej.
Na Atari 8-bit oczywiście można pokazać to tak jak w oryginale, jednak trzeba obniżyć rozdzielczość, gdyż tryb 320x200 hires w Atari jak dla mnie to do niczego sensownego się nie nadaje. Tak więc pozostały rozdzielczości:
- 160x240 w 4 kolorach
- 80x200 w 16 kolorach
- 160x119 w 128 kolorach (TIP Animator)
Pierwszy odpadł TIP Animator, gdyż nie lubię interlace'u i nigdy nic w tym nie stworzę. Następnie odpadł GTIA - mając do dyspozycji 80x200, rozdzielczość obrazka miałaby 40x100 (bo są dwa ułożone jak szachownica). Jakbym nie próbował, napisu "Snowman" nie da rady zrobić w 40 pikselach. Na to zwrócił uwagę również autor wersji dla PC.
Pozostał więc tryb 160x240 czyli 80x120 dla obrazka - jednak w 4 kolorach. Początkowo zrobiłem więc wersję właśnie w 80x120, a właściwie 80x100, gdyż korzystałem z oryginalnych obrazków z wersji Atari ST, przeniesionych do piksli 2x1 i 4 kolorów. Nie wyglądało to zbyt dobrze bo było dwa razy mniej piksli, a przecież przy 4 kolorach musiałem użyć ditheringu, co z kolei dodatkowo obniża rozdzielczość, oczywiście nie realnie, ale subiektywnie. Ponadto częśc znaków była używana na te napisy obok animacji - a szłona to dość dużo w każdym foncie. Ostatecznie wyglądało to niespecjalnie, a nadto zajmowało dość dużo miejsca w pamięci.
Postanowiłem więc zrobić inaczej - jedno miejsce, gdzie będzie wyświetlane wideo, a poniżej napisy - font z napisami będzie jeden i nie będzie się "wtryniał" w ten z wideo. Oczywiście teraz mogłem zwiększyć rozdzielczość do 256x160 (128x160). Klatki z oryginału przeskalowałem do tej rozdzielczości. Obraz trochę poprawił się w ostrości, jednak z uwagi na przeskalowanie nadal nie było to tak jak chciałem. Ponadto zdałem sobie sprawę z faktu, że nie ma żadnych szans, aby to demko ruszyło na 64 KB. Dlaczego? Gdyż sama tylko samplowana muzyka zajmuje w oryginale 165 KB (a po przeróbce do 4bit 6khz będzie zajmować 62KB (1 bank pamięci) lub 8bit 6khz 124KB (2 banki pamięci). Tak więc to, że demko będzie wymagać na przykład 210 KB czy 320 KB nie ma znaczenia, gdyż i tak nie ruszy na normalnych maszynach bez rozszerzonej pamięci. Poniekąd zrozumiałem autorów "Bomb Jacka" i teraz trochę inaczej patrzę na kwestię rozszerzeń sprzętu (choć nadal jestem antyVBXE).
Oczywiście w tej sytuacji obrazki z Atari ST w 160x100 stały się już zbędne, bo nie ma żadnego sensu skalować do 320x240 (a właściwie 160x240 z uwagi na piksele 2x1). Postanowiłem poszukać oryginału, prawdziwego oryginału. Znalazłem go na Youtube - trwa 30 minut i ma rozdzielczość 320x240. W rzeczywistości jest on tam wrzucony trzy razy, podzielony na trzy części ze względu na limit 10 minut na Youtube. Dwie wersje, mimo iż w 320x240, to wyglądają tak jak najgorsze nagranie z kasety VHS przegrane/obejrzane tysiąc razy w czasach giełdy wymiennej z Wrocka z końca lat 80tych, gdzie często się bywało :). Link do jedynej zdatnej do oglądania wersji dałem powyżej. Ale i ta wersja ma wadę: na górze są ze dwie, czasami trzy czarne linie - to powodowałoby, że w każdym zestawie znaków trzebaby z miejsca poświęcić 30-40 znaków na tą linię. Uznałem więc, że obetnę trochę z góry i dla równowagi z dołu, a docelowa rozdzielczość będzie wynosić 320x224. Następnie zgrałem całą animację z Youtube za pomocą "Virtualdub" do tysięcy klatek BMP. Po otwarciu pierwszej klatki z animacji Atari ST zacząłem jej szukać w tym ogromnym zbiorze plików BMP. Tak znalazłem wszystkie 74 klatki. Dzięki rozdzielczości 320x224 i filtrom sharpen oraz contrast udało się uzyskać dość wyraźny obraz. W międzyczasie udało mi się wymóc na TeBe dodanie opcji we wspaniałym "Graph2Font" dotyczącej powtórzeń danej klatki, co znacznie zmniejsza objętość pliku wideo.
Klatka w 320x224 (160x224) w 4 kolorach zajmuje w "G2F" 10 fontów + dane o ułożeniu fontów = 11 KB. Możemy ją zoptymalizować korzystając z opcji Optymizing i tak średnio dane fontów każdej klatki spadają do wartości 8-9 fontów + dane o ich ułożeniu = razem 9KB. To nadal za dużo. Możemy ją skompresować korzystając z programu Algorithma "CSAM" - jednak efekt jest taki jak widać poniżej na porównaniu. Nie wygląda najlepiej, ale zajmuje jedynie 3-5 fonty na klatkę + dane o ich ułożeniu = 4-6KB.
Możemy ją też skompresować ręcznie, to jest samemu analizując, które miejsca w klatce są ważne dla ludzkiego oka (twarze, ciało, elementy istotne jak dom, płatki śniegu które dadzą wrażenie ruchu), a które mniej - jak tło, pokrycie dachu, płotu. Tego automatyczny w swym działaniu program nie zrobi, gdyż on działa na podstawie różnic, metodą brute force, nie patrząc że ludzkie oko wyczulone jest na pewne szczególy, a inne pomija, lub nie przywiazuje do nich wagi. Oczywiście wtedy cała czarna robota spadłaby na mnie, ale myślę że warto to zrobić, gdyż 95% klatek uzyskanych tą drogą używa jedynie 2 zestawu fontów (a niektóre nawet 1, choć jest i parę, które mają 3 zestawy), a jakość nie odbiega od oryginału - patrz ostatni obrazek w porównaniu powyżej.
Na początku szło jak po grudzie i nad pierwszymi obrazkami siedziałem po 2-3 godziny, nierzadko zaczynając od nowa, potem gdy nabrałem wprawy to czasem w 15 minut i wgrywałem następny. Badając oryginał z Atari ST zacząłem sam układać listę/harmonogram czasu trwania poszczególnych klatek. Praktycznie jest on identyczny z oryginałem, jednak z uwagi na muzykę postanowiłem trochę dodać tu i ówdzie w czasie trwania niektórych klatek, tak aby cała długość animacji wyniosła 1 minutę i 24,6 sekundy czyli dokładny czas 4-krotnego powtórzenia sampla, tak aby animacja po rozpoczęciu od nowa ładnie się zapętliła - w oryginale muzyka dość nieszczególnie się urywa.
Ogólnie wszystkie obrazki używają 154 zestawy fontów i to liczonych już po przeróbce w "G2F". Niestety, mimo iż używałem w każdym foncie jedynie 127 znaków to i tak G2F czasami sam z siebie doda jakiś zestaw - na przykład mam 15 obrazków, które wiem, że używają 30 fontów, każdy po 127 znaków, a po eksporcie G2F informuje, że użyto 32 fontów... Dane obrazka (gdzie dany znak ma wystąpić), zajmują 75 obrazków x około 1KB = 80KB (u mnie jest jeden dodatkowy obrazek, na samym końcu, z info o autorach tej wersji. Ogólnie z uwagi na ograniczenia G2F (limit fontów w zestawie: 127, limit rozmiaru pamięci: 64KB) podzieliłem animację na pięć części i łącznie zajmują one 240 KB + dane audio, które zajmują 62KB. Razem około 300KB czyli 4 banki wideo + 1 bank audio. Limit 320KB nie jest przekroczony! :)"
W dalszej części tej historii do akcji wkracza właśnie TeBe, o czym Irwin pisał następująco:
"Tebe zainteresował się tematem i co chwila coś robi w tej sprawie, podrzuca mi nowe wersje, które są coraz lepsze. Przede wszystkim dźwięk już gra dobrze na przerwaniach IRQ w 4khz. Nie brzmi tak jak na Atari ST, ale jak na warunki małego Atari to wręcz fenomenalnie. TeBe skorzystał tu z procedury grającej sample z gry "Space Harrier" (nadal w produkcji). Odnośnie grafiki - nie da rady zrobić tak, aby jednocześnie mieć ANTIC i sample. Jak to TeBe napisał: "POKEY napastowany jest przez ANTIC stąd te zniekształcenia, rozdzielenie POKEY-a od ANTIC-a zagwarantuje czysty dźwięk, ale to oznacza zmianę sprzętu typu: 1. VBXE + POKEY lub 2. ANTIC + COVOX".
Tak więc TeBe przerobił orginalne obrazki z wersji Atari ST na 4 kolory. Teraz animacja ma 160x100 w 4 kolorach z jakimś ditheringiem typu Floyd (nie moim ulubionym ordered). Jest w trybie GRAPHICS 13 w trybie bitmapy (ANTIC nie jest napastowany ;) na całym ekranie i powiem szczerze -wygląda to lepiej niż moja wersja mimo przeszło 2-krotnie mniejszej rozdzielczości (160x100 zamiast 160x224). Widać TeBe dodając różne opcje ditheringu do "AIS" wprawił się i nawet ładnie to wygląda. Mimo, iż to mniejsza rozdzielczość niż u mnie to całość zajmuje więcej - 300KB przeciwko moim 240KB (to jest jedna z tych zalet ręcznej kompresji). Niby niewielka różnica, ale dodając kod i sample mamy teraz plik ważący około 370 KB (305 KB było u mnie). To oznacza, że rozszerzenie pamięci 320KB to zbyt mało. Jednakże TeBe do swojej wersji dodał kompresje Huffmana i dane wideo spadły z 300 KB do około 200 KB. Teraz plik ma około 260KB, a jest rozpakowywany sukcesywnie w czasie rzeczywistym, więc na rozszerzeniach do 320 KB już działa. A ponieważ jest w bitmapie, a nie na znakach, działa na każdym rozszerzeniu 320KB, to jest także na najbardziej rozpowszechnionym Rambo.
Oczywiście jeszcze nie ma dokładnego planu odtwarzania, klatki są odtwarzane ze stała częstotliwością, bez zapętleń, w kolejności w jakiej są zapisane w pliku DAT wersji AtariST (a to nie jest porządek wyświetlanej animacji). Ponadto animacja jest bez buforowania i klatki się rysują na ekranie zamiast być wyświetlane. Wysłalem więc ów plan kolejności odtwarzania danej klatki, czasu jej trwania jak i zapetlenia zarówno ten ustalony przeze mnie, aby pasował do sampli, jak i ten który otrzymałem od autora wersji na PC - teraz TeBe wprowadzi je do animacji.
I to tyle narazie, prace trwją, TeBe stał się nie tylko autorem kodu, ale i samej konwersji animacji, tak więc moj udział z demka został całkowicie wyłączony. Mnie to absolutnie nie przeszkadza, sam zresztą to TeBe-mu zaproponowałem. Jeśli ma to być zrobione lepiej to jestem całkowicie za wersją TeBe. Ja będe zadowolony z tego, że udało mi się zainteresować TeBe-go zarówno tym demkiem (jakże innym od typowych produkcji scenowych, z wyjątkowo wspaniałą opowieścią i równie piękną muzyką), jak i samplami (kto wie, czy dzieki temu gra "Pang" nie dorobi się sampli ;). Tak więc jest nadzieja, że oprócz wersji na Atari ST Amigę i PC The Snowman pojawi się na jeden stareńki 8-bitowy komputer - i nie będzie to C64, a nasze Atari :)."
Dzisiaj wiemy, że marzenie Irwina się spełniło, bo TeBe zaprezentował demko "The Snowman" pisząc o nim tak:
"The Snowman" na Atari XL/XE
"Klatki są w trybie znakowym (160x96 piksli), piksel proporcjonalny 2x2 hires (GRAPHICS 13 BASIC-a), 5 kolorów, odcienie szarości, każda klatka to 4 zestawy znaków (próba dla kompresji każdej klatki oddzielnym zestawem znaków - z kompresją powtarzających się znaków wykazała 276 różnych zestawów, jednak trudniej było tym zarządzać, buforować, itp., dlatego zrezygnowałem z takiej wersji).
Pomysł procedury przerwania IRQ odgrywającej sampel przy aktywnych przerwaniach DLI, NMI - autora konwersji gry "Space Harrier" Sheddy-ego (źródło AtariAge). Są dwie wersje:
- wersja SNOWMAN_DF7.XEX pakowane DEF7Z (dekompresja INFLATE
Fox-a) z ditheringiem (15 banków pamięci),
- wersja SNOWMAN_SQZ.XEX pakowania SQUASH 1.5 bez ditheringu (16 banków pamięci).
Sampel zajmuje 4 banki pamięci, 4-bitowy (oryginalnie 8-bitowy), czyli w 1 bajcie zapisane są dwie próbki, inaczej musiałby zajmować 8 banków pamięci.
Było bodaj z 8 różnych wersji, podejść do tej animacji, m.in. w trybie bitmapy (4 kolory) i w trybach znakowych, różne wersje kompresji, buforowania, itp. Wersje finalne są kompromisem między szybkością dekompresji, zajętością pamięci a jakością obrazu. Dither niewątpliwie wyglądał lepiej, kiedy zwiększyłem rozdzielczość pionową dwukrotnie, jednak wtedy nie dało się tego zmieścić w 16 bankach, a kompresja stratna znaków (z którą też eksperymentowałem) nie dawała zadawalających rezultatów dla każdej klatki. Wersja DF7 to dłuższy czas działania dekompresora, SQZ wersja szybsza, jednak w ostatecznym rozrachunku dzięki buforowaniu klatek szybkość nie ma takiego znaczenia.
Pliki XEX nie dadzą się już zbytnio spakować, SQZ co najwyżej do rozmiaru pliku DF7. Tak czy siak dyskietka 180KB (DD) tutaj nie wystarczy."
Jak widać, czasem pozornie proste rzeczy (tutaj: przeniesienie "jakiejś tam" animacyjki) wymagają nie tylko masy czasu na eksperymenty, ale i ogromnej wiedzy, a także wielu kompromisów... Miejcie to na względzie przy ocenianiu i krytykowaniu ludzi, którzy robią coś na retrokomputerach. A oto pliki demka. Za zainteresowanych mam też podesłany przez Irwina pakiecik - demko w wersji Atari ST, Amiga i PC oraz jego niedoszła wersja dla małego Atari.
Kaz 2009-11-18 01:35:31
Wrzucilem jeszcze kompilacje Irwina - jego reczne klatki polaczone w jeden filmik z Atari XL/XE z muzyka podlozona z oryginalu. Tutaj filmik:
http://www.youtube.com/watch?v=2uZx5KBwz8A
Warto tez obejrzec wersje ST:
http://www.youtube.com/watch?v=LUI428lF5eo
Tdc 2009-11-18 01:51:46
Racja to demko robiło spore wrażenie, a ludzie je lubili. Ja może nie przepadałem za nim, ale kiedyś w GFA Basicu napisałem program który wyciągał tę muzyczkę. Byłem zaskoczony, że miała tak słabą jakość (nawet jak na ST czy małe Atari). Co ciekawe jakoś nikt tego nie zauważał przy oglądaniu tego niegdyś na np. Atari ST, widocznie treść filmiku wciągała tak, że na parametry nikt nie patrzył ;)
Tezz 2009-11-18 02:55:04
Excellent! Very well done, I remember the original ST demo well
marcin 2009-11-18 03:19:10
Jako miłośnik bałwana pozwolę sobie kilka linków dorzucić
strona oficjalna: http://www.thesnowman.co.uk/
wikipedia: http://en.wikipedia.org/wiki/The_Snowman
imdb: http://www.imdb.com/title/tt0084701/
google video (całość w 1 kawałku):
http://video.google.com/videoplay?docid=2067664373050394413
muzyka: http://stuff.fork.pl/walinkg-in-the-air/
sikor_ 2009-11-18 07:37:37
Całkiem przyjemnie wyszło, pamiętam to demko z STE.
========KAZ, nadal moje hasło nie działa do komentowania
Emu 2009-11-18 09:10:51
Kaz, w pliku "pakiecik" brak wersji dla Amigi?
tbxx 2009-11-18 09:14:08
reklamówka z motywem snowman http://www.youtube.com/watch?v=9wMs5bUkjO0
Ciekawski 2009-11-18 09:29:16
"Klatki są w trybie znakowym (160x96 piksli), piksel proporcjonalny 2x2 hires (GRAPHICS 13 BASIC-a)"
- no ciekawe, a jak uzyskac taki tryb gfx w G2F (jesli ktos chcialby zmontowac wlasna historie wiec to co opowiadacie nie byloby calkowita "sztuka dla sztuki") ??? ;o
Kaz 2009-11-18 10:12:19
Sikor - piszesz to w kolejnym komentarzy i tam Ci juz wyjasnialem: wszystkie hasla zostaly zmienione po wlamie do systemu nowinek, jezeli chcesz nowe haslo to napisz jakie i przyslij je do mnie.
Emu - racja, wersji Amigi w pakieciku nie ma, napisalo mi sie z rozpedu, sorki.
Marcin, Tbxx - dzieki za dodatkowe linki.
tbxx 2009-11-18 10:29:07
Z tego co widzę to w demie na ST zostały użyte klatki z filmu "the Snowman", do którego linka podał Marcin. Czy używając do konwersji oryginalnych klatek z filmu zamiast tych z ST efekt mógłby być jeszcze lepszy?
rako 2009-11-18 11:15:47
Czepiacie się, jest Bardzo Fajne!!! i bardzo się cieszę, że nareszcie jest śnieżny człowiek na Maluszku.
seeman 2009-11-18 11:31:10
@tbxx
Link ktory podal Marcin zawiera film w slabszej jakosci niz ten ktorym Irwin sie posluzyl - gdyz jak poczytasz dokladnie tekst, to zobaczysz, ze Irwin wlasnie tak zrobil jak piszesz: zrobil wersje bazujac nie na klatkach z AtariST, a z filmu z Youtube, ktory ma jakosc lepsza niz ta z podana przez Marcina na Google.
Całe wideo z tej właśnie wersji Kaz umiescił w pierwszym komentarzu:
http://www.youtube.com/watch?v=2uZx5KBwz8A
Poszczegolne jej czesci: 5 plików xex, znajduja sie w pliku:
http://atarionline.pl/pliki/irwin_thesnowman.7z
ktory Kaz podal na koncu artykulu.
Caco 2009-11-18 12:43:42
Jak dla mnie rewelacja. Kawał dobrej roboty. Gratulacje za dobrnięcie do końca tematu !
mono 2009-11-18 13:37:27
Bardzo fajne demo - gratulacje Irwin i TeBe. Demo zachowało swój klimat, nawet mimo niewielkiej ilości kolorów.
Słyszałem "Walking in the air" w wykonaniu Tarji z Nightwisha, ale nie wiedziałem, że to jest motyw z filmu. W linkach podanych przez marcina jest zresztą też ta wersja.
Nie wiem czemu, ale u mnie (Ubuntu 9.04 x86_64, FireFox 3.0.15) wideo z youtuba umieściło się na obrazkach a nie pod :(
Kaz 2009-11-18 13:42:17
Mono - zapewne gdzies sknocilem znaczniki htmla, jak Scalak znajdzie czas to pewnie rzuci okiem.
mono 2009-11-18 13:47:07
Już jest ok (to jakieś humory mojego komputera). Irwin - trzeba przyznać, że Twoja ręczna kompresja jest BARDZO DOBRA! Tylko niewiele odstępuje od wersji wyjściowej w g2f.
F6 2009-11-18 13:50:38
:)
http://www.worldofspectrum.org/infoseekid.cgi?id=0004609
Kaz 2009-11-18 13:59:56
"Sinclair User's" review:
"THE SNOWMAN, for the 48K Spectrum, is a game based on the best-selling book of the same name by Raymond Briggs. It is based loosely on some of the action in the book but it centres on the building of the snowman. It should appeal to young children because of its non-violent nature.
To build the snowman you have to collect snow and avoid the flames which will chase you so that you can turn it back into water.
In some ways the game is like Jet-Pac, from Ultimate, as there is a drop site on the left of the screen which you must reach to mould the snowman's body and dress him.
There are four stages to each round. The first is to collect the snow, the second to put on the features, the third to dress the snowman and the fourth to collect ice cubes to prevent him melting. Once all of those phases have been completed you will move to round two and a different screen layout.
There are two ways of winning points. You could forget about building the snowman at the first stage and collect objects such as crackers, stockings and Christmas trees. That will boost your score considerably, so long as you do not fall from the ice structure. If you do, or your energy level is depleted too much, you will fall back into bed.
The alternative is to build the snowman but risk the wrath of the sleep monsters, which can only be combated using the special alarm clocks.
The game is attractive and is a change from the violence of Space Invaders and the like."
xxl could convert it ;)
_rocky 2009-11-18 14:06:45
tebe:
Ja bym w tej wersji 4 kolorowej podmienił kolory szare na odcienie brązu.. animacja nabrała by "ciepła", które emituje z oryginału..
glowas11 2009-11-18 18:23:38
Powiem tak znam to demnko i tez mi sie mzyło aby zagościło na Atarce 8 bit-owej . TEBE jesteś wielki i żyj na sto lat bo jeśli odpukać coś ci się stanie to bedzie to ogromna strata dla narodu polskiego .
Wielkie gratulacje panowie .
PS. przyłączam się rocky też uważam że odcień brązu nada klimatu .
Jacques 2009-11-18 20:39:10
Trochę bardziej slideshow niż animacja (cóż, nominalne 1,79 MHz ;-) , ale i tak kawał dobrej roboty, dzięki tebe! W połączeniu z odpowiednią muzyką ma naprawdę dobry klimat, taki melancholijny... :-)
tbxx 2009-11-18 21:32:08
74 klatki/2.30min demo, ciężko z tego zrobić płynna animację. Po za tym płynność porównywalna do tej z mocniejszych komputerów. Szkoda że tak późno - znalazłem "The Snowman" w wersji divx 512x384, bez porównania ładniejsza wersja od tej z youtube...
_rocky 2009-11-19 15:47:06
tbxx:
A jest gdzieś udostępniona ta ładniejsza wersja...
W sumie fajna bajka dla dzieci na święta..
tbxx 2009-11-19 19:08:37
np tu:
http://www.btmon.com/Video/Movies/The_Snowman_1982_Cartoon.torrent.html
CharlieChaplin 2009-11-20 00:48:53
Well,
here you can find/download a different snowman animation, I did many months ago:
http://www.atariage.com/forums/index.php?app=core&module=attach§ion=att
ach&attach_id=145012
The animation was done with tip animator 2.7 or 2.8 and has some flicker, it requires a min. of 128k RAM to run... -Andreas Koch.
P.S.: I cannot find the source (GIF-animation) anymore. otherwise I could do a better animation of it nowadays...
CharlieChaplin 2009-11-20 00:52:58
Hmm,
above link does not work (the copy & paste did not work correct, don`t know why). So simply use this link:
http://www.atariage.com/forums/topic/153666-snowman-demo-atari-st-original-on-lit
tle-atari/
and then goto post nr. 5 to download my snowman animation (which is for adults only)... -Andreas Koch.
mono 2009-11-20 10:49:47
A tak nawiasem - czemu nie przytrzymaliście tego na któreś party? Np. na Forevera 2010?
Jacques 2009-11-20 12:18:41
Może dlatego, że grudzień za pasem? ;-)
irwin 2009-11-21 08:44:52
Przede wszystkim dzięki wszystkim za pochwały - oczywiście idą one na konto Tebe'go gdyż to on wszystko zrobił.
@Marcin, tbxx - dzięki za linki
@Emu - no właśnie nigdzie nie można znaleźć wesji na Amige a na 120% takowa jest bo naocznie ją widziałem na początku lat 90tych i to na mojej A500 ;) Ktokolwiek widział? ktokolwiek wie?
@Ciekawski - być może Tebe kiedyś taki tryb w G2F, jednak kiedy i czy w ogóle to pytanie do niego. Są sytuacje że on coś robi bo ktoś chce a potem nikt z tego nie korzysta - vide AIS.
@TDC - odnośnie jakości sampla z wersji AtariST - ja również jestem ową jakością zaskoczony tyle że na plus tzn że jest tak dobra. Musisz pamiętać że to były lata 80te i ówczesne przetworniki DAC nie były takiej jakości jak dziś i to zarówno po strnie samplera jak i na AtariSTE. Sam pamiętam jaka była przeogromna różnica jakości tego samego sampla odtwarzanego na Sound Blasterze 2.0 a na SoundBlasterze 16.
Po drugie musisz wziąć też pod uwagę że nie było też takich programów jak Cooledit czy Audiocity które pozwolą na wygładzenie czy usunicie szumów.
Po trzecie dyskietka 720kb nie jest z gumy i mając już plik 600kb z danymi video ciężko ładować tam sampel o większej liczbie khz.
Sam NeHe autor wersji pecetowej był zaskoczony jakością sampla z AtariST, o czym mi też pisał.
@tbxx -lepsza jakość filmu niż ta z youtube nie jest już potrzebna gdyż w ostatecznym rozrachunku na Atari i tak wszystko sprowadzi się do max 160x240.
@Mono - dzięki! trochę czasu nad tym spędziłem. O dacie zadecydował autor czyli Tebe. Trzymanie tego do Forevera nie byłoby czymś dobrym gdyż raz - to demko jest w temacie raczej świątecznym, 6-grudniowym, a dwa na Forever pewnie pojawią się "normalne" dema.
Na zakończenie mała uwaga dla wszystkich: jeśli jakiś koder Atari na nasze zapytanie z miejsca machnie "tego nie da się zrobić" to nie należy tego traktować poważnie. ;) Na Atari a zwłaszcza "małe" Atari da się wszystko ;)
Tdc 2009-11-22 21:20:56
irwin: no niestety nie mogę się z Tobą zgodzić. Na ST w dobrych demkach było minimum 30 kHz (a w jeszcze lepszych - jeszcze więcej) (mam na myśli Yamaszkę), a na małym atari z Crystal Sound też tyle dało radę. Dlatego 8khz to naprawdę mało - może powiem inaczej - trudno znaleźć na ST demko z tak niską częstotliwością (na małym Atari w tamtym okresie było ich sporo, różne madonny itp.).
Co do pecetów to jest to odrębna dziedzina, bo wspomniane karty SB 2.0 to początek wychodzenia pecetów z ciszy, który nastąpił jako ostatni (w końcu nawet Apple miały dźwięk). Dlatego tę epokę dźwiękowego kamienia łupanego pozostawmy na następny raz;)
irwin 2009-11-22 21:59:58
Ok, więc sprawdzmy: podaj mi choć jeden tytuł demka na ST w którym jest sampel minimum 22 sekundowy o parametrach jak piszesz tj 30khz.
tdc 2009-11-23 03:22:53
Ja takiego nie znam, ale z reguły nie oglądałem/zgrywałem demek w których leci sama muzyka ;) Natomiast masz tu wiele racji bo zwykle w demkach było robione coś na kształt modułów. Dlatego być może są takie przykłady ale ja się do demek na ST nie włamywałem (miałem ST dość krótko). Może ktoś inny poda jakiś tytuł, mi przychodza do głowy różne demka, gdzie na słuch wiem że jest sporo ponad 20 kHz, ale nie wiem jak zostało to technicznie zrealizowane.
Natomiast w STE często w demkach leciał prosty sampl, ale były to często częstotliwości związane z trybami pracy układu STE czyli głównie 25 Khz. Podobnie jest w najnowszym bardzo fajnym demku.
Jeszcze tak na marginesie dodam, że ST nie miało dźwięku 8 bitowego, dlatego przy 4 bitowym zapisie 30 kHz w 22 sek to 330 kb. w demku jest to wielkość zupełnie akceptowalna.
sikor 2009-11-23 06:49:25
@TDC, przykro mi, ale lejesz wodę. Ani z Ciebie programista, ani... Tylko gawędziasz, niestety - muszę tu przyznać rację KMK, bo cała dyskusja na atariarea, jak i Twoje wypowiedzi tutaj świadczą tylko o tym. Ja widziałem, ja zrobiłem, ja się ze... (a nie, może to i zrobiłeś). A proste pytanie: daj link/przykład i Ty ani be, ani me. Wot przykrość, czyżby rzeczywistość mijała się z Twoimi gawędami?
Prosty przykład z kilku komentarzy powyżej:
TDC: [..]irwin: no niestety nie mogę się z Tobą zgodzić. Na ST w dobrych demkach było minimum 30 kHz (a w jeszcze lepszych - jeszcze więcej) (mam na myśli Yamaszkę), a na małym atari z Crystal Sound też tyle dało radę. Dlatego 8khz to naprawdę mało - może powiem inaczej - trudno znaleźć na ST demko z tak niską częstotliwością (na małym Atari w tamtym okresie było ich sporo, różne madonny itp.).[,,]
a zaraz potem:
TDC: [..]Ja takiego nie znam, ale z reguły nie oglądałem/zgrywałem demek w których leci sama muzyka ;) Natomiast masz tu wiele racji bo zwykle w demkach było robione coś na kształt modułów. Dlatego być może są takie przykłady ale ja się do demek na ST nie włamywałem (miałem ST dość krótko). Może ktoś inny poda jakiś tytuł, mi przychodza do głowy różne demka, gdzie na słuch wiem że jest sporo ponad 20 kHz, ale nie wiem jak zostało to technicznie zrealizowane.
Natomiast w STE często w demkach leciał prosty sampl, ale były to często częstotliwości związane z trybami pracy układu STE czyli głównie 25 Khz. Podobnie jest w najnowszym bardzo fajnym demku.[..]
Więc jak to jest, minimum 30 czy 22Khz? Wyciągałeś muzykę z dem czy nie, jak piszesz wcześniej? Masz słuch muzyczny, że rozpoznajesz minimum 20KHz, czy nie masz? Od kiedy Crystal Sound dawał radę z 30KHz, bo ja o takiej możliwości )CS na małe Atari) nie słyszałem?
Prosimy Tomku o szczegółowe wyjaśnienia, jak nie znasz - za przeproszeniem, nie pieprz głupot, bo to już się robi nudne.
irwin 2009-11-23 11:18:00
@TDC
Wyjaśnijmy tę sprawę po kolei ;)
Specjalnie zapytałem Cię o podanie choć jednego tytułu demka z minimum 30khz aby zwrócić Ci uwagę że: realne parametry sampla tj liczba bitów i częstotliwość w hz to coś innego od miksowania modułu w pamięci i następnie odgrywania go przez układ dzwiękowy komputera.
"The Snowman" w oryginale ma dzwięk 8khz (8000hz)
Demka na AtariST z uwagi na brak sprzętowego układu jakim jest Paula w amidze odgrywały moduły-muzyczki poprzez miksowanie 4 lub więcej kanałów, niejako można to nazwać wirtualnym samplowaniem w pamięci, (przynajmniej ja to tak bym nazweał ale koderem nie jestem detali nie znam) w określonej liczbie khz poprzez procesor główny 68000, a następnie całość była wysyłana na już prawdziwy układ grający. Liczba khz zależała od liczby kanałów, i innych czynników ale głównie od ilości czasu jaki koder jest w stanie poświęcić na procedure grającą kosztem efektów wizulanych.
Moduł muzyczny składa się z 4 lub więcej scieżek z notacjami które zawierają jaki dzwięk o jakiej głośności, i jakiego instrumentu-sampla ma być zagrany.
Pytanie nr 1: Czy wiesz jaka jakość sampli dominowała (praktycznie w 95%) w modułach z lat 86-94? Tak aby porównać je do "tak słabej jakości" jak piszesz sampla z The Snoman?
odpowiedź brzmi: około 8khz (a dokładnie 8363hz a to z uwagi "MOD samples generally use a sampling rate of 8363Hz for a C in the second octave" oraz specyfike układu Paula w Amidze)
Pytanie nr 2: Czy 8.0khz w Snowman jest znacząco gorsza od 8.3khz w 95% modułów z tamtych lat?
Pytanie nr 3,4,5 i 6: Załóżmy że zamiast sampla w Snowman mamy moduł który ma jedną scieżkę, jeden pattern i jeden sampel 8khz o długości 22 sekund. Bez problemu można taki moduł zrobić w dosłownie minutę. Całość miksowana jest jak w innych demkach z AtariST powiedzmy niech będzie jak piszesz w 30khz. Czy jakość sampla nagle wzrośnie do 30khz? Czy obrazek 16 kolorowy z AtariSt oglądany na PC będzie miał znacząco lepszą jakość? Czy 2 zł włożone do miejsca gdzie się trzyma 5 zł'ówki stanie się 5złotówką? ;) Czy wyciągałeś sample-instrumenty z owych modułów z atarowskich demek i czy nie zdziwiło Cię że praktycznie wszystkie mają sample w okolicach 8khz?
Tak więc nie należy mylić samego sampla z procedurą odgrywającą bo to prowadzi do mylnych stwierdzeń. Może być też tak: że sampel np 22khz może brzmieć ładniej od modułu miksowanego w np 35khz z samplami 8khz. To są dwie odrębne sprawy.
Zaś jeszcze co do samego sampla - powtórzę: musisz pamiętać że to były lata 80te i ówczesne przetworniki ADC i DAC nie były takiej jakości jak dziś. Dziś mając użyteczne programy o których pisałem i bardzo dobre jakościwe samplery można zrobić plik 8khz który będzie czystszy. Tyle że to dziś a nie w 1987 roku. Po drugie przypomnę o tym że dyskietka nie była z gumy i mając 500-600kb czy to video czy to innych danych (jeśli mówimy od demkach) to koderowi trudno byłoby poświęcić całą masę kb na samą muzykę. A trzeba też pamiętać że i pamięć w samym kompie była ważna. To były przecież lata 80te. Wszystko ma swoją cenę, trzeba iść na kompromis. To dlatego demko zamiast choćby animacji 5 fps ma jedynie 74 klatek na 84 sekundy czyli średnio mniej niż jedna klatka na sec. (w wersji z AtariST) Tego też filmem nie nazwiemy, ale mimo wszystko się spodobało. Zawsze trzeba patrzeć z poziomu realnych możliwości sprzętu w danym okresie i akceptowalnych, dostosowanych do posiadaczy tego sprzętu rozmiarów i wymagań programu czy demka. Dlatego min. wersja na małe Atari chodzi na 320kb.
ps.
- A przy okazji: co to jest te Crystal Sound?
- możesz, lub ktokolwiek inny (ja nie znam się na AtariST i ichnej scenie) podać jakieś demka na AtariST gdzie leci zdigitalizowana muzyka? (nie musi być to demko z efektami wystarczy one screen i sama muzyka)
seban 2009-11-23 11:49:14
gwoli ścisłości, YM2149 miało 5-bitowe DAC-e, więc bez problemu odtwarzało się na nim 5-bitowe sample. Dodać też trzeba iż YM2149 miało logarytmiczną skalę głośności. Można było również wykorzystać trik z sumowaniem głośności 3 kanałów co dawało jeszcze większą rozdzielczość bitową... były playery które miksując 3 kanały uzyskiwały rozdzielczość sampli na poziomie 8-bit. Także YM2149 w połączeniu z motorolą 68k ma naprawdę duże możliwości. A to ile KHz dało się wyciągnąć to zależało tylko od tego co chcemy oprócz odtwarzania sampli robić jeszcze.
irwin 2009-11-23 12:00:18
@Seban - dzięki za info. To by tłumaczyło dlaczego w demku użyty jest sampel 8bit. Po drugie teraz 22 sekundy w 30khz jak chce TDC zajmuje 660kb co wyłącza zastosowanie tylko jednej dyskietki ale przede wszystkim uniemożliwiałoby uruchomienie demka ST z 1mb ram. A w roku 1987 większe ilości ramu niż 1mb były raczej rzadko widziane u użytkowników ;) Osobiście myślę że nawet liczba tych z 1mb nie była zbyt duża.
seban 2009-11-23 12:22:11
W przypadku Atari ST bez problemów może czytać dane w locie z FDD, dekompresować również w czasie rzeczywistym i odtwarzać taki sampel na YM2149... ale w tamtych czasach chyba nikt o tym nie myślał ;)
irwin 2009-11-23 12:46:36
Naturalnie masz rację, dzwięk pewnie dałoby się skompresować jakimś prostym algorytmem stratnej kompresji, także i video - są wszak nieskompresowane. Jestem pewniem że dziś dałoby się zrobić owo demko zarówno z większą ilością klatek jak chodzące nawet na 512kb. Tylko 1987 rok to raczej pionierskie lata nie tylko dla AtariST ale i standadów kompresji audio-video. I oceniając Snowmana należy mieć na uwadze właśnie owe pionierskie czasy, a porówywanie czy to jakości sampli czy video powinno odbywać się w korelacji do istniejących wówczas demek, sprzętu, narzędzi, rozwiązań itd. Dziś niektórzy Atarowcy zapominają o tym, pisząc np. że dana gra wygląda i działa lepiej niż jej pierwowzór z końca lat 80tych z C64.
seban 2009-11-23 12:52:40
dlatego właśnie napisałem że w tamtych czasach nikt o takich technikach raczej nie myślał. Może to śmieszne jak przyznam się iż jak zobaczyłem to demko na ST to mnie w tamtych czasach zatkało... niestety na ST nie było mnie stać :) Tak więc jak najbardziej doceniam twórców tego dema :)
tdc 2009-11-23 14:56:08
Irwin i seban: dzięki za rzeczowe opisy. Ogólnie nie zaskoczyliście mnie i nie chcę tu z Wami dyskutować bo się zgadzamy.
> liczba bitów i częstotliwość w hz to coś innego od miksowania modułu w pamięci i następnie odgrywania go przez układ dzwiękowy komputera.
Racja tylko, że w demkach zapewne każdy programista robił to po swojemu. Ja to sobie wyobrażam, że były to znacznie uproszczone mechanizmy niż moduł, bo po pierwsze mało było na ST we wczesnym okresie dobrych algorytmów do modułów (były żenujące), a po drugie koderom zależało na wydajności.
W dobrych demkach, koderzy starali się odtwarzać dźwięk o najlepszej jakości, co nie musi się równać z jego parametrami (musiał brzmieć dobrze), czyli sampl poniżej 15 kHz odpadał. Do tego najłatwiej wtedy jest właśnie odtworzyć długi sampl niż bawić się w bardziej skomplikowane playery na kilku kanałach (co jednak nie wykluczam że pojawiało się – np. w niektórych częściach demek itp.).
> Tego też filmem nie nazwiemy, ale mimo wszystko się spodobało.
I ja jako osoba niezwykle pedantyczna w tym względzie, muszę jednak przyznać że jest to piękne. Jest to pewien artyzm, aby słabymi środkami osiągnąć coś co jest dobre i zapada w pamięci.
> A przy okazji: co to jest te Crystal Sound?
To jest taki program i sprzęt.
http://atariki.krap.pl/index.php/Sampler
W przypadku programu to jest to jeden z tych, który rozwala emulatory :):) Bo emulatory zakładają, że małe Atari potrafi odtworzyć maksymalnie ~15 kHz odtworzenie większej częstotliwości np. tym programem kończy się katastrofą)
> możesz, lub ktokolwiek inny
Jak już wcześniej pisałem słabo znam te demka muzyczne. Ale tak na szybko podam kilka przykładów prawdziwych demek (które mam nadzieję że są z lat 80 – choć pamięć moja już nie ta ;) ):
1. tu jest fragment European Demo, które na pewno jest z lat 80, jednak z tego co pamiętam to tam była dość niska jakość sampli (10- 15 kHz) ale to tak z pamięci.
http://www.youtube.com/watch?v=mhzqQVb4NxU
2. ULM
Niestety nie znalazłem właściwych fragmentów tego demka, ale mam je na dyskietce, więc jak ktoś jest zainteresowany to mogę podesłać.
a) fragment demka, nie wiem ile tu jest kHz, bo nie pamietam oraz w tym efekcie programista mógł coś kombinować aby mieć więcej czasu CPU:
http://www.youtube.com/watch?v=mHAYQZwApn4
Nawiasem mówiąc w tym filmie prawie nic nie widać...
b) Tu widać tylko ułamek sekundy screenu w czasie wczytywania demka, gdzie leciał sobie sampl. W menu demka też było dużo długiej muzyki na samplach.
http://www.youtube.com/watch?v=W8Th7QQ-u1I
3. Szukałem jeszcze jednego starego demka z ST gdzie były jakieś muzyczki na samplach, ale nie pamiętam tytułu i nie znalazłem go w necie. Nawiasem mówiąc nie mam go na ST i od wielu lat go szukam.
4. Lost boys – to nowsze demko
http://www.youtube.com/watch?v=KOPS-dyNDnk&feature=related
To demko leciało na pierwszej Grzybsoniadzie. To jest najprawdopodobniej najprawdziwszy moduł w jednym z najlepszych odtwarzaczy jak na ST (pojawia się w tym demku też w innych częściach).
5. Przypadkowe znalezisko z netu:
http://www.youtube.com/watch?v=je2EgYY5IeE
seban: „Można było również wykorzystać trik z sumowaniem głośności 3 kanałów co dawało jeszcze większą rozdzielczość bitową...”
No tak ale demka się raczej w to nie bawiły. Pamiętam jakiś odtwarzacz z lat 80, prosty tekst na czarnym tle (jeśli mnie pamięć nie myli), który potrafił właśnie osiągnąć około 40 kHz na Yamaszce i inne fajne rzeczy.
Irwin: „Po drugie teraz 22 sekundy w 30khz jak chce TDC zajmuje 660kb co wyłącza zastosowanie tylko jednej dyskietki”
Skoro sam piszesz że RAMu za dużo nie było to tym bardziej każdy koder myślał o samplach 4 bitowych a nie 8 ;)
Sikor... no nie ! Znowu masz urlop... znowu mnie zaczepiasz... Nie mogę z Tobą dyskutować bo już to wielokrotnie przerabialiśmy jak to się skończy. Jeśli zrozumiesz na czym polega różnica w oprogramowaniu ST i STE, przeczytasz moją wypowiedź jeszcze raz to ją zrozumiesz. Co do programów to napisałem (chyba) 1 program wyciągający muzykę z „bałwanka”, natomiast demek na ST jest tyle, że moje jedno wyciągnięcie nie kwalifikuje się do określenia „wyciągałem muzykę z dem ST” (za krótko miałem ST aby się w to bawić).
irwin 2009-11-23 17:38:29
@TDC - dzięki za przykłady, problem w tym że we wszystkich zamiast sampli jako głównej muzyki dema są moduły z samplami oczywiście 8khz. Owszem czasami wśród przerywnikach które zapodałeś na youtube są grane same sample ale:
- po pierwsze trwają one po 3-4 sekundy a to trudno uznać za scieżkę dzwiękową
- po drugie wbrew temu co piszesz we wszystkich owe sample mają po 8khz (jak to sprawdzić? - wgrywasz steem i gdy jest grany ów sampel, zapisujesz stan pamięci do pliku, następnie ów plik wgrywasz do edytora audio - np Audiocity czy Cooledit, 8bit unsigned, na przebiegu widać charakterystyczne dane dzwięku, wycinasz je lub na odwrót kasujesz śmieci, następnie dajesz reverse bo sampel jest obrócony i voila mamy sampla. - przyklad: http://rapidshare.com/files/311123392/aa__8_.001.wav.html)
Osobiście sądzę że owe choćby 20khz sample używane jako scieżka dzwiękowa można włożyć między bajki ;) Tak więc pozwolisz że niezgodzę się z Twoim "W dobrych demkach, koderzy starali się odtwarzać dźwięk o najlepszej jakości, co nie musi się równać z jego parametrami (musiał brzmieć dobrze), czyli sampl poniżej 15 kHz odpadał." gdyż takiego demka gdzie choćby grany był samplel 15khz jako scieżka dzwiękowa dema nie znam. Chyba że mi go podasz(a zaczynaliśmy od 30khz ;) teraz moje wymagania spadły;) tylko warunek jest taki, musi mieć choć 15khz i stanowić scieżkę dzwiękową dema tj minium ze 20 sekund ;)
Co do sampli 4bit - spróbuj sobie przerobić mp3 na np 4bit 30khz i 8bit 15khz i powiedz który lepiej brzmi. Wiesz mi ja wolę 8bit 8khz ze Snowmana niż 4bit 30khz gdyż różnica jakości na korzyść 8bitów jest duża.
irwin 2009-11-23 17:41:10
Aha i dzięki za info o tym Crystal Sound - nie słyszałem o tym, fajna zabawka. Szkoda że tak mało w Atariki o tym, chętnie bym się więcej dowiedział.
seban 2009-11-23 18:47:02
a propos crystal sound: jeżeli mówimy o samplerze crystal sound dla małego Atari to mogę rzucić nieco światła na sprawę, natomiast jeżeli istniało coś takiego dla atari 16-bit to niestety się nie orientuję ;) uświadomcie mnie o którą wersję wam chodzi to będę mógł się wypowiedzieć lub nie ;)
irwin 2009-11-23 19:09:30
Mnie chodzi o wersję dla małego Atari. I ogólnie możliwości małego Atari w zakresie odtwarzania sampli. Czy dałoby się bez wyłączenia ekranu, z wyświetlanym prostym screenem i scrollem odtworzyć:
- sampel o jakich parametrach
- 3-4 kanałowy moduł z Amigi i o jakich parametrach (bity i khz)
sikor 2009-11-23 19:58:29
@irwin, co do crystal sound i jego możliwości: http://atari.fandal.cz/detail.php?files_id=223 - ale było tego więcej (z 10-15 części ogólnie, część z nich w nazwie nie miała "crystal sound").
Co do odtwarzania sampli: tak, można. O szczegóły uderz do Sebana, ja nie wytłumaczę niestety co i jak, bo ja zwykłym userem jego procki jestem (demo ASCII GIRL - ale tam akurat przy samplu wyłączony ekran jest).
Co do modów: jest MOD Player, ale on chyba md8 odtwarza (o ile dobrze pamiętam), same mody można tworzyć bodajże w Future Composerze (nie pamiętam jakie ograniczenia), a dość dobrą jakość daje NeoTracker Epi-ego (ale modów nie zapisuje, tylko odtwarza). O ile pamiętam - w małym Atari jest do 4 kanałów (mogę się mylić) i ograniczona wielkość sampla (dość mocno), ale ponieważ nie jestem muzykiem - nie powiem jaka dokładnie (trza poszukać info).
irwin 2009-11-23 21:12:06
@Sikor - dzięki! za linka i za info. Ciekawi mnie czy można by zrobić proste demko z prostymi efektami ale z muzyką z trackera bądź muzyką 2 kanały synteza Pokey+1 kanał digi.
seban 2009-11-23 22:10:13
@irwin: moduł przy włączonym ekranie + scroll:
http://atari.fandal.cz/detail.php?files_id=970
jakoś: 4-bity na kanał, player bez tablicy umożliwiającej osiągnięcie precyzji 5-bit. Nie brzmi to jakoś rewelacyjnie. Ale dało się coś zrobić jak widać. Ile KHz wyszło nie pamiętam... jak się nie chwali SoTe w scrollu to trzeba by było policzyć. Procka odtwarzająca nie jest jakoś ekstremalnie optymalizowana, dało by się wycisnąć więcej. Coś mi się kojarzy że udawało się wycisnąć 3.5 do 4KHz.
Teraz o crystal sound dla 8-bit atari. To co pokazał Sikor, to chyba sztandarowa produkcja wykonana programem dołączonym do samplera crystal sound. Takich produkcji było bardzo dużo... swego czasu produkował je Marek Górecki (EGR General Programming a.k.a. Górecki Productions). Program dołączony do samplera umożliwiał wczytanie sampla, obrazka, zestawu znaków oraz wpisanie tekstu scrolla. Następnie ten program zapisywał wszystko jako plik wykonywalny i w ten sposób powstawały tego typu produkcje. Widziałem ich na pewno ponad 5 szt.
Co do strony sprzętowej crystal sound (będę go nazywał CS w skrócie) to na tamte czasy była to fajna zabawka i zrealizowana w dość śmieszny sposób od strony sprzętowej. Domyślam się iż w czasach gdy powstawał CS kupno w Polsce taniego przetwornika A/C graniczyło z cudem. Twórcy rozwiązali ten problem używając polskich układów scalonych UL1970 lub UL1980. Były to układy stosowane w diodowych wskaźnikach wysterowania (UL1970 - punktowy, UL1980 - tzw. linijka śwetlna). Całość była podpinana do portu joysticka.
Większość z tego co napisałem to moje domysły ponieważ nigdy nie posiadałem CS w swoich rękach a to co piszę wnioskuję na podstawie kodu programu do CS który miałem okazję kiedyś analizować. Rozwiązanie proste i skuteczne jednak proponuje obejrzeć sample zrobione tą techniką.
Upraszczając do bólu w przypadku normalnego przetwornika A/C robimy tak iż jego punkt pracy ustawiamy w połowie zakresu pomiarowego i mamy możliwość pomiaru zarówno napięć w zakresie dodatnim jak i ujemnym. Pomijając tu format zapisu sampli (ze znakiem lub bez) mamy możliwość uzyskania wartości np -8 do +7 (przy założeniu iż mamy do czynienia z 4 bitowym A/C), lub gdy przetwornik pracuje tylko przy dodatnich napięciach wejściowych otrzymujemy wartości od 0 do 15 (w tym wypadku cisza na wejściu będzie reprezentowana przez wartość 8). W przypadku UL1970/UL1980 w zależności od napięcia podanego na wejście układu układ uaktywniał kolejne wyjścia proporcjonalnie do poziomu sygnału wejściowego. Mając 16 wyjść z układu można było pokusić się o konwersję 4-bitową jednak to wymagało enkodera '1 z 16' na system binarny... nie wydaje mi się aby CS taki posiadał. Sądząc po kodzie który widziałem w tamtych czasach... wyjścia UL1970/80 były podpięte bezpośrednio pod porty Joystick-ów a konwersji dokonywał software. Także CS mógł określić maksymalnie 8 (lub 10 poziomów jeżeli by wykorzystać wejścia trig_in z GTIA). Nie pokrywało to pełnej 4-bitowej rozdzielczości oczywiście co dawało niepełną dynamikę. Również reprezentacja poziomu była mocno niewierna ponieważ mieliśmy tu do czynienia z pewnym uśrednieniem amplitudy sygnału wejściowego ... nie wiem jak to dokładnie napisać... ale złapiecie jeżeli obejrzycie kształt sampla z demek typu CS.
Wiem iż powstał w późniejszym okresie Crystal Sound II, niestety na jego temat niewiele wiem, nie widziałem ani samplera ani softu do niego także nie mogę się wypowiadać.
Również informacje o CS traktujcie z pewnym dystansem. To co opisuje działo się w latach 89-90 i część wniosków to moja własna dedukcja, mogę się mylić lub po prostu moje domysły mogą być błędne.
Przypomniało mi się iż pomysł z wykorzystaniem UL1970/80 był opublikowany lata po powstaniu CS w Tajemnicach Atari... pamiętam iż w gdy zobaczyłem ten art w TA, uśmiałem się że ktoś wpadł na ten sam pomysł parę ładnych latek później ;)
Być może znajdę chwilę czasu i wytnę sample z produkcji crystal sound i pokażę wam na czym polega różnica w symetrii sampli. To powinno unaocznić moje powyższe wypociny.
Reasumując CS był niezłą próbą stworzenia tanio samplera... jednak jakość jaką można było za jego pomocą uzyskać pozostawiała wiele do życzenia. Co do częstotliwości próbkowania to w zależności od produkcji widziałem iż opóźnienie wynosiło od 1 do 3 lini ekranowych. Niektóre z procedur używały liczników pokeya do odmierzania opóźnień (np. produkcja pokazana przez Sikora), niektóre prostej pętli dex, bne, a jeszcze inne po prostu opóźniały się poprzez zapisy do WSYNC. Zakładając iż WSYNC jest to jakieś 15KHz, to w.g. prawem częstotliwości Nyquista jeżeli odtwarzamy próbki z prędkością 15KHz to słyszalne pasmo wynosi połowę tego czyli jakieś 7.5KHz, tutaj teoria:
http://pl.wikipedia.org/wiki/Cz%C4%99stotliwo%C5%9B%C4%87_Nyquista
To co mi się udało wyciągnąć z atari przy odtwarzaniu sampli na pokeyu to jakieś 21KHz (czyli 10,5KHz pasmo), do posłuchania w intrze tego dema:
http://atari.fandal.cz/detail.php?files_id=304
perkusja w intrze przed właściwym demem odtwarzana jest na przerwaniach IRQ generowanych przez POKEY-a z częstotliwością ~21KHz. Do tego dema polecam prawdziwy hardware, na emu nie brzmi jak powinno.
ufff... ale się naprodukowałem ;)
irwin 2009-11-23 22:43:53
@Seban - czapki z głów, dzięki za wyczerpujące przedstawienie tematu - to powinno być na atariki lub Kaz powinien zrobić z Twojego tekstu nowinke.
A samo demko Digital Trash - właśnie oto mi chodziło, tj o perksuje na samplach reszta na syntezie. Jak dla mnie to znacząco poprawia komfort słuchania muzy na Atari. Gdyby jeszcze RasterMusicTracker tak potrafił to wiele prostych nie wymagających gierek można by było tą drogą udzwiękowić.
tdc 2009-11-24 06:13:55
Z racji braku czasu, na razie jedynie obrazek:
http://tdc.pigwa.net/pics/programy/atari/CrystalSound_1988_mab1.png
Program/sampler proponuję testować własnie na tym pliku wczytanym do programu (jest jeszcze dostępny 2 i chyba 3 plik).
seban 2009-11-24 13:39:55
ten program właśnie kiedyś analizowałem, nie pamiętam czy w wersji 1.0 ale 30KHz było wierutną bzdurą niestety. Jeżeli znajdę to w swoich zbiorach to przyjrzę się temu jeszcze raz. I żeby nie było nie twierdzę że na 8-bit atari nie da się uzyskać 30KHz częstotliwości próbkowania (czyli pasmo słyszalne jakieś 15KHz). Kod który widziałem zajmował zbyt wiele cykli aby można było uzyskać wspominane 30KHz, być może miałem jakąś starszą wersję oprogramowania do CS... ale taka częstotliwość próbkowania wymagałaby odtwarzania dwóch próbek w ciągu lini skaningowej... pomijając sens robienia tego przy 4-bitowej rozdzielczości sampla... to długość sampla wykonanego z taką częstotliwością przy buforze jakieś 40-50KB RAM byłaby śmieszna :)
irwin 2009-11-24 16:13:09
@Seban - też tak podejrzewam, raczej wątpie aby małe Atari potrafiło tyle wyciągnąć, zresztą tak jak piszesz nawet gdyby to i tak pożytek z tego byłby marny z uwagi na kolosalną zajętość takich sampli. Mnie tam na małym Atari wystarczyłoby nawet 6khz, i myślę że byłaby to wartość optymalna ze względu na jakość i zajętość pamięci.
@Tdc - a możesz podać, zamieścić ów program z tymi samplami -bo Kaza niestety brak, albo ja nie mogę znaleźć. Z góry dziękuje.
seban 2009-11-24 21:11:25
@irwin: pewnie da się tyle wyciągnąć nawet, tylko co z tego? przy tak małej ilości pamięci... pewnie trzeba by trzymać 1 próbkę w jednym bajcie, prockę odgrywającą zapodać na stronie zerowej, wyłączyć ekran. Trzeba by to policzyć ile cykli to zajmie ale sądzę iż powinno się dać. W tamtych czasach chyba nikt nie próbował odtwarzać szybciej niż 15KHz, ale mogę się mylić, przecież nie analizowałem każdego programu z samplami który napotkałem ;)
Poszukam tego programu do crystal sounda na swoich dyskietkach, może uda się odkopać, a jeżeli znajdę zapodam linka.
Typowe prędkości używane do odgrywania sampli to 15KHz (opóźnienie równe jeden lini rastrowej) lub 7,5KHz (opóźnienie równie dwóm liniom rastrowym). Takich prędkości odtwarzania używał Music ProTracker napisany przez SoTe. Również Black Magic Composer jeżeli się nie mylę odtwarzał swoje digi-drumy z prędkością 7,5KHz.
Zdarzały się oczywiście wyjątki od reguły, niektórzy w swoich prockach używali liczników POKEY-a i przerwania IRQ generowanego przez POKEY-a po doliczeniu do zera... ale właściwie takie rozwiązanie miało swoje wady jeżeli chciałeś wykorzystać normalne (syntetyczne) kanały dźwięku... ale to już wywód na długie zimowe wieczory ;)
Wracając do Crystal Sounda nawet jakby wyciągał 30KHz to zastosowane w nim rozwiązania sprzętowe nie było zbyt optymalne i dawało o niższą jakość dźwięku niż w przypadku zastosowania klasycznego przetwornika A/D. Chyba muszę przykład jakiś przygotować aby pokazać o co mi chodzi :)
I jeszcze jedno... w niczym nie umniejszam twórcom crystal sounda. Wymyślone przez nich rozwiązanie w tamtych trudnych czasach zasługuje jak najbardziej na pochwałę, i było to chyba jedno z niewielu rozwiązań dostępnych na rynku w tamtym okresie... także wielki szacunek dla osób stojących za crystal sound. Pojęcia tylko nie mam ile taki sampler kosztował w tamtych czasach.
Jako samplera używałem swojego wynalazku zbudowanego z układu ADC0809 i podpiętego do portu CART-a, potem gdy z SoTe tworzyliśmy oprogramowanie dla AD Convertera (http://atariki.krap.pl/index.php/Mirage_AD_Converter) dostaliśmy po 1 szt. z Mirage Software. Było to jednak sporo po tym jak powstał Crystal Sound.
Kaz 2009-11-24 21:30:43
Irwin - w jakim sensie brak i do czego jestem potrzebny? :)
Seban - Irwin ma racje, ze te wszystkie informacje zasluguja na zebranie, zilustrowanie przykladami i zaprezentowanie swiatu. Gdybys mial chwile czasu to sluze szpaltami serwisu.
irwin 2009-11-24 21:54:58
Miało być "u Kaz'a brak" czyli w AtariOnline.pl takiej wersji tego programu z dołączonymi, a wymienionymi przez TDC samplami nie ma. Tak więc nie o Kaz'a tu chodzi ;)
Kaz 2009-11-24 22:00:06
OK, to jak znajdziesz taka wersje z dodatkami to ja tez poprosze, bo uzupelnie katalog.
Tdc 2009-11-24 23:29:02
Nie sprawdzałem tego, ale jest to warte sprawdzenia co ten program faktycznie robi. Ja pamiętam, że tylko się wtedy zastanawiałem jak oni to sprawdzili, że w danym momencie jest właśnie tyle Hz itp. (w końcu wtedy na małym Atari nie było programów, które podawały aż tak precyzyjne dane i dało się je dowolnie ustawiać). Bo co do tego że małe Atari tyle wyciąga to nie mam wątpliwości (z mojego ostatniego artka u Kaza odnośnie szybkości Action! pośrednio wynika, że nawet w tym kompilatorze da się osiągnąć częstotliwość o wiele wyższą).
Zamieściłem dla Ciebie ten programik z przykładowym samplem (nigdy na małym Atari nie słyszałem lepszej jakości dźwięku digitalizowanego):
http://tdc.pigwa.net/Prg/Atari8bit/CrystalSnd1988.atr
Natomiast na którejś dyskietce na pewno mam tych przykładów więcej, ale nie mam teraz możliwości aby tego szukać. Może ktoś inny to znajdzie.
Aha i testujcie ten program koniecznie na real Atari.
seban 2009-11-25 01:18:15
@tdc: z tym że w action da się odtwarzać sample 30KHz to trochę przesadziłeś ;) twoja procedura musiałaby się wykonać dwa razy w ciągu linii ekranowej. Śmiem twierdzić iż dla action! nie jest to wykonalne. Mówię o precyzyjnym odtwarzaniu kolejnych próbek ze ściśle określoną częstotliwością. Nie chodzi mi o odegranie kawałka pamięci z częstotliwością wynikającą z przypadku ;) Czyli synchronizujesz się albo licznikami POKEY-a, albo liczysz cykle. I trzymasz po dwie 4-bitowe próbki w bajcie :) tak jak to robi 99,9% programów obsługujących sample na małym Atari.
Zajrzę do kodu programu z twojego ATR-a i powiem Ci czy faktycznie ich procka wyciąga 30KHz (słyszalne pasmo 15KHz). Używają liczników POKEY-a (kanały 3 i 4 połączone w jeden kanał 16-bit) do generowania opóźnień więc w czym problem określić częstotliwość próbkowania?, wzór jest prosty (wspomagałem się atariki):
sample_rate = (F/2)/(R+7)
gdzie F to częstotliwość bazowa 1773447 Hz, a R - wartość wstawiana do rejestru układu POKEY.
dla tych co chcą liczyć szybko jaką częstotliwość soft do CS usiłuje osiągnąć:
http://www.wolframalpha.com/input/?i=%281773447%2F2%29%2F%280x003c%2B7%29
W przypadku ustawienia prędkości na 30KHz, do rej. POKEY-a wpisywane jest $003c, więc faktycznie licznik odmierza okres czasu odpowiadający 31662Hz, ale do tego trzeba doliczyć jeszcze czas wykonania się procedury odtwarzającej. Spróbuję określić realną częstotliwość odtwarzania którą wyciąga oprogramowanie crystal sound.
Dodam jeszcze iż procedura samplująca jest jeszcze dłuższa, ponieważ musi dokonać konwersji i korzysta z 256-bajtowej tablicy konwersji. Z kodu widać iż crystal sound był podpinany do dwóch portów joysticków. To co mogło wyjść z niego to jak widzę wartości od 1-8 ... a więc sample są de facto rozdzielczości 3-bit. No chyba że hardware był inny niż myślę i wtedy jestem w błędzie. Ale pewnie nikt nie ma crystal sounda? co? ;)
Jest jakiś miąch z tablicą konwersji, i wygląda na to że było coś więcej niż UL1970/UL1980 ale na chwilę obecną nie mam chęci wnikać za bardzo... sprawdzę to później... na dziś mam dość ;)
Tablica konwersji (PORTA->Sample Value) jest pod adresem $2f00:
2F00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F10 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F20 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F30 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0E
2F40 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F50 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F60 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F70 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F
2F80 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F90 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0C
2FA0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2FB0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0D
2FC0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A
2FD0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0B
2FE0 : 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 09
2FF0 : 00 00 00 06 00 00 00 07 00 04 00 05 02 03 01 00
Niby pokrywa pełne 4-bity, więc może się myliłem co do 3-bitowości Crystal Sound-a? Coś mi świta w głowie iż mogli dołożyć enkoder priorytetowy 1 z 10 na BCD ;) np. coś w rodzaju 74LS147 do tego UL1970/UL1980 mieliby 10 poziomów ;) tudzież dwa 74LS148 ;) Tak, chyba bym użył dwóch 74148 i UL1970 ;)
dla zainteresowanych tematem:
http://focus.ti.com/lit/ds/symlink/sn54ls148.pdf
http://www.iele.polsl.pl/elenota/CEMI/ul1970.pdf
No pora chyba przeanalizować kształt i zawartość sampli aby się przekonać czy CS był na prawdę full 4-bit ;)
Procedura odtwarzająca jest pod adresem $2ba0
Procedura samplująca jest pod adresem $2c0e
Ktoś chętny do liczenia cykli? ;) Jest szansa iż chłopaki z future crew zmieścili się i wtedy faktycznie mamy 30KHz sample rate czyli słyszalne pasmo ~15KHz :)
Pozostaje jeszcze sprawa dynamiki i jakości ich przetwornika ale o tym później. Faktem jest natomiast iż te kilka sekund sampla brzmi całkiem nieźle ;)
aha, przykład od TDC odpalajcie np. pod Altirra, Atari800Win nie będzie działać poprawnie :)
@kaz: nie obiecuję, ale mogę spróbować jakoś to poskładać, ale właściwie część spraw to tylko moje domysły więc nie wiem czy warto publikować. I tak właściwie to co to miałoby by być? o czym art? bo tutaj dyskutujemy o masie spraw bez większego ładu i składu ;)
dobrej nocy wszystkim życzę :)
seban 2009-11-25 02:24:06
nie dawało mi to spokoju... dokonałem konwersji sampla mab1 moim prymitywnym programikiem do formatu 8-bit raw... wczytałem do edytora audio... i co wyszło...
1) myliłem się co do sposobu interpretacji poziomu sygnału wejściowego przez Crystal Sound... właściwie daje taki sam efekt jak normalny przetwornik A/C. Zero po środku skali, tak jak powinno być. Widać sample które kiedyś oglądałem nie pochodziły z samplera crystal sound...i były na dysku z tym programem co zapodał TDC niejako przez przypadek.
2) częstotliwość odtwarzania którą uzyskuje ten program to około 27KHz, a nawet trochę mniej. Skąd wniosek? Przy odtworzeniu sampla z prędkością 31662Hz było go słychać duuużo za szybko... dopiero zejście do 27KHz dało efekt identyczny z tym który można było usłyszeń na real-atari :)
Charakterystyka częstotliwościowa przykładowego sampla w miarę liniowa w zakresie do 12KHz, DC offset trochę zwichrowany i próbka z mocnym clippingiem (tzn. przesterowana), i sampler wprowadzał pewną asymetrię sygnału :) w sygnale występowały także krótkotrwałe "szpile" (tzw. glitch). Ale jak na tamte czasy... i tak było nieźle ;)
seban 2009-11-25 02:40:24
i ostatnia sprawa, analiza statystyczna występowania każdej wartości w pliku "mab1" wykazała iż każda z wartości 0-15 występuje w pliku, a więc sampler wygląda na w pełni 4-bitowy, poniżej wyniki zliczenia każdej z wartości:
$0: 1341
$1: 2587
$2: 1433
$3: 3638
$4: 2058
$5: 7349
$6: 6436
$7: 8779
$8: 11897
$9: 11610
$a: 9649
$b: 8650
$c: 2745
$d: 4000
$e: 1813
$f: 4601
wniosek: nie doceniałem technologii z 1988 roku ;)
Tdc 2009-11-25 16:03:51
No proszę jaki ładny wykład ;)
No mi się właśnie wtedy również wszystko zgadzało, jednak nie miałem jak sprawdzić czy to jest 30 czy 27 (nawet CS nie miałem;) – tak czy siak jest dobrze ;)
Moja uwaga jest jeszcze taka, że pewne przekłamania do sygnału może prowadzać emulator (w końcu w emulatorach zwykle emulacja dźwięku to kulawa noga). Dlatego nie wszystkie parametry jakie podałeś mogą być w 100% pewne.
Co do Action! to oczywiście miałem na myśli maksymalną prędkość jaką da się osiągnąć (bez asm) dlatego nie miałem na myśli pełnej kontroli częstotliwości bo w momencie gdy CPU ma tyle roboty to jest to dość trudne. Jeśli miałbym zmieniać częstotliwość płynnie to tak samo jak w asm musiałbym docyklowywać itp.
Z wykorzystaniem sztuczek opisywanych przez Yosha i przeze mnie da się w jednej linii spokojnie wrzucić cztery wartości do rejestru POKEYa co daje ~60 kHz realnego sygnału samplowanego (trudno mi w tej chwili powiedzieć, czy da się w Action! dać 5 wartości; natomiast w teoretycznym przypadku gdy nie chcemy mieć sygnału z danych, tylko sygnał o maksymalnej częstotliwości to w Action! da się wyciągnąć jeszcze kilku krotność 60 kHz).
Nie jest też to taka sztuka dla sztuki, bo kiedyś napisałem dwukanałowy tracker w Action! który działał w całkiem przyzwoitej szybkości odtwarzania. W te wakacje Sikor i Miker namawiali mnie abym do niego napisał cywilizowany edytor i wypuścił. Jak rozumiem irwin byłby zainteresowany tematem ;)
PS. skoro ma powstać artykuł to ja się piszę na drugiego redaktora ;) W końcu temat ciekawy.
seban 2009-11-25 17:20:26
@tdc: ja nie odpalałem tylko na emu, odpalałem na real atari i na Altirra. Chłopaki w ASM ledwie 27KHz wyciągają a ty chcesz w Action! 60KHz i więcej? ;) Uważam to za nierealne nawet jakbyś trzymał 1 próbkę w jednym bajcie.
Weź także pod uwagę pasmo przenoszenia biednego LM358 który robi za mixer/wzmacniacz w torze audio Atari :)
Co do 60KHz i wielokrotności tegoż to już jest całkowicie nierealne. Zapominasz iż nawet przy wyłączonym ekranie antic wstrzymuje CPU (i to 9 razy w ciągu każdej linii skaningowej) aby wykonać dram-refresh. Odtworzenie 5 próbek w jednej linii rastra w ACT? Uważam to za nierealne :)
Nawet jakby było realne to jakich ilości pamięci potrzebujesz? Nawet jakbyś chciał wykorzystać ext ram to dochodzi czas aby przełączać banki. No chyba że raz na 16K i zachwianiem częstotliwości odtwarzania ;) Ogólnie możemy dyskutować tak w nieskończoność, ale postaram Ci się udowodnić iż to co chciałbyś osiągnąć jest nierealne, weźmy taki przykład:
sei
inc $d40e
lda #$00
sta $d400
clc
lda #$10
ldx #$1f
loop:
sta $d201
stx $d201
bcc loop
co co widzisz to najszybsza metoda wygenerowania sygnału prostokątnego na wyjściu POKEY-a. Efektywność niby jakieś 140KHz, ale nie chciałbyś widzieć kształtu fali poszatkowanej sygnałem HALT wystawianym przez ANTIC dla CPU. I tak jak sie spodziewałem coś możesz zobaczyć jednie bezpośrednio na pine audio out z POKEY-a, to co wychodzi z LM358 można określić jako szum i jakąś interferencję spowodowane przed dużą ilość harmonicznych występujących w tym sygnale... jednym słowem ledwie udało się uzyskać 60KHz *2 i to nie nadaje się do niczego, bo procka odtwarzająca sampel musi mieć nieco więcej instrukcji... i ja mówię o czystym ASM.
Swoje słowa mogę poprzeć oscylogramami i pomiarami dokonanymi na jeżeli będzie taka potrzeba, jednak to co widzę obecnie na oscyloskopie jest jedną wielką porażką jeżeli chodzi o kształt fali.
pozdrawiam
Seban
irwin 2009-11-25 17:26:20
irwin jest zainteresowany takowym trackerem ale pod dwama warunkami - nie może być w action, gdyż irwin jest zainteresowany trakerem pod Windows ;) oraz fajnie jakby potrafił zrobić kombo tj np jeden, dwa kanały sample a inne syneza Pokeya. To byłby przełom w rodzaju Graph2Fonta. Natomiast sam player/biblioteka pod Action - jak najbardziej.
Odnośnie owego sampla - ja też sprawdziłem i rzeczywiście jego jakość oscyluje około 26.8khz co jest wynikiem bardzo dobrym. Jedynem problemem jest tu zajętość takiej próbki oraz czy oprócz odgrywania jest jeszcze możlwość pokazania czegoś na ekranie.
seban 2009-11-25 17:32:58
@irwin: takie możliwości ma od wielu lat Music ProTracker ;), tyle że nie jest pod windows, a więc nie spełnia twoich wymagań ;). Za to bez problemu obsługuje 2 kanały digi+ 2 kanały syntetyczne. W przypadku 2 kanałów Digi jeden jest przeznaczony dla perkusji (stała prędkość odtwarzania), drugi natomiast gra sample ze zmienną częstotliwością.
seban 2009-11-25 18:33:32
@irwin: przy tej jakości sampla nia da się nic sensownego pokazać na ekranie... włączenie dma obrazu nawet w trybach o niskich rozdzielczościach spowoduje znaczące zniekształcenia dźwięku. Optymalną (w sensie jakości) częstotliwością odtwarzania przy włączonym obrazie i w trybie graficznym wydaje się być 15KHz. Gdy zaczynamy zabawę z trybami znakowymi robi się bardziej krytycznie i trzeba zejść do 7,5KHz. W trybach znakowych w pierwszej linii każdego rozkazu DL nie pozostaje za dużo cykli wolnych... procedura która miała by działać z częstotliwością 15KHz nie bardzo miałaby szanse na wyrobić się czasowo. Można to oczywiście zrobić ale wyraźnie słychać jak ANTIC przeszkadza CPU.
irwin 2009-11-25 18:34:36
Swego czasu na Atari powstały programy do kolorowania grafiki duszkami jak GED czy PowerGraph ale dopiero pojawienie się Graph2Fonta stworzyło tę lawinę obrazków jakie dotyczczas już w G2F zrobiono. Kiedyś pisałem do Rastera aby taką moźliwość wprowadził do RMTrackera ale nie był zainteresowany tematem.
Tdc 2009-11-25 20:43:57
He, he no proszę jednak się udało. Na dyskietce z moimi źródłami znalazłem backup drugiego pliku, dlatego podmieniłem plik ATR:
http://tdc.pigwa.net/Prg/Atari8bit/CrystalSnd1988.zip
seban: No widzisz, pokazujesz, że jednak nauka Action! na Atarionline jest potrzebna ;) bo jakoś wielu do dziś tego języka nie docenia.
Aby nie wdawać się w szczegóły to odsyłam tutaj do mojego dawnego tekstu:
http://atarionline.pl/v01/index.php?subaction=showfull&id=1241566556
&archive=&start_from=40&ucat=1&ct=nowinki
Przeanalizuj sobie moje wykresiki rastrowe prezentujące obciążenie CPU. Te źródełka zamieszczone w tym tekście są tak skonstruowane aby wskazać czas jaki potrzebuje Action! na wykonanie jakiś czynności. Jak widać Action! Wiele może zrobić podczas jednej linii rastra.
Jeśli Tobie mało to zrobię źródełka w Action! (+ skompilowane), które coś takiego robą z dźwiękiem czy z czymś innym. (nawiasem mówiąc w moim efekcie do demka które mam nadzieję ujrzy światło dzienne na następnych Głuchołazach – jest zrobiony fajny efekt w którym czysty Action! robi fajne rzeczy w 1 linii rastra)
> Weź także pod uwagę pasmo przenoszenia biednego LM358 który robi za mixer/wzmacniacz w torze audio Atari :)
Racja ;) ja tylko teoretyzowałem ;)
> Co do 60KHz i wielokrotności tegoż to już jest całkowicie nierealne. Zapominasz iż nawet przy wyłączonym ekranie antic wstrzymuje CPU
O niczym nie zapominam, chodzi mi o to że jeśli nie bierzemy kolejnych danych z RAM to wsadzamy sobie do rejestru cokolwiek (np. XOR) za maksymalną prędkością. Wtedy w asm da się duuuużo w 1 linii, a w Action! niewiele mniej. Jak nie wierzysz to mogę szybko napisać jakiś kod i podesłać.
Oczywiście cały czas są problemy o których piszesz – trzeba tu cyklować jak nic.
> Odtworzenie 5 próbek w jednej linii rastra w ACT?
No ja właśnie też pisałem, że nie jestem tego pewien, 4 wyjdą ale czy 5 to nie pamiętam tak dobrze wydajności małego Atari i Action! (w końcu dawno na nich nie programowałem – ostatnio tylko emulatory, którym nie dowierzam).
> Nawet jakby było realne to jakich ilości pamięci potrzebujesz?
Nie zrozumiałeś mnie odnośnie częstotliwości większych od 60 kHz to cytuję: „natomiast w teoretycznym przypadku gdy nie chcemy mieć sygnału z danych, tylko sygnał o maksymalnej częstotliwości to w Action! da się wyciągnąć jeszcze kilku krotność 60 kHz ”
czyli dane xor czy inne jak pisałem wyżej.
> to co wychodzi z LM358 można określić jako szum i jakąś interferencję spowodowane przed dużą ilość harmonicznych występujących w tym sygnale...
Racja dlatego pisałem wcześniej „w teoretycznym przypadku”
> Swoje słowa mogę poprzeć oscylogramami i pomiarami dokonanymi na jeżeli będzie taka potrzeba
Nie trzeba doskonale się rozumiemy ;)
irwin: „gdyż irwin jest zainteresowany trakerem pod Windows ;) ”
Nie piszę programów na tego trojana ;):)
Poza tym na win jest wiele trackerów następny nie jest potrzebny, choć chyba nie ma żadnego z emulacją POKEYa, choć kto wie czy nie dało by się tego zrobić w jakimś programie (np. w końcu instrumenty wirtualne są na co dzień na pecetach używane).
> fajnie jakby potrafił zrobić kombo tj np jeden, dwa kanały sample a inne syneza Pokeya. T
To realne, ale właśnie ja się za to brać nie będę, bo
1. staram się wykorzystać potencjał moich starych programów (a nie pisać zupełnie nowe)
2. Jak pisał saban – jest już parę takich
3. chcę aby max pamięci było dostępnej na sample (czyli prawdziwy tracker), a nie na dużo kodu z mojego punktu widzenia zupełnie zbędnego;)
pin 2009-12-01 20:50:06
.. miałem gdzieś kilka sampli wykonanych samplerem z /TA/;- na "ucho" brzmiały dobrze i raczej nie był to baton 3bit :) Jak wygrzebie, to podeśle.
MD 2010-05-31 22:19:17
Kilka słów o Crystal Soundzie wprost ze źródła. Urządzenie zaprojektowaliśmy i zrobiliśmy razem z kolegą, chodząc jeszcze do ZSEE W Bytomiu (ogólne założenia powstały w tramwaju). CS oparty był o UL1980 (linijka śwetlna), na wyjściach zamiast diod były odpowiednio dobrane oporniki. Jeżeli dobrze pamiętam, układ był przystosowany do sterowania 8 diodami więc w sumie odczytywane było 9 poziomów dźwięku (3 i "pół" bita). W pierwszej wersji CS podłączany był przez wejścia joysticka i można było uzyskać próbkowanie większe niż 20kHz. Kolejną wersję zrobiliśmy już w formie cartridża, ale "przetwornik A/C" pozostał na UL1980. Do tego dodawaliśmy zestaw 3 programów do obsługi. Potem Marek napisał chyba jeszcze jakiś dodatkowy program do tworzenia własnych dem gdzie wczytywało się tylko dźwięk, obrazek itp i można było automatycznie wygenerować własne demo, pewnie stad ileś różnych dem wykorzystujących tak digitalizowany dźwięk.
Wrzucilem jeszcze kompilacje Irwina - jego reczne klatki polaczone w jeden filmik z Atari XL/XE z muzyka podlozona z oryginalu. Tutaj filmik:
http://www.youtube.com/watch?v=2uZx5KBwz8A
Warto tez obejrzec wersje ST:
http://www.youtube.com/watch?v=LUI428lF5eo
Tdc 2009-11-18 01:51:46
Racja to demko robiło spore wrażenie, a ludzie je lubili. Ja może nie przepadałem za nim, ale kiedyś w GFA Basicu napisałem program który wyciągał tę muzyczkę. Byłem zaskoczony, że miała tak słabą jakość (nawet jak na ST czy małe Atari). Co ciekawe jakoś nikt tego nie zauważał przy oglądaniu tego niegdyś na np. Atari ST, widocznie treść filmiku wciągała tak, że na parametry nikt nie patrzył ;)
Tezz 2009-11-18 02:55:04
Excellent! Very well done, I remember the original ST demo well
marcin 2009-11-18 03:19:10
Jako miłośnik bałwana pozwolę sobie kilka linków dorzucić
strona oficjalna: http://www.thesnowman.co.uk/
wikipedia: http://en.wikipedia.org/wiki/The_Snowman
imdb: http://www.imdb.com/title/tt0084701/
google video (całość w 1 kawałku):
http://video.google.com/videoplay?docid=2067664373050394413
muzyka: http://stuff.fork.pl/walinkg-in-the-air/
sikor_ 2009-11-18 07:37:37
Całkiem przyjemnie wyszło, pamiętam to demko z STE.
========KAZ, nadal moje hasło nie działa do komentowania
Emu 2009-11-18 09:10:51
Kaz, w pliku "pakiecik" brak wersji dla Amigi?
tbxx 2009-11-18 09:14:08
reklamówka z motywem snowman http://www.youtube.com/watch?v=9wMs5bUkjO0
Ciekawski 2009-11-18 09:29:16
"Klatki są w trybie znakowym (160x96 piksli), piksel proporcjonalny 2x2 hires (GRAPHICS 13 BASIC-a)"
- no ciekawe, a jak uzyskac taki tryb gfx w G2F (jesli ktos chcialby zmontowac wlasna historie wiec to co opowiadacie nie byloby calkowita "sztuka dla sztuki") ??? ;o
Kaz 2009-11-18 10:12:19
Sikor - piszesz to w kolejnym komentarzy i tam Ci juz wyjasnialem: wszystkie hasla zostaly zmienione po wlamie do systemu nowinek, jezeli chcesz nowe haslo to napisz jakie i przyslij je do mnie.
Emu - racja, wersji Amigi w pakieciku nie ma, napisalo mi sie z rozpedu, sorki.
Marcin, Tbxx - dzieki za dodatkowe linki.
tbxx 2009-11-18 10:29:07
Z tego co widzę to w demie na ST zostały użyte klatki z filmu "the Snowman", do którego linka podał Marcin. Czy używając do konwersji oryginalnych klatek z filmu zamiast tych z ST efekt mógłby być jeszcze lepszy?
rako 2009-11-18 11:15:47
Czepiacie się, jest Bardzo Fajne!!! i bardzo się cieszę, że nareszcie jest śnieżny człowiek na Maluszku.
seeman 2009-11-18 11:31:10
@tbxx
Link ktory podal Marcin zawiera film w slabszej jakosci niz ten ktorym Irwin sie posluzyl - gdyz jak poczytasz dokladnie tekst, to zobaczysz, ze Irwin wlasnie tak zrobil jak piszesz: zrobil wersje bazujac nie na klatkach z AtariST, a z filmu z Youtube, ktory ma jakosc lepsza niz ta z podana przez Marcina na Google.
Całe wideo z tej właśnie wersji Kaz umiescił w pierwszym komentarzu:
http://www.youtube.com/watch?v=2uZx5KBwz8A
Poszczegolne jej czesci: 5 plików xex, znajduja sie w pliku:
http://atarionline.pl/pliki/irwin_thesnowman.7z
ktory Kaz podal na koncu artykulu.
Caco 2009-11-18 12:43:42
Jak dla mnie rewelacja. Kawał dobrej roboty. Gratulacje za dobrnięcie do końca tematu !
mono 2009-11-18 13:37:27
Bardzo fajne demo - gratulacje Irwin i TeBe. Demo zachowało swój klimat, nawet mimo niewielkiej ilości kolorów.
Słyszałem "Walking in the air" w wykonaniu Tarji z Nightwisha, ale nie wiedziałem, że to jest motyw z filmu. W linkach podanych przez marcina jest zresztą też ta wersja.
Nie wiem czemu, ale u mnie (Ubuntu 9.04 x86_64, FireFox 3.0.15) wideo z youtuba umieściło się na obrazkach a nie pod :(
Kaz 2009-11-18 13:42:17
Mono - zapewne gdzies sknocilem znaczniki htmla, jak Scalak znajdzie czas to pewnie rzuci okiem.
mono 2009-11-18 13:47:07
Już jest ok (to jakieś humory mojego komputera). Irwin - trzeba przyznać, że Twoja ręczna kompresja jest BARDZO DOBRA! Tylko niewiele odstępuje od wersji wyjściowej w g2f.
F6 2009-11-18 13:50:38
:)
http://www.worldofspectrum.org/infoseekid.cgi?id=0004609
Kaz 2009-11-18 13:59:56
"Sinclair User's" review:
"THE SNOWMAN, for the 48K Spectrum, is a game based on the best-selling book of the same name by Raymond Briggs. It is based loosely on some of the action in the book but it centres on the building of the snowman. It should appeal to young children because of its non-violent nature.
To build the snowman you have to collect snow and avoid the flames which will chase you so that you can turn it back into water.
In some ways the game is like Jet-Pac, from Ultimate, as there is a drop site on the left of the screen which you must reach to mould the snowman's body and dress him.
There are four stages to each round. The first is to collect the snow, the second to put on the features, the third to dress the snowman and the fourth to collect ice cubes to prevent him melting. Once all of those phases have been completed you will move to round two and a different screen layout.
There are two ways of winning points. You could forget about building the snowman at the first stage and collect objects such as crackers, stockings and Christmas trees. That will boost your score considerably, so long as you do not fall from the ice structure. If you do, or your energy level is depleted too much, you will fall back into bed.
The alternative is to build the snowman but risk the wrath of the sleep monsters, which can only be combated using the special alarm clocks.
The game is attractive and is a change from the violence of Space Invaders and the like."
xxl could convert it ;)
_rocky 2009-11-18 14:06:45
tebe:
Ja bym w tej wersji 4 kolorowej podmienił kolory szare na odcienie brązu.. animacja nabrała by "ciepła", które emituje z oryginału..
glowas11 2009-11-18 18:23:38
Powiem tak znam to demnko i tez mi sie mzyło aby zagościło na Atarce 8 bit-owej . TEBE jesteś wielki i żyj na sto lat bo jeśli odpukać coś ci się stanie to bedzie to ogromna strata dla narodu polskiego .
Wielkie gratulacje panowie .
PS. przyłączam się rocky też uważam że odcień brązu nada klimatu .
Jacques 2009-11-18 20:39:10
Trochę bardziej slideshow niż animacja (cóż, nominalne 1,79 MHz ;-) , ale i tak kawał dobrej roboty, dzięki tebe! W połączeniu z odpowiednią muzyką ma naprawdę dobry klimat, taki melancholijny... :-)
tbxx 2009-11-18 21:32:08
74 klatki/2.30min demo, ciężko z tego zrobić płynna animację. Po za tym płynność porównywalna do tej z mocniejszych komputerów. Szkoda że tak późno - znalazłem "The Snowman" w wersji divx 512x384, bez porównania ładniejsza wersja od tej z youtube...
_rocky 2009-11-19 15:47:06
tbxx:
A jest gdzieś udostępniona ta ładniejsza wersja...
W sumie fajna bajka dla dzieci na święta..
tbxx 2009-11-19 19:08:37
np tu:
http://www.btmon.com/Video/Movies/The_Snowman_1982_Cartoon.torrent.html
CharlieChaplin 2009-11-20 00:48:53
Well,
here you can find/download a different snowman animation, I did many months ago:
http://www.atariage.com/forums/index.php?app=core&module=attach§ion=att
ach&attach_id=145012
The animation was done with tip animator 2.7 or 2.8 and has some flicker, it requires a min. of 128k RAM to run... -Andreas Koch.
P.S.: I cannot find the source (GIF-animation) anymore. otherwise I could do a better animation of it nowadays...
CharlieChaplin 2009-11-20 00:52:58
Hmm,
above link does not work (the copy & paste did not work correct, don`t know why). So simply use this link:
http://www.atariage.com/forums/topic/153666-snowman-demo-atari-st-original-on-lit
tle-atari/
and then goto post nr. 5 to download my snowman animation (which is for adults only)... -Andreas Koch.
mono 2009-11-20 10:49:47
A tak nawiasem - czemu nie przytrzymaliście tego na któreś party? Np. na Forevera 2010?
Jacques 2009-11-20 12:18:41
Może dlatego, że grudzień za pasem? ;-)
irwin 2009-11-21 08:44:52
Przede wszystkim dzięki wszystkim za pochwały - oczywiście idą one na konto Tebe'go gdyż to on wszystko zrobił.
@Marcin, tbxx - dzięki za linki
@Emu - no właśnie nigdzie nie można znaleźć wesji na Amige a na 120% takowa jest bo naocznie ją widziałem na początku lat 90tych i to na mojej A500 ;) Ktokolwiek widział? ktokolwiek wie?
@Ciekawski - być może Tebe kiedyś taki tryb w G2F, jednak kiedy i czy w ogóle to pytanie do niego. Są sytuacje że on coś robi bo ktoś chce a potem nikt z tego nie korzysta - vide AIS.
@TDC - odnośnie jakości sampla z wersji AtariST - ja również jestem ową jakością zaskoczony tyle że na plus tzn że jest tak dobra. Musisz pamiętać że to były lata 80te i ówczesne przetworniki DAC nie były takiej jakości jak dziś i to zarówno po strnie samplera jak i na AtariSTE. Sam pamiętam jaka była przeogromna różnica jakości tego samego sampla odtwarzanego na Sound Blasterze 2.0 a na SoundBlasterze 16.
Po drugie musisz wziąć też pod uwagę że nie było też takich programów jak Cooledit czy Audiocity które pozwolą na wygładzenie czy usunicie szumów.
Po trzecie dyskietka 720kb nie jest z gumy i mając już plik 600kb z danymi video ciężko ładować tam sampel o większej liczbie khz.
Sam NeHe autor wersji pecetowej był zaskoczony jakością sampla z AtariST, o czym mi też pisał.
@tbxx -lepsza jakość filmu niż ta z youtube nie jest już potrzebna gdyż w ostatecznym rozrachunku na Atari i tak wszystko sprowadzi się do max 160x240.
@Mono - dzięki! trochę czasu nad tym spędziłem. O dacie zadecydował autor czyli Tebe. Trzymanie tego do Forevera nie byłoby czymś dobrym gdyż raz - to demko jest w temacie raczej świątecznym, 6-grudniowym, a dwa na Forever pewnie pojawią się "normalne" dema.
Na zakończenie mała uwaga dla wszystkich: jeśli jakiś koder Atari na nasze zapytanie z miejsca machnie "tego nie da się zrobić" to nie należy tego traktować poważnie. ;) Na Atari a zwłaszcza "małe" Atari da się wszystko ;)
Tdc 2009-11-22 21:20:56
irwin: no niestety nie mogę się z Tobą zgodzić. Na ST w dobrych demkach było minimum 30 kHz (a w jeszcze lepszych - jeszcze więcej) (mam na myśli Yamaszkę), a na małym atari z Crystal Sound też tyle dało radę. Dlatego 8khz to naprawdę mało - może powiem inaczej - trudno znaleźć na ST demko z tak niską częstotliwością (na małym Atari w tamtym okresie było ich sporo, różne madonny itp.).
Co do pecetów to jest to odrębna dziedzina, bo wspomniane karty SB 2.0 to początek wychodzenia pecetów z ciszy, który nastąpił jako ostatni (w końcu nawet Apple miały dźwięk). Dlatego tę epokę dźwiękowego kamienia łupanego pozostawmy na następny raz;)
irwin 2009-11-22 21:59:58
Ok, więc sprawdzmy: podaj mi choć jeden tytuł demka na ST w którym jest sampel minimum 22 sekundowy o parametrach jak piszesz tj 30khz.
tdc 2009-11-23 03:22:53
Ja takiego nie znam, ale z reguły nie oglądałem/zgrywałem demek w których leci sama muzyka ;) Natomiast masz tu wiele racji bo zwykle w demkach było robione coś na kształt modułów. Dlatego być może są takie przykłady ale ja się do demek na ST nie włamywałem (miałem ST dość krótko). Może ktoś inny poda jakiś tytuł, mi przychodza do głowy różne demka, gdzie na słuch wiem że jest sporo ponad 20 kHz, ale nie wiem jak zostało to technicznie zrealizowane.
Natomiast w STE często w demkach leciał prosty sampl, ale były to często częstotliwości związane z trybami pracy układu STE czyli głównie 25 Khz. Podobnie jest w najnowszym bardzo fajnym demku.
Jeszcze tak na marginesie dodam, że ST nie miało dźwięku 8 bitowego, dlatego przy 4 bitowym zapisie 30 kHz w 22 sek to 330 kb. w demku jest to wielkość zupełnie akceptowalna.
sikor 2009-11-23 06:49:25
@TDC, przykro mi, ale lejesz wodę. Ani z Ciebie programista, ani... Tylko gawędziasz, niestety - muszę tu przyznać rację KMK, bo cała dyskusja na atariarea, jak i Twoje wypowiedzi tutaj świadczą tylko o tym. Ja widziałem, ja zrobiłem, ja się ze... (a nie, może to i zrobiłeś). A proste pytanie: daj link/przykład i Ty ani be, ani me. Wot przykrość, czyżby rzeczywistość mijała się z Twoimi gawędami?
Prosty przykład z kilku komentarzy powyżej:
TDC: [..]irwin: no niestety nie mogę się z Tobą zgodzić. Na ST w dobrych demkach było minimum 30 kHz (a w jeszcze lepszych - jeszcze więcej) (mam na myśli Yamaszkę), a na małym atari z Crystal Sound też tyle dało radę. Dlatego 8khz to naprawdę mało - może powiem inaczej - trudno znaleźć na ST demko z tak niską częstotliwością (na małym Atari w tamtym okresie było ich sporo, różne madonny itp.).[,,]
a zaraz potem:
TDC: [..]Ja takiego nie znam, ale z reguły nie oglądałem/zgrywałem demek w których leci sama muzyka ;) Natomiast masz tu wiele racji bo zwykle w demkach było robione coś na kształt modułów. Dlatego być może są takie przykłady ale ja się do demek na ST nie włamywałem (miałem ST dość krótko). Może ktoś inny poda jakiś tytuł, mi przychodza do głowy różne demka, gdzie na słuch wiem że jest sporo ponad 20 kHz, ale nie wiem jak zostało to technicznie zrealizowane.
Natomiast w STE często w demkach leciał prosty sampl, ale były to często częstotliwości związane z trybami pracy układu STE czyli głównie 25 Khz. Podobnie jest w najnowszym bardzo fajnym demku.[..]
Więc jak to jest, minimum 30 czy 22Khz? Wyciągałeś muzykę z dem czy nie, jak piszesz wcześniej? Masz słuch muzyczny, że rozpoznajesz minimum 20KHz, czy nie masz? Od kiedy Crystal Sound dawał radę z 30KHz, bo ja o takiej możliwości )CS na małe Atari) nie słyszałem?
Prosimy Tomku o szczegółowe wyjaśnienia, jak nie znasz - za przeproszeniem, nie pieprz głupot, bo to już się robi nudne.
irwin 2009-11-23 11:18:00
@TDC
Wyjaśnijmy tę sprawę po kolei ;)
Specjalnie zapytałem Cię o podanie choć jednego tytułu demka z minimum 30khz aby zwrócić Ci uwagę że: realne parametry sampla tj liczba bitów i częstotliwość w hz to coś innego od miksowania modułu w pamięci i następnie odgrywania go przez układ dzwiękowy komputera.
"The Snowman" w oryginale ma dzwięk 8khz (8000hz)
Demka na AtariST z uwagi na brak sprzętowego układu jakim jest Paula w amidze odgrywały moduły-muzyczki poprzez miksowanie 4 lub więcej kanałów, niejako można to nazwać wirtualnym samplowaniem w pamięci, (przynajmniej ja to tak bym nazweał ale koderem nie jestem detali nie znam) w określonej liczbie khz poprzez procesor główny 68000, a następnie całość była wysyłana na już prawdziwy układ grający. Liczba khz zależała od liczby kanałów, i innych czynników ale głównie od ilości czasu jaki koder jest w stanie poświęcić na procedure grającą kosztem efektów wizulanych.
Moduł muzyczny składa się z 4 lub więcej scieżek z notacjami które zawierają jaki dzwięk o jakiej głośności, i jakiego instrumentu-sampla ma być zagrany.
Pytanie nr 1: Czy wiesz jaka jakość sampli dominowała (praktycznie w 95%) w modułach z lat 86-94? Tak aby porównać je do "tak słabej jakości" jak piszesz sampla z The Snoman?
odpowiedź brzmi: około 8khz (a dokładnie 8363hz a to z uwagi "MOD samples generally use a sampling rate of 8363Hz for a C in the second octave" oraz specyfike układu Paula w Amidze)
Pytanie nr 2: Czy 8.0khz w Snowman jest znacząco gorsza od 8.3khz w 95% modułów z tamtych lat?
Pytanie nr 3,4,5 i 6: Załóżmy że zamiast sampla w Snowman mamy moduł który ma jedną scieżkę, jeden pattern i jeden sampel 8khz o długości 22 sekund. Bez problemu można taki moduł zrobić w dosłownie minutę. Całość miksowana jest jak w innych demkach z AtariST powiedzmy niech będzie jak piszesz w 30khz. Czy jakość sampla nagle wzrośnie do 30khz? Czy obrazek 16 kolorowy z AtariSt oglądany na PC będzie miał znacząco lepszą jakość? Czy 2 zł włożone do miejsca gdzie się trzyma 5 zł'ówki stanie się 5złotówką? ;) Czy wyciągałeś sample-instrumenty z owych modułów z atarowskich demek i czy nie zdziwiło Cię że praktycznie wszystkie mają sample w okolicach 8khz?
Tak więc nie należy mylić samego sampla z procedurą odgrywającą bo to prowadzi do mylnych stwierdzeń. Może być też tak: że sampel np 22khz może brzmieć ładniej od modułu miksowanego w np 35khz z samplami 8khz. To są dwie odrębne sprawy.
Zaś jeszcze co do samego sampla - powtórzę: musisz pamiętać że to były lata 80te i ówczesne przetworniki ADC i DAC nie były takiej jakości jak dziś. Dziś mając użyteczne programy o których pisałem i bardzo dobre jakościwe samplery można zrobić plik 8khz który będzie czystszy. Tyle że to dziś a nie w 1987 roku. Po drugie przypomnę o tym że dyskietka nie była z gumy i mając 500-600kb czy to video czy to innych danych (jeśli mówimy od demkach) to koderowi trudno byłoby poświęcić całą masę kb na samą muzykę. A trzeba też pamiętać że i pamięć w samym kompie była ważna. To były przecież lata 80te. Wszystko ma swoją cenę, trzeba iść na kompromis. To dlatego demko zamiast choćby animacji 5 fps ma jedynie 74 klatek na 84 sekundy czyli średnio mniej niż jedna klatka na sec. (w wersji z AtariST) Tego też filmem nie nazwiemy, ale mimo wszystko się spodobało. Zawsze trzeba patrzeć z poziomu realnych możliwości sprzętu w danym okresie i akceptowalnych, dostosowanych do posiadaczy tego sprzętu rozmiarów i wymagań programu czy demka. Dlatego min. wersja na małe Atari chodzi na 320kb.
ps.
- A przy okazji: co to jest te Crystal Sound?
- możesz, lub ktokolwiek inny (ja nie znam się na AtariST i ichnej scenie) podać jakieś demka na AtariST gdzie leci zdigitalizowana muzyka? (nie musi być to demko z efektami wystarczy one screen i sama muzyka)
seban 2009-11-23 11:49:14
gwoli ścisłości, YM2149 miało 5-bitowe DAC-e, więc bez problemu odtwarzało się na nim 5-bitowe sample. Dodać też trzeba iż YM2149 miało logarytmiczną skalę głośności. Można było również wykorzystać trik z sumowaniem głośności 3 kanałów co dawało jeszcze większą rozdzielczość bitową... były playery które miksując 3 kanały uzyskiwały rozdzielczość sampli na poziomie 8-bit. Także YM2149 w połączeniu z motorolą 68k ma naprawdę duże możliwości. A to ile KHz dało się wyciągnąć to zależało tylko od tego co chcemy oprócz odtwarzania sampli robić jeszcze.
irwin 2009-11-23 12:00:18
@Seban - dzięki za info. To by tłumaczyło dlaczego w demku użyty jest sampel 8bit. Po drugie teraz 22 sekundy w 30khz jak chce TDC zajmuje 660kb co wyłącza zastosowanie tylko jednej dyskietki ale przede wszystkim uniemożliwiałoby uruchomienie demka ST z 1mb ram. A w roku 1987 większe ilości ramu niż 1mb były raczej rzadko widziane u użytkowników ;) Osobiście myślę że nawet liczba tych z 1mb nie była zbyt duża.
seban 2009-11-23 12:22:11
W przypadku Atari ST bez problemów może czytać dane w locie z FDD, dekompresować również w czasie rzeczywistym i odtwarzać taki sampel na YM2149... ale w tamtych czasach chyba nikt o tym nie myślał ;)
irwin 2009-11-23 12:46:36
Naturalnie masz rację, dzwięk pewnie dałoby się skompresować jakimś prostym algorytmem stratnej kompresji, także i video - są wszak nieskompresowane. Jestem pewniem że dziś dałoby się zrobić owo demko zarówno z większą ilością klatek jak chodzące nawet na 512kb. Tylko 1987 rok to raczej pionierskie lata nie tylko dla AtariST ale i standadów kompresji audio-video. I oceniając Snowmana należy mieć na uwadze właśnie owe pionierskie czasy, a porówywanie czy to jakości sampli czy video powinno odbywać się w korelacji do istniejących wówczas demek, sprzętu, narzędzi, rozwiązań itd. Dziś niektórzy Atarowcy zapominają o tym, pisząc np. że dana gra wygląda i działa lepiej niż jej pierwowzór z końca lat 80tych z C64.
seban 2009-11-23 12:52:40
dlatego właśnie napisałem że w tamtych czasach nikt o takich technikach raczej nie myślał. Może to śmieszne jak przyznam się iż jak zobaczyłem to demko na ST to mnie w tamtych czasach zatkało... niestety na ST nie było mnie stać :) Tak więc jak najbardziej doceniam twórców tego dema :)
tdc 2009-11-23 14:56:08
Irwin i seban: dzięki za rzeczowe opisy. Ogólnie nie zaskoczyliście mnie i nie chcę tu z Wami dyskutować bo się zgadzamy.
> liczba bitów i częstotliwość w hz to coś innego od miksowania modułu w pamięci i następnie odgrywania go przez układ dzwiękowy komputera.
Racja tylko, że w demkach zapewne każdy programista robił to po swojemu. Ja to sobie wyobrażam, że były to znacznie uproszczone mechanizmy niż moduł, bo po pierwsze mało było na ST we wczesnym okresie dobrych algorytmów do modułów (były żenujące), a po drugie koderom zależało na wydajności.
W dobrych demkach, koderzy starali się odtwarzać dźwięk o najlepszej jakości, co nie musi się równać z jego parametrami (musiał brzmieć dobrze), czyli sampl poniżej 15 kHz odpadał. Do tego najłatwiej wtedy jest właśnie odtworzyć długi sampl niż bawić się w bardziej skomplikowane playery na kilku kanałach (co jednak nie wykluczam że pojawiało się – np. w niektórych częściach demek itp.).
> Tego też filmem nie nazwiemy, ale mimo wszystko się spodobało.
I ja jako osoba niezwykle pedantyczna w tym względzie, muszę jednak przyznać że jest to piękne. Jest to pewien artyzm, aby słabymi środkami osiągnąć coś co jest dobre i zapada w pamięci.
> A przy okazji: co to jest te Crystal Sound?
To jest taki program i sprzęt.
http://atariki.krap.pl/index.php/Sampler
W przypadku programu to jest to jeden z tych, który rozwala emulatory :):) Bo emulatory zakładają, że małe Atari potrafi odtworzyć maksymalnie ~15 kHz odtworzenie większej częstotliwości np. tym programem kończy się katastrofą)
> możesz, lub ktokolwiek inny
Jak już wcześniej pisałem słabo znam te demka muzyczne. Ale tak na szybko podam kilka przykładów prawdziwych demek (które mam nadzieję że są z lat 80 – choć pamięć moja już nie ta ;) ):
1. tu jest fragment European Demo, które na pewno jest z lat 80, jednak z tego co pamiętam to tam była dość niska jakość sampli (10- 15 kHz) ale to tak z pamięci.
http://www.youtube.com/watch?v=mhzqQVb4NxU
2. ULM
Niestety nie znalazłem właściwych fragmentów tego demka, ale mam je na dyskietce, więc jak ktoś jest zainteresowany to mogę podesłać.
a) fragment demka, nie wiem ile tu jest kHz, bo nie pamietam oraz w tym efekcie programista mógł coś kombinować aby mieć więcej czasu CPU:
http://www.youtube.com/watch?v=mHAYQZwApn4
Nawiasem mówiąc w tym filmie prawie nic nie widać...
b) Tu widać tylko ułamek sekundy screenu w czasie wczytywania demka, gdzie leciał sobie sampl. W menu demka też było dużo długiej muzyki na samplach.
http://www.youtube.com/watch?v=W8Th7QQ-u1I
3. Szukałem jeszcze jednego starego demka z ST gdzie były jakieś muzyczki na samplach, ale nie pamiętam tytułu i nie znalazłem go w necie. Nawiasem mówiąc nie mam go na ST i od wielu lat go szukam.
4. Lost boys – to nowsze demko
http://www.youtube.com/watch?v=KOPS-dyNDnk&feature=related
To demko leciało na pierwszej Grzybsoniadzie. To jest najprawdopodobniej najprawdziwszy moduł w jednym z najlepszych odtwarzaczy jak na ST (pojawia się w tym demku też w innych częściach).
5. Przypadkowe znalezisko z netu:
http://www.youtube.com/watch?v=je2EgYY5IeE
seban: „Można było również wykorzystać trik z sumowaniem głośności 3 kanałów co dawało jeszcze większą rozdzielczość bitową...”
No tak ale demka się raczej w to nie bawiły. Pamiętam jakiś odtwarzacz z lat 80, prosty tekst na czarnym tle (jeśli mnie pamięć nie myli), który potrafił właśnie osiągnąć około 40 kHz na Yamaszce i inne fajne rzeczy.
Irwin: „Po drugie teraz 22 sekundy w 30khz jak chce TDC zajmuje 660kb co wyłącza zastosowanie tylko jednej dyskietki”
Skoro sam piszesz że RAMu za dużo nie było to tym bardziej każdy koder myślał o samplach 4 bitowych a nie 8 ;)
Sikor... no nie ! Znowu masz urlop... znowu mnie zaczepiasz... Nie mogę z Tobą dyskutować bo już to wielokrotnie przerabialiśmy jak to się skończy. Jeśli zrozumiesz na czym polega różnica w oprogramowaniu ST i STE, przeczytasz moją wypowiedź jeszcze raz to ją zrozumiesz. Co do programów to napisałem (chyba) 1 program wyciągający muzykę z „bałwanka”, natomiast demek na ST jest tyle, że moje jedno wyciągnięcie nie kwalifikuje się do określenia „wyciągałem muzykę z dem ST” (za krótko miałem ST aby się w to bawić).
irwin 2009-11-23 17:38:29
@TDC - dzięki za przykłady, problem w tym że we wszystkich zamiast sampli jako głównej muzyki dema są moduły z samplami oczywiście 8khz. Owszem czasami wśród przerywnikach które zapodałeś na youtube są grane same sample ale:
- po pierwsze trwają one po 3-4 sekundy a to trudno uznać za scieżkę dzwiękową
- po drugie wbrew temu co piszesz we wszystkich owe sample mają po 8khz (jak to sprawdzić? - wgrywasz steem i gdy jest grany ów sampel, zapisujesz stan pamięci do pliku, następnie ów plik wgrywasz do edytora audio - np Audiocity czy Cooledit, 8bit unsigned, na przebiegu widać charakterystyczne dane dzwięku, wycinasz je lub na odwrót kasujesz śmieci, następnie dajesz reverse bo sampel jest obrócony i voila mamy sampla. - przyklad: http://rapidshare.com/files/311123392/aa__8_.001.wav.html)
Osobiście sądzę że owe choćby 20khz sample używane jako scieżka dzwiękowa można włożyć między bajki ;) Tak więc pozwolisz że niezgodzę się z Twoim "W dobrych demkach, koderzy starali się odtwarzać dźwięk o najlepszej jakości, co nie musi się równać z jego parametrami (musiał brzmieć dobrze), czyli sampl poniżej 15 kHz odpadał." gdyż takiego demka gdzie choćby grany był samplel 15khz jako scieżka dzwiękowa dema nie znam. Chyba że mi go podasz(a zaczynaliśmy od 30khz ;) teraz moje wymagania spadły;) tylko warunek jest taki, musi mieć choć 15khz i stanowić scieżkę dzwiękową dema tj minium ze 20 sekund ;)
Co do sampli 4bit - spróbuj sobie przerobić mp3 na np 4bit 30khz i 8bit 15khz i powiedz który lepiej brzmi. Wiesz mi ja wolę 8bit 8khz ze Snowmana niż 4bit 30khz gdyż różnica jakości na korzyść 8bitów jest duża.
irwin 2009-11-23 17:41:10
Aha i dzięki za info o tym Crystal Sound - nie słyszałem o tym, fajna zabawka. Szkoda że tak mało w Atariki o tym, chętnie bym się więcej dowiedział.
seban 2009-11-23 18:47:02
a propos crystal sound: jeżeli mówimy o samplerze crystal sound dla małego Atari to mogę rzucić nieco światła na sprawę, natomiast jeżeli istniało coś takiego dla atari 16-bit to niestety się nie orientuję ;) uświadomcie mnie o którą wersję wam chodzi to będę mógł się wypowiedzieć lub nie ;)
irwin 2009-11-23 19:09:30
Mnie chodzi o wersję dla małego Atari. I ogólnie możliwości małego Atari w zakresie odtwarzania sampli. Czy dałoby się bez wyłączenia ekranu, z wyświetlanym prostym screenem i scrollem odtworzyć:
- sampel o jakich parametrach
- 3-4 kanałowy moduł z Amigi i o jakich parametrach (bity i khz)
sikor 2009-11-23 19:58:29
@irwin, co do crystal sound i jego możliwości: http://atari.fandal.cz/detail.php?files_id=223 - ale było tego więcej (z 10-15 części ogólnie, część z nich w nazwie nie miała "crystal sound").
Co do odtwarzania sampli: tak, można. O szczegóły uderz do Sebana, ja nie wytłumaczę niestety co i jak, bo ja zwykłym userem jego procki jestem (demo ASCII GIRL - ale tam akurat przy samplu wyłączony ekran jest).
Co do modów: jest MOD Player, ale on chyba md8 odtwarza (o ile dobrze pamiętam), same mody można tworzyć bodajże w Future Composerze (nie pamiętam jakie ograniczenia), a dość dobrą jakość daje NeoTracker Epi-ego (ale modów nie zapisuje, tylko odtwarza). O ile pamiętam - w małym Atari jest do 4 kanałów (mogę się mylić) i ograniczona wielkość sampla (dość mocno), ale ponieważ nie jestem muzykiem - nie powiem jaka dokładnie (trza poszukać info).
irwin 2009-11-23 21:12:06
@Sikor - dzięki! za linka i za info. Ciekawi mnie czy można by zrobić proste demko z prostymi efektami ale z muzyką z trackera bądź muzyką 2 kanały synteza Pokey+1 kanał digi.
seban 2009-11-23 22:10:13
@irwin: moduł przy włączonym ekranie + scroll:
http://atari.fandal.cz/detail.php?files_id=970
jakoś: 4-bity na kanał, player bez tablicy umożliwiającej osiągnięcie precyzji 5-bit. Nie brzmi to jakoś rewelacyjnie. Ale dało się coś zrobić jak widać. Ile KHz wyszło nie pamiętam... jak się nie chwali SoTe w scrollu to trzeba by było policzyć. Procka odtwarzająca nie jest jakoś ekstremalnie optymalizowana, dało by się wycisnąć więcej. Coś mi się kojarzy że udawało się wycisnąć 3.5 do 4KHz.
Teraz o crystal sound dla 8-bit atari. To co pokazał Sikor, to chyba sztandarowa produkcja wykonana programem dołączonym do samplera crystal sound. Takich produkcji było bardzo dużo... swego czasu produkował je Marek Górecki (EGR General Programming a.k.a. Górecki Productions). Program dołączony do samplera umożliwiał wczytanie sampla, obrazka, zestawu znaków oraz wpisanie tekstu scrolla. Następnie ten program zapisywał wszystko jako plik wykonywalny i w ten sposób powstawały tego typu produkcje. Widziałem ich na pewno ponad 5 szt.
Co do strony sprzętowej crystal sound (będę go nazywał CS w skrócie) to na tamte czasy była to fajna zabawka i zrealizowana w dość śmieszny sposób od strony sprzętowej. Domyślam się iż w czasach gdy powstawał CS kupno w Polsce taniego przetwornika A/C graniczyło z cudem. Twórcy rozwiązali ten problem używając polskich układów scalonych UL1970 lub UL1980. Były to układy stosowane w diodowych wskaźnikach wysterowania (UL1970 - punktowy, UL1980 - tzw. linijka śwetlna). Całość była podpinana do portu joysticka.
Większość z tego co napisałem to moje domysły ponieważ nigdy nie posiadałem CS w swoich rękach a to co piszę wnioskuję na podstawie kodu programu do CS który miałem okazję kiedyś analizować. Rozwiązanie proste i skuteczne jednak proponuje obejrzeć sample zrobione tą techniką.
Upraszczając do bólu w przypadku normalnego przetwornika A/C robimy tak iż jego punkt pracy ustawiamy w połowie zakresu pomiarowego i mamy możliwość pomiaru zarówno napięć w zakresie dodatnim jak i ujemnym. Pomijając tu format zapisu sampli (ze znakiem lub bez) mamy możliwość uzyskania wartości np -8 do +7 (przy założeniu iż mamy do czynienia z 4 bitowym A/C), lub gdy przetwornik pracuje tylko przy dodatnich napięciach wejściowych otrzymujemy wartości od 0 do 15 (w tym wypadku cisza na wejściu będzie reprezentowana przez wartość 8). W przypadku UL1970/UL1980 w zależności od napięcia podanego na wejście układu układ uaktywniał kolejne wyjścia proporcjonalnie do poziomu sygnału wejściowego. Mając 16 wyjść z układu można było pokusić się o konwersję 4-bitową jednak to wymagało enkodera '1 z 16' na system binarny... nie wydaje mi się aby CS taki posiadał. Sądząc po kodzie który widziałem w tamtych czasach... wyjścia UL1970/80 były podpięte bezpośrednio pod porty Joystick-ów a konwersji dokonywał software. Także CS mógł określić maksymalnie 8 (lub 10 poziomów jeżeli by wykorzystać wejścia trig_in z GTIA). Nie pokrywało to pełnej 4-bitowej rozdzielczości oczywiście co dawało niepełną dynamikę. Również reprezentacja poziomu była mocno niewierna ponieważ mieliśmy tu do czynienia z pewnym uśrednieniem amplitudy sygnału wejściowego ... nie wiem jak to dokładnie napisać... ale złapiecie jeżeli obejrzycie kształt sampla z demek typu CS.
Wiem iż powstał w późniejszym okresie Crystal Sound II, niestety na jego temat niewiele wiem, nie widziałem ani samplera ani softu do niego także nie mogę się wypowiadać.
Również informacje o CS traktujcie z pewnym dystansem. To co opisuje działo się w latach 89-90 i część wniosków to moja własna dedukcja, mogę się mylić lub po prostu moje domysły mogą być błędne.
Przypomniało mi się iż pomysł z wykorzystaniem UL1970/80 był opublikowany lata po powstaniu CS w Tajemnicach Atari... pamiętam iż w gdy zobaczyłem ten art w TA, uśmiałem się że ktoś wpadł na ten sam pomysł parę ładnych latek później ;)
Być może znajdę chwilę czasu i wytnę sample z produkcji crystal sound i pokażę wam na czym polega różnica w symetrii sampli. To powinno unaocznić moje powyższe wypociny.
Reasumując CS był niezłą próbą stworzenia tanio samplera... jednak jakość jaką można było za jego pomocą uzyskać pozostawiała wiele do życzenia. Co do częstotliwości próbkowania to w zależności od produkcji widziałem iż opóźnienie wynosiło od 1 do 3 lini ekranowych. Niektóre z procedur używały liczników pokeya do odmierzania opóźnień (np. produkcja pokazana przez Sikora), niektóre prostej pętli dex, bne, a jeszcze inne po prostu opóźniały się poprzez zapisy do WSYNC. Zakładając iż WSYNC jest to jakieś 15KHz, to w.g. prawem częstotliwości Nyquista jeżeli odtwarzamy próbki z prędkością 15KHz to słyszalne pasmo wynosi połowę tego czyli jakieś 7.5KHz, tutaj teoria:
http://pl.wikipedia.org/wiki/Cz%C4%99stotliwo%C5%9B%C4%87_Nyquista
To co mi się udało wyciągnąć z atari przy odtwarzaniu sampli na pokeyu to jakieś 21KHz (czyli 10,5KHz pasmo), do posłuchania w intrze tego dema:
http://atari.fandal.cz/detail.php?files_id=304
perkusja w intrze przed właściwym demem odtwarzana jest na przerwaniach IRQ generowanych przez POKEY-a z częstotliwością ~21KHz. Do tego dema polecam prawdziwy hardware, na emu nie brzmi jak powinno.
ufff... ale się naprodukowałem ;)
irwin 2009-11-23 22:43:53
@Seban - czapki z głów, dzięki za wyczerpujące przedstawienie tematu - to powinno być na atariki lub Kaz powinien zrobić z Twojego tekstu nowinke.
A samo demko Digital Trash - właśnie oto mi chodziło, tj o perksuje na samplach reszta na syntezie. Jak dla mnie to znacząco poprawia komfort słuchania muzy na Atari. Gdyby jeszcze RasterMusicTracker tak potrafił to wiele prostych nie wymagających gierek można by było tą drogą udzwiękowić.
tdc 2009-11-24 06:13:55
Z racji braku czasu, na razie jedynie obrazek:
http://tdc.pigwa.net/pics/programy/atari/CrystalSound_1988_mab1.png
Program/sampler proponuję testować własnie na tym pliku wczytanym do programu (jest jeszcze dostępny 2 i chyba 3 plik).
seban 2009-11-24 13:39:55
ten program właśnie kiedyś analizowałem, nie pamiętam czy w wersji 1.0 ale 30KHz było wierutną bzdurą niestety. Jeżeli znajdę to w swoich zbiorach to przyjrzę się temu jeszcze raz. I żeby nie było nie twierdzę że na 8-bit atari nie da się uzyskać 30KHz częstotliwości próbkowania (czyli pasmo słyszalne jakieś 15KHz). Kod który widziałem zajmował zbyt wiele cykli aby można było uzyskać wspominane 30KHz, być może miałem jakąś starszą wersję oprogramowania do CS... ale taka częstotliwość próbkowania wymagałaby odtwarzania dwóch próbek w ciągu lini skaningowej... pomijając sens robienia tego przy 4-bitowej rozdzielczości sampla... to długość sampla wykonanego z taką częstotliwością przy buforze jakieś 40-50KB RAM byłaby śmieszna :)
irwin 2009-11-24 16:13:09
@Seban - też tak podejrzewam, raczej wątpie aby małe Atari potrafiło tyle wyciągnąć, zresztą tak jak piszesz nawet gdyby to i tak pożytek z tego byłby marny z uwagi na kolosalną zajętość takich sampli. Mnie tam na małym Atari wystarczyłoby nawet 6khz, i myślę że byłaby to wartość optymalna ze względu na jakość i zajętość pamięci.
@Tdc - a możesz podać, zamieścić ów program z tymi samplami -bo Kaza niestety brak, albo ja nie mogę znaleźć. Z góry dziękuje.
seban 2009-11-24 21:11:25
@irwin: pewnie da się tyle wyciągnąć nawet, tylko co z tego? przy tak małej ilości pamięci... pewnie trzeba by trzymać 1 próbkę w jednym bajcie, prockę odgrywającą zapodać na stronie zerowej, wyłączyć ekran. Trzeba by to policzyć ile cykli to zajmie ale sądzę iż powinno się dać. W tamtych czasach chyba nikt nie próbował odtwarzać szybciej niż 15KHz, ale mogę się mylić, przecież nie analizowałem każdego programu z samplami który napotkałem ;)
Poszukam tego programu do crystal sounda na swoich dyskietkach, może uda się odkopać, a jeżeli znajdę zapodam linka.
Typowe prędkości używane do odgrywania sampli to 15KHz (opóźnienie równe jeden lini rastrowej) lub 7,5KHz (opóźnienie równie dwóm liniom rastrowym). Takich prędkości odtwarzania używał Music ProTracker napisany przez SoTe. Również Black Magic Composer jeżeli się nie mylę odtwarzał swoje digi-drumy z prędkością 7,5KHz.
Zdarzały się oczywiście wyjątki od reguły, niektórzy w swoich prockach używali liczników POKEY-a i przerwania IRQ generowanego przez POKEY-a po doliczeniu do zera... ale właściwie takie rozwiązanie miało swoje wady jeżeli chciałeś wykorzystać normalne (syntetyczne) kanały dźwięku... ale to już wywód na długie zimowe wieczory ;)
Wracając do Crystal Sounda nawet jakby wyciągał 30KHz to zastosowane w nim rozwiązania sprzętowe nie było zbyt optymalne i dawało o niższą jakość dźwięku niż w przypadku zastosowania klasycznego przetwornika A/D. Chyba muszę przykład jakiś przygotować aby pokazać o co mi chodzi :)
I jeszcze jedno... w niczym nie umniejszam twórcom crystal sounda. Wymyślone przez nich rozwiązanie w tamtych trudnych czasach zasługuje jak najbardziej na pochwałę, i było to chyba jedno z niewielu rozwiązań dostępnych na rynku w tamtym okresie... także wielki szacunek dla osób stojących za crystal sound. Pojęcia tylko nie mam ile taki sampler kosztował w tamtych czasach.
Jako samplera używałem swojego wynalazku zbudowanego z układu ADC0809 i podpiętego do portu CART-a, potem gdy z SoTe tworzyliśmy oprogramowanie dla AD Convertera (http://atariki.krap.pl/index.php/Mirage_AD_Converter) dostaliśmy po 1 szt. z Mirage Software. Było to jednak sporo po tym jak powstał Crystal Sound.
Kaz 2009-11-24 21:30:43
Irwin - w jakim sensie brak i do czego jestem potrzebny? :)
Seban - Irwin ma racje, ze te wszystkie informacje zasluguja na zebranie, zilustrowanie przykladami i zaprezentowanie swiatu. Gdybys mial chwile czasu to sluze szpaltami serwisu.
irwin 2009-11-24 21:54:58
Miało być "u Kaz'a brak" czyli w AtariOnline.pl takiej wersji tego programu z dołączonymi, a wymienionymi przez TDC samplami nie ma. Tak więc nie o Kaz'a tu chodzi ;)
Kaz 2009-11-24 22:00:06
OK, to jak znajdziesz taka wersje z dodatkami to ja tez poprosze, bo uzupelnie katalog.
Tdc 2009-11-24 23:29:02
Nie sprawdzałem tego, ale jest to warte sprawdzenia co ten program faktycznie robi. Ja pamiętam, że tylko się wtedy zastanawiałem jak oni to sprawdzili, że w danym momencie jest właśnie tyle Hz itp. (w końcu wtedy na małym Atari nie było programów, które podawały aż tak precyzyjne dane i dało się je dowolnie ustawiać). Bo co do tego że małe Atari tyle wyciąga to nie mam wątpliwości (z mojego ostatniego artka u Kaza odnośnie szybkości Action! pośrednio wynika, że nawet w tym kompilatorze da się osiągnąć częstotliwość o wiele wyższą).
Zamieściłem dla Ciebie ten programik z przykładowym samplem (nigdy na małym Atari nie słyszałem lepszej jakości dźwięku digitalizowanego):
http://tdc.pigwa.net/Prg/Atari8bit/CrystalSnd1988.atr
Natomiast na którejś dyskietce na pewno mam tych przykładów więcej, ale nie mam teraz możliwości aby tego szukać. Może ktoś inny to znajdzie.
Aha i testujcie ten program koniecznie na real Atari.
seban 2009-11-25 01:18:15
@tdc: z tym że w action da się odtwarzać sample 30KHz to trochę przesadziłeś ;) twoja procedura musiałaby się wykonać dwa razy w ciągu linii ekranowej. Śmiem twierdzić iż dla action! nie jest to wykonalne. Mówię o precyzyjnym odtwarzaniu kolejnych próbek ze ściśle określoną częstotliwością. Nie chodzi mi o odegranie kawałka pamięci z częstotliwością wynikającą z przypadku ;) Czyli synchronizujesz się albo licznikami POKEY-a, albo liczysz cykle. I trzymasz po dwie 4-bitowe próbki w bajcie :) tak jak to robi 99,9% programów obsługujących sample na małym Atari.
Zajrzę do kodu programu z twojego ATR-a i powiem Ci czy faktycznie ich procka wyciąga 30KHz (słyszalne pasmo 15KHz). Używają liczników POKEY-a (kanały 3 i 4 połączone w jeden kanał 16-bit) do generowania opóźnień więc w czym problem określić częstotliwość próbkowania?, wzór jest prosty (wspomagałem się atariki):
sample_rate = (F/2)/(R+7)
gdzie F to częstotliwość bazowa 1773447 Hz, a R - wartość wstawiana do rejestru układu POKEY.
dla tych co chcą liczyć szybko jaką częstotliwość soft do CS usiłuje osiągnąć:
http://www.wolframalpha.com/input/?i=%281773447%2F2%29%2F%280x003c%2B7%29
W przypadku ustawienia prędkości na 30KHz, do rej. POKEY-a wpisywane jest $003c, więc faktycznie licznik odmierza okres czasu odpowiadający 31662Hz, ale do tego trzeba doliczyć jeszcze czas wykonania się procedury odtwarzającej. Spróbuję określić realną częstotliwość odtwarzania którą wyciąga oprogramowanie crystal sound.
Dodam jeszcze iż procedura samplująca jest jeszcze dłuższa, ponieważ musi dokonać konwersji i korzysta z 256-bajtowej tablicy konwersji. Z kodu widać iż crystal sound był podpinany do dwóch portów joysticków. To co mogło wyjść z niego to jak widzę wartości od 1-8 ... a więc sample są de facto rozdzielczości 3-bit. No chyba że hardware był inny niż myślę i wtedy jestem w błędzie. Ale pewnie nikt nie ma crystal sounda? co? ;)
Jest jakiś miąch z tablicą konwersji, i wygląda na to że było coś więcej niż UL1970/UL1980 ale na chwilę obecną nie mam chęci wnikać za bardzo... sprawdzę to później... na dziś mam dość ;)
Tablica konwersji (PORTA->Sample Value) jest pod adresem $2f00:
2F00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F10 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F20 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F30 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0E
2F40 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F50 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F60 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F70 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F
2F80 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2F90 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0C
2FA0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2FB0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0D
2FC0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A
2FD0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0B
2FE0 : 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 09
2FF0 : 00 00 00 06 00 00 00 07 00 04 00 05 02 03 01 00
Niby pokrywa pełne 4-bity, więc może się myliłem co do 3-bitowości Crystal Sound-a? Coś mi świta w głowie iż mogli dołożyć enkoder priorytetowy 1 z 10 na BCD ;) np. coś w rodzaju 74LS147 do tego UL1970/UL1980 mieliby 10 poziomów ;) tudzież dwa 74LS148 ;) Tak, chyba bym użył dwóch 74148 i UL1970 ;)
dla zainteresowanych tematem:
http://focus.ti.com/lit/ds/symlink/sn54ls148.pdf
http://www.iele.polsl.pl/elenota/CEMI/ul1970.pdf
No pora chyba przeanalizować kształt i zawartość sampli aby się przekonać czy CS był na prawdę full 4-bit ;)
Procedura odtwarzająca jest pod adresem $2ba0
Procedura samplująca jest pod adresem $2c0e
Ktoś chętny do liczenia cykli? ;) Jest szansa iż chłopaki z future crew zmieścili się i wtedy faktycznie mamy 30KHz sample rate czyli słyszalne pasmo ~15KHz :)
Pozostaje jeszcze sprawa dynamiki i jakości ich przetwornika ale o tym później. Faktem jest natomiast iż te kilka sekund sampla brzmi całkiem nieźle ;)
aha, przykład od TDC odpalajcie np. pod Altirra, Atari800Win nie będzie działać poprawnie :)
@kaz: nie obiecuję, ale mogę spróbować jakoś to poskładać, ale właściwie część spraw to tylko moje domysły więc nie wiem czy warto publikować. I tak właściwie to co to miałoby by być? o czym art? bo tutaj dyskutujemy o masie spraw bez większego ładu i składu ;)
dobrej nocy wszystkim życzę :)
seban 2009-11-25 02:24:06
nie dawało mi to spokoju... dokonałem konwersji sampla mab1 moim prymitywnym programikiem do formatu 8-bit raw... wczytałem do edytora audio... i co wyszło...
1) myliłem się co do sposobu interpretacji poziomu sygnału wejściowego przez Crystal Sound... właściwie daje taki sam efekt jak normalny przetwornik A/C. Zero po środku skali, tak jak powinno być. Widać sample które kiedyś oglądałem nie pochodziły z samplera crystal sound...i były na dysku z tym programem co zapodał TDC niejako przez przypadek.
2) częstotliwość odtwarzania którą uzyskuje ten program to około 27KHz, a nawet trochę mniej. Skąd wniosek? Przy odtworzeniu sampla z prędkością 31662Hz było go słychać duuużo za szybko... dopiero zejście do 27KHz dało efekt identyczny z tym który można było usłyszeń na real-atari :)
Charakterystyka częstotliwościowa przykładowego sampla w miarę liniowa w zakresie do 12KHz, DC offset trochę zwichrowany i próbka z mocnym clippingiem (tzn. przesterowana), i sampler wprowadzał pewną asymetrię sygnału :) w sygnale występowały także krótkotrwałe "szpile" (tzw. glitch). Ale jak na tamte czasy... i tak było nieźle ;)
seban 2009-11-25 02:40:24
i ostatnia sprawa, analiza statystyczna występowania każdej wartości w pliku "mab1" wykazała iż każda z wartości 0-15 występuje w pliku, a więc sampler wygląda na w pełni 4-bitowy, poniżej wyniki zliczenia każdej z wartości:
$0: 1341
$1: 2587
$2: 1433
$3: 3638
$4: 2058
$5: 7349
$6: 6436
$7: 8779
$8: 11897
$9: 11610
$a: 9649
$b: 8650
$c: 2745
$d: 4000
$e: 1813
$f: 4601
wniosek: nie doceniałem technologii z 1988 roku ;)
Tdc 2009-11-25 16:03:51
No proszę jaki ładny wykład ;)
No mi się właśnie wtedy również wszystko zgadzało, jednak nie miałem jak sprawdzić czy to jest 30 czy 27 (nawet CS nie miałem;) – tak czy siak jest dobrze ;)
Moja uwaga jest jeszcze taka, że pewne przekłamania do sygnału może prowadzać emulator (w końcu w emulatorach zwykle emulacja dźwięku to kulawa noga). Dlatego nie wszystkie parametry jakie podałeś mogą być w 100% pewne.
Co do Action! to oczywiście miałem na myśli maksymalną prędkość jaką da się osiągnąć (bez asm) dlatego nie miałem na myśli pełnej kontroli częstotliwości bo w momencie gdy CPU ma tyle roboty to jest to dość trudne. Jeśli miałbym zmieniać częstotliwość płynnie to tak samo jak w asm musiałbym docyklowywać itp.
Z wykorzystaniem sztuczek opisywanych przez Yosha i przeze mnie da się w jednej linii spokojnie wrzucić cztery wartości do rejestru POKEYa co daje ~60 kHz realnego sygnału samplowanego (trudno mi w tej chwili powiedzieć, czy da się w Action! dać 5 wartości; natomiast w teoretycznym przypadku gdy nie chcemy mieć sygnału z danych, tylko sygnał o maksymalnej częstotliwości to w Action! da się wyciągnąć jeszcze kilku krotność 60 kHz).
Nie jest też to taka sztuka dla sztuki, bo kiedyś napisałem dwukanałowy tracker w Action! który działał w całkiem przyzwoitej szybkości odtwarzania. W te wakacje Sikor i Miker namawiali mnie abym do niego napisał cywilizowany edytor i wypuścił. Jak rozumiem irwin byłby zainteresowany tematem ;)
PS. skoro ma powstać artykuł to ja się piszę na drugiego redaktora ;) W końcu temat ciekawy.
seban 2009-11-25 17:20:26
@tdc: ja nie odpalałem tylko na emu, odpalałem na real atari i na Altirra. Chłopaki w ASM ledwie 27KHz wyciągają a ty chcesz w Action! 60KHz i więcej? ;) Uważam to za nierealne nawet jakbyś trzymał 1 próbkę w jednym bajcie.
Weź także pod uwagę pasmo przenoszenia biednego LM358 który robi za mixer/wzmacniacz w torze audio Atari :)
Co do 60KHz i wielokrotności tegoż to już jest całkowicie nierealne. Zapominasz iż nawet przy wyłączonym ekranie antic wstrzymuje CPU (i to 9 razy w ciągu każdej linii skaningowej) aby wykonać dram-refresh. Odtworzenie 5 próbek w jednej linii rastra w ACT? Uważam to za nierealne :)
Nawet jakby było realne to jakich ilości pamięci potrzebujesz? Nawet jakbyś chciał wykorzystać ext ram to dochodzi czas aby przełączać banki. No chyba że raz na 16K i zachwianiem częstotliwości odtwarzania ;) Ogólnie możemy dyskutować tak w nieskończoność, ale postaram Ci się udowodnić iż to co chciałbyś osiągnąć jest nierealne, weźmy taki przykład:
sei
inc $d40e
lda #$00
sta $d400
clc
lda #$10
ldx #$1f
loop:
sta $d201
stx $d201
bcc loop
co co widzisz to najszybsza metoda wygenerowania sygnału prostokątnego na wyjściu POKEY-a. Efektywność niby jakieś 140KHz, ale nie chciałbyś widzieć kształtu fali poszatkowanej sygnałem HALT wystawianym przez ANTIC dla CPU. I tak jak sie spodziewałem coś możesz zobaczyć jednie bezpośrednio na pine audio out z POKEY-a, to co wychodzi z LM358 można określić jako szum i jakąś interferencję spowodowane przed dużą ilość harmonicznych występujących w tym sygnale... jednym słowem ledwie udało się uzyskać 60KHz *2 i to nie nadaje się do niczego, bo procka odtwarzająca sampel musi mieć nieco więcej instrukcji... i ja mówię o czystym ASM.
Swoje słowa mogę poprzeć oscylogramami i pomiarami dokonanymi na jeżeli będzie taka potrzeba, jednak to co widzę obecnie na oscyloskopie jest jedną wielką porażką jeżeli chodzi o kształt fali.
pozdrawiam
Seban
irwin 2009-11-25 17:26:20
irwin jest zainteresowany takowym trackerem ale pod dwama warunkami - nie może być w action, gdyż irwin jest zainteresowany trakerem pod Windows ;) oraz fajnie jakby potrafił zrobić kombo tj np jeden, dwa kanały sample a inne syneza Pokeya. To byłby przełom w rodzaju Graph2Fonta. Natomiast sam player/biblioteka pod Action - jak najbardziej.
Odnośnie owego sampla - ja też sprawdziłem i rzeczywiście jego jakość oscyluje około 26.8khz co jest wynikiem bardzo dobrym. Jedynem problemem jest tu zajętość takiej próbki oraz czy oprócz odgrywania jest jeszcze możlwość pokazania czegoś na ekranie.
seban 2009-11-25 17:32:58
@irwin: takie możliwości ma od wielu lat Music ProTracker ;), tyle że nie jest pod windows, a więc nie spełnia twoich wymagań ;). Za to bez problemu obsługuje 2 kanały digi+ 2 kanały syntetyczne. W przypadku 2 kanałów Digi jeden jest przeznaczony dla perkusji (stała prędkość odtwarzania), drugi natomiast gra sample ze zmienną częstotliwością.
seban 2009-11-25 18:33:32
@irwin: przy tej jakości sampla nia da się nic sensownego pokazać na ekranie... włączenie dma obrazu nawet w trybach o niskich rozdzielczościach spowoduje znaczące zniekształcenia dźwięku. Optymalną (w sensie jakości) częstotliwością odtwarzania przy włączonym obrazie i w trybie graficznym wydaje się być 15KHz. Gdy zaczynamy zabawę z trybami znakowymi robi się bardziej krytycznie i trzeba zejść do 7,5KHz. W trybach znakowych w pierwszej linii każdego rozkazu DL nie pozostaje za dużo cykli wolnych... procedura która miała by działać z częstotliwością 15KHz nie bardzo miałaby szanse na wyrobić się czasowo. Można to oczywiście zrobić ale wyraźnie słychać jak ANTIC przeszkadza CPU.
irwin 2009-11-25 18:34:36
Swego czasu na Atari powstały programy do kolorowania grafiki duszkami jak GED czy PowerGraph ale dopiero pojawienie się Graph2Fonta stworzyło tę lawinę obrazków jakie dotyczczas już w G2F zrobiono. Kiedyś pisałem do Rastera aby taką moźliwość wprowadził do RMTrackera ale nie był zainteresowany tematem.
Tdc 2009-11-25 20:43:57
He, he no proszę jednak się udało. Na dyskietce z moimi źródłami znalazłem backup drugiego pliku, dlatego podmieniłem plik ATR:
http://tdc.pigwa.net/Prg/Atari8bit/CrystalSnd1988.zip
seban: No widzisz, pokazujesz, że jednak nauka Action! na Atarionline jest potrzebna ;) bo jakoś wielu do dziś tego języka nie docenia.
Aby nie wdawać się w szczegóły to odsyłam tutaj do mojego dawnego tekstu:
http://atarionline.pl/v01/index.php?subaction=showfull&id=1241566556
&archive=&start_from=40&ucat=1&ct=nowinki
Przeanalizuj sobie moje wykresiki rastrowe prezentujące obciążenie CPU. Te źródełka zamieszczone w tym tekście są tak skonstruowane aby wskazać czas jaki potrzebuje Action! na wykonanie jakiś czynności. Jak widać Action! Wiele może zrobić podczas jednej linii rastra.
Jeśli Tobie mało to zrobię źródełka w Action! (+ skompilowane), które coś takiego robą z dźwiękiem czy z czymś innym. (nawiasem mówiąc w moim efekcie do demka które mam nadzieję ujrzy światło dzienne na następnych Głuchołazach – jest zrobiony fajny efekt w którym czysty Action! robi fajne rzeczy w 1 linii rastra)
> Weź także pod uwagę pasmo przenoszenia biednego LM358 który robi za mixer/wzmacniacz w torze audio Atari :)
Racja ;) ja tylko teoretyzowałem ;)
> Co do 60KHz i wielokrotności tegoż to już jest całkowicie nierealne. Zapominasz iż nawet przy wyłączonym ekranie antic wstrzymuje CPU
O niczym nie zapominam, chodzi mi o to że jeśli nie bierzemy kolejnych danych z RAM to wsadzamy sobie do rejestru cokolwiek (np. XOR) za maksymalną prędkością. Wtedy w asm da się duuuużo w 1 linii, a w Action! niewiele mniej. Jak nie wierzysz to mogę szybko napisać jakiś kod i podesłać.
Oczywiście cały czas są problemy o których piszesz – trzeba tu cyklować jak nic.
> Odtworzenie 5 próbek w jednej linii rastra w ACT?
No ja właśnie też pisałem, że nie jestem tego pewien, 4 wyjdą ale czy 5 to nie pamiętam tak dobrze wydajności małego Atari i Action! (w końcu dawno na nich nie programowałem – ostatnio tylko emulatory, którym nie dowierzam).
> Nawet jakby było realne to jakich ilości pamięci potrzebujesz?
Nie zrozumiałeś mnie odnośnie częstotliwości większych od 60 kHz to cytuję: „natomiast w teoretycznym przypadku gdy nie chcemy mieć sygnału z danych, tylko sygnał o maksymalnej częstotliwości to w Action! da się wyciągnąć jeszcze kilku krotność 60 kHz ”
czyli dane xor czy inne jak pisałem wyżej.
> to co wychodzi z LM358 można określić jako szum i jakąś interferencję spowodowane przed dużą ilość harmonicznych występujących w tym sygnale...
Racja dlatego pisałem wcześniej „w teoretycznym przypadku”
> Swoje słowa mogę poprzeć oscylogramami i pomiarami dokonanymi na jeżeli będzie taka potrzeba
Nie trzeba doskonale się rozumiemy ;)
irwin: „gdyż irwin jest zainteresowany trakerem pod Windows ;) ”
Nie piszę programów na tego trojana ;):)
Poza tym na win jest wiele trackerów następny nie jest potrzebny, choć chyba nie ma żadnego z emulacją POKEYa, choć kto wie czy nie dało by się tego zrobić w jakimś programie (np. w końcu instrumenty wirtualne są na co dzień na pecetach używane).
> fajnie jakby potrafił zrobić kombo tj np jeden, dwa kanały sample a inne syneza Pokeya. T
To realne, ale właśnie ja się za to brać nie będę, bo
1. staram się wykorzystać potencjał moich starych programów (a nie pisać zupełnie nowe)
2. Jak pisał saban – jest już parę takich
3. chcę aby max pamięci było dostępnej na sample (czyli prawdziwy tracker), a nie na dużo kodu z mojego punktu widzenia zupełnie zbędnego;)
pin 2009-12-01 20:50:06
.. miałem gdzieś kilka sampli wykonanych samplerem z /TA/;- na "ucho" brzmiały dobrze i raczej nie był to baton 3bit :) Jak wygrzebie, to podeśle.
MD 2010-05-31 22:19:17
Kilka słów o Crystal Soundzie wprost ze źródła. Urządzenie zaprojektowaliśmy i zrobiliśmy razem z kolegą, chodząc jeszcze do ZSEE W Bytomiu (ogólne założenia powstały w tramwaju). CS oparty był o UL1980 (linijka śwetlna), na wyjściach zamiast diod były odpowiednio dobrane oporniki. Jeżeli dobrze pamiętam, układ był przystosowany do sterowania 8 diodami więc w sumie odczytywane było 9 poziomów dźwięku (3 i "pół" bita). W pierwszej wersji CS podłączany był przez wejścia joysticka i można było uzyskać próbkowanie większe niż 20kHz. Kolejną wersję zrobiliśmy już w formie cartridża, ale "przetwornik A/C" pozostał na UL1980. Do tego dodawaliśmy zestaw 3 programów do obsługi. Potem Marek napisał chyba jeszcze jakiś dodatkowy program do tworzenia własnych dem gdzie wczytywało się tylko dźwięk, obrazek itp i można było automatycznie wygenerować własne demo, pewnie stad ileś różnych dem wykorzystujących tak digitalizowany dźwięk.