2,926

(35 odpowiedzi, napisanych Bałagan)

Rozumiem, ze Code3 Cruncher powstal w wyniku niezadowolenia z osiagow crunchera Magnusa? ;)

Dokładnie tak. SoTe był i jest taki że lubi robić rzeczy po swojemu.

Cruncher 5 Magnusa był jak na tamte czasy totalną rewelacją ;-) Bo był to jedyny tego rodzaju program na ATARI, w tym czasie ludzie z C64 mieli tych programów dziesiątki. Jednak temat packerów z C64 to temat na oddzielny post a może nawet artykuł, bo to bardzo interesujące zagadnienie. W skrócie rzecz ujmując w C64 jedyną możliwością załądowania programu było załadowanie go w obrzar przeznaczony na pamięć programu BASIC'a. Chyba około 38KB, więc teraz się domyślacie zlaczego ludzie z C64 tak szybko zaczeli się znajmować kompresją danych. ATARI miało na tyle genialnie pomyślany format pliku binarnego iż przez baaaardzo długi czas nie było takiej potrzeby. Bo ładowaliśmy sobie programy w jake obszary chcieliśmy i do tego mogliśmy wykonywać dowolny kod pomiędzy wczytanymi blokami (tzn. wektor INIT).

Ale wracając do SoTe on zawsze lubił analizowoać dany problem i rozwiązywać go po swojemu ;) A że wychodziło mu to w 99% przypadków lepiej to już nie jego winia. Nie ma co ukrywać iż Code3 Cruncher jest bardzo podobny w obsłudze do Crunchera 5, bo też na nim był wzorowany ;) Jednak procedury pakujące były napisane od nowa przez SoTe. Możecie się smiać ale pamiętam to do dziś jak SoTe pod koniec pisania swojego Packera potrafił rozpakować ciąg zero-jedynkowy na kartce pochodzący z jego packera ;) Zersztą pakowanie pliku na kartce prze SoTe też wyglądało zabawnie (pewnie nie dla niego, bo spędził nad testami procedur pakująco/depakujących naprawdę wiele godzin).

Wiem że SoTe analizował dogłębnie Cruncher 5 i bardzo mocno się zastanawiał czy procedury kompresji/dekompresji nie pochodzą z C64. Pokazywał mi kilka zastanawiających fragmętów kodu z Cruncher 5. Była chyba obsługa komórki $00 lub $01 która w C64 odpowiada za odłącznie róznych obszarów pamięci (tak jak $d301 w ATARI). Do tego po załadowniu pliku procedury przepisywały wszystko jak najniżej się da i rozpoczynały proces dekompresji od konca do początku pamięci (zawsze tak robili na C64). Tylko u nas był mały problem ;) W C64 mogli sobie odłączyć wszystko co możliwe i mieć pełne 64KB RAM, mogli odłączyć nawet rejestry sprzętowe ;) Magnus rozwiązał sprawę w ten sposób iż dane spakowane po pierwszym przebiegu (RLE, charpack) musiały się kończyć w do $cfff inaczej Cruncher odmawiał dalszej kompresji. Potem drugi przebieg pakował dane w obszarze do $cfff, a depacker chyba rozpakowyał dane do końca... ale mogłem coś popier&^#&*# dawno to było... i nie opowiadam o tym aby wywołać jakąś wojnę.... tylko dlatego że uważam to za bardzo fajną ciekawostkę! Zawsze miałem i będę miał szaczunek dla Magnusa ;)


Wcześniesza wersja Cruncher'a Magnusa (4.64) miała tylko jeden przebieg; specyficzne RLE, które ludzie z C64 nazywają char packerem. Czy nie zastanawiała was wersja *.64? bo ja się zawsze zastanawiałem czy to przypadek czy też nie. Potem Magnus dopisał drugi przebieg (LZ77 jak dla mnie) ale ludzie z C64 nazywają to chyba imploding ;)

Co by nie mówić i to i tak Magnus zapoczątkował rewolucję cruncher'ową na małym ATARI. I nie istotne w tej chwili jest czy przepiswyał to z C64 czy nie... ale on to rozpoczoł... i chwała mu za to :)

a skad czerpal wiedze o metodach kompresji?  Czy zagladal do C64? ;)

hmmm... nie powiem że SoTe nie przyglądał się Cruncher'owi Magnusa. W tamtych czasach nie było praktycznie żadnej literatury w Polsce dostępnej o tej tematyce. Ale swego czasu ukazała się seria bardzo fajnych artykułow o metodach kompresji a magazynie papierowym "KEBAB" i tam na prawdę było opisane dużo metod i rodzajów kompresji. Z tego co pamiętam SoTe dużo eksperymentował z metodami kompresji i to co wytworzył to wynik jego doświadczeń. Wiem że spakował setki plików aby dobrac tablice i metody kodowania długości sewencji. Trochę nad tym posiedział i zrobił co mógł na tamte czasy. A wyszło mu to chyba całkiem nieźle ;) Bardzo długo Clever People uzywało jego narzędzia do pakowania fileówek ;)

Raz, ze obiecales kiedys podeslac mi spakowana wersje megadema HOBBY-TRONIC '90 lub '91 (?), ktora w czasach snaila dostalem od Ciebie, ale pozniej stracilem ;  Dwa, ze chetnie obejrze wszystkie  releasy od *CLEVER PEOPLE* !!!!  :)

Wiem, obiecałem i pamiętam. Jak tylko się trochę odkuję i znajdę czas na przejrzenie dyskietek obiecuję wszystko udostępnić. Zarówno Ciebie, Strykera jak i pozostałych zniecierpliwionych i zniechęconych proszę o trochę wyrozumiałości i cierpliwości...  za jakiś czas na stronie:

http://www.n-s.pl/slight/

powinno się coś zacząć dziać ;)

Zreszta musze wam powiedzieć iż rodzina też narzuca pewne obowiązki na człowiekia i to powoduje że wolny czas czasami kurczy się prawie do 0... ;( także proszę jeszcze o cierpliwość ;)

Wracając do packerów ze stajni SLIGHT, zapomniałem dodać jeszcze o dwóch depackerach ;)  W końcu przysły czasy takie że były wokoło AMIGI i ATARI ST ;) A na tych platformach były bardzo szybkie w porównaniu z ATARI programy pakujące (np. PowerPacker dla AMIGI) i bardzo fajny (ICE-PACK) dla ATARI-ST. Już kiedyś o tym wspominałem przy okazji jakiegoś posta na AA, ale może przypomnę iż przy okazji nauki assemblera motoroli 68000 napisałem depacker dla ICE-PACK'a z ATARI ST i dokonałem optymalizacji depackera dla PP20 z amigi... którego to wypatrzyłem w releaseach z Boody Coders ;)

Były jeszcze czasy pakowania wszystkich release'ow z Clever People na C64 ;)  Przewalało się dane do spakowania na C64 ;) Pakowało (najczęsciej Cruel Cruncherem lun Exploding Faces Cruncher'em) i przewalało się to z powrtorem na ATARI gdzie po paru modyfikacjach depackera odpalało się to ATARI ;) Operacja wygłądała tak. Spakowana file'ówka ładowała się jak najwyzej w pamięć. Po załadowaniu przepisywana była w obszar $801 (tak jak się ładują programy na C64 ). Odpalało się depacker, te depackery z C64 zawsze rozpakowywały od końca pamięci w dół (znaczy się pierszy bajt rozpakowaywały od $ffff i potem $fffe). Po rozpakowaniu dane się przepisywało w odpowiednie obszary pamięci i działało ;) Możecie mówić iż to było LAME, ale jakie efektywnie i krótkie ;) Przyznaje się bez bica iż biło na głowę Code3 Crunchera i sam nie potrafiłem napisać lepszego Crunchera niż te z C64 (pod względem rozmiaru danych wyjściowych). Prędkości pakowania nz C64 były straaaaaasznie długie... dlatego potem się przerzuciłem na PP20 i PackICE ;)

pozdrawiam serdecznie
Seban/SLIGHT

2,927

(35 odpowiedzi, napisanych Bałagan)

No i wychodzie, że kiedyś efekty nie były "realtime calculating", tylko "realtime depacking". :D

Ba.... no wiesz... jak byś chciał mapę do "voxel'a" 256x256 pixeli poiliczyć na ATARI to trochę by to zajeło czasu ;) policzyliśmy wcześniej na PC, a potem SFDN Packer i już ... cały Voxel był jednak rysowany realtime, na podstawie mapy wysokości odpackowanej wcześniej ;)

Track scroll też był rysowany realtime, jednak liczenie trajektorji też by zajeło kupę czasu... więc zostały one policzone wcześniej w turbo basicu ;) a potem spakowane sine packer'em ;)

Obroty 3D korzystały ze stablicowanych wymnożonych sinusów ;) zresztą wszyscy do dziś tak robią ;) tyle że dziś bym te tablice sam policzył a kiedyś prościej mi było mieć gotowe tablice i spakować je np. sine-packerem ;)

Zapomniałeś chyba jeszcze o pakerze do 4-bitowych sampli, który został zmuszony do pakowania bodajże HIP-ów. A może to właśnie jest ShanonFano Differentian Nibble Packer? :)

Pojęcia nie miałem iż HIP był pakowany SFDN ;) tak ten packer nadaje się wyśmienicie do sampli i grafiki w trybie 9,10,11 (i wszystkiego o organizacji Nibblowej). Tak naprawdę to myślałem że nikt tego packera poza mną nie ma ;)  Nie pamiętam abym go puszczał w obieg ;) ale ja w końcu mam już skrerozę więc może go udostepniłem ;) to było tak dawno temu ;)

pozdrawiam serdecznie
Seban/SLIGHT

2,928

(35 odpowiedzi, napisanych Bałagan)

Seban, przypomnij mi w takim razie co było czym.

Ehhh.... no to trunde pytanie mi zadałeś ;)
Ja też tak naprawdę mało pamiętam ;(
Ja chyba pamiętam 3 lub 4 wersje Code3 Crunchera ;)

Pierwsza wersja... nie wiem czy wyszła publicznie... charakteryzowała sie tym iż miała jakby 3 przebiegi dekompresji ;) Pierwsza od depacking LZ77 (efekt na ekranie to inc $d01a chyba), drugi etap do dekompresja RLE (efekt to sta $d01a), trzeci etap to długie przemieszczanie rozpakowanych danych w pamięci, na ekranie dość długo migotały chyba ciemno brązowe paski.

Drugą wersją była chyba wersja 2.2 która miała przyspieszone ostatnie przepisywanie... nie było przy nim "wizualizacji". Ona spakowane dane zapisywała na dysk przeznaczony specjalnie dla siebie ;)

Kolejna wersja miała dorobiony już licznik przy depackowaniu pierwszym (LZ77), potem było RLE. Z tego co pamiętam to chyba RzOG wymolestował SoTe o licznik przy dekompresji ;) I do tego packer zapisywał zane już nie na dyskietkę ale do rozszeżonej pamięci i po zakończeniu pakowania dokonywał zapisu całości na dyskietkę.

Coś po głowie mi się pałęta  że była wersja 2.2 bez litery "D", która zamiast wykorzystywać zapis spakowanych danych na dyskietkę robiła to w dodatkowej pamięci (potrzbne były 4 banki, czyli 130XE). Ale szybko powstała wersja 3.0 z licznikiem i nie była chyba puszczona w świat wersja 2.2 (bez D), gdzie "D" miało właśnie oznaczać zapis spakowanych danych na dysk. Ale głowy sobie odciąć nie dam ;)

Żaden z w/w cruncherów nie dorobił się szybkiego depackera. Wszystkie posiadały wolną wersje dekompresora. Tak naprawdę do wersja przygotowująca dane dla FastDepackera była dwu przebiegowa... piwerwszy etap normalna kompresja bitowa... drugi etap o wiele szybszy... reorganizacja danych (wyrównanie do granic bajtów).

Idea fast depacker była zrealizowana już chyba przy Bitter Reality... jednak tak byliśmy zajarani efektem "świeczki" przy depackingu że szybki depacker w ogóle nie wchodził w grę bo świeczka się za krótko paliła ;-)

Nie pamiętam kto, ale ktoś pusił na giełdzie w Warszawie plotkę iż mamy wersję Code3 Crunchera ze świeczką przy depackingu... później ktoś pisał do SoTe że chce dostać od niego wersje Code3 Crunchera z efektem świeczki przy depackingu... oczywiście nic takiego nigdy nie istniało ;-) Ale niektórzy ludzie uparcie molestowali nas o wypuszczenie tej wersji na scene ;)

uffff... to chyba tyle ;)

Właściwie to zawsze SoTe pisał packery/depackery i nikt nas nie był z nim w stanie konkurować. Dopiero potem jak SoTe już na JIL nic nie tworzył a my pisaliśmy jeszcze Overminda to powstało kilka nigdy nie opublikowanych packerów na użytek Overminda i gierki SexySix.... na potrzeby Overmind'a napisałem chyba ShanonFano Differentian Nibble Packer oraz Sine Packera. To umożliwiało np. spakowanie 32KB mapy do comancha w chyba 4KB ;) Sine packer idealnie się nadawał do pakowania trajektorji do track scrolla i tablic potrzebnyych dla obrotów 3D ;)

Do Sexy six'a napisałem jakąś dziwną hybrydę podobną do kodowania huffmana ;) już na prawdę nie pamiętam ;) Wiem że zrobiłem jakiegoś wrednego bug'a i był problem przy kompresji/dekompresji niektórych rysunków.... nie miałem już czasu aby to poprawić i problem rozwiązano w ten sposób iż dobrano takie rysunki kótre się nie "syfiły" po komresji i dekompresji. Potem Miker się strasznie namęczył produkując kolejne "data disk" dla Sexy6 bo musiał dobierać rysunki tak aby nie trafić na buga w pakerze/depakerze ;)

więcej packerów ze stajni Code3/Slight nie pamiętam.  Muszę w końcu moje dyskietki ratować i je zacząć przeglądać może wtedy da się więcej napisać jeżeli to kogokolwiek jeszcze interesuje ;)

aaa.... był jeszcze jednek packer do Overminda ;) Pakował poszególne fazy fraktala ;) on był bardzo specjalizowany ;) depacker musiał odpackowyać poszczególne klatki w czasie rzeczywistym w międzczasie procedura zoom'ująca musiała przezoom'owywać sie od jednej rozpakowanej klatki do drugiej ;) To było jakieś RLE (poziome albo pionowe) i do tego jeszcze przed pakowaniem była zrobiona detekcja krawędzi tak aby jednolite powierzchnie zostały zastąpione bajtami 0, a odtworzenie obrazu było możwie metodą EOR, STA (jak w wypełnianych wektorkach). Tyle że packer decydował która metoda kompresji daje najmniejszy wynik i wybierą tą najbardziej optymalną ;)

Był jeszcze jeden packer... do textur w 64x64. Był on wykorzystany w niedokończonych nigdy częsciach overminda ;)

He... było jeszcze jedno.... nigdy tego w świat nie puściłem. To było coś w stylu DiskCommunicatora ;) Pakowało całe dyski do pliku i pakowało to jakimś głupim RLE... spakowałem sobie tym kilanaście dysków i potem się okazało że miałem tam jakiegoś buga i połowa stworzonych moim programem obrazów nadaje się do smieci (przewidująco liczyłem nawet CRC z tworzonych dysków). Niestety odkryłem to po tym jak skasowałem już oryginalne wersje ;(


pozdrawiam
Seban/SLIGHT

2,929

(35 odpowiedzi, napisanych Bałagan)

Gwoli ścisłości: tajną (chyba do dzisiaj) wersją był/jest Code3 Cruncher 2.2(fast depacker)

Tajną? Nie było czegoś takiego jak Code3 Cruncher 2.2 (fast depacker) sensu stricte. SoTe napisał taki programik który wczytywał plik do pamięci (max chyba 48KB) pakował go algorytmem który był w Code3 Cruncherze.... powstawał spakowany plik "zorganizowany bitowo" (strumień bitów).

Fash Depacker, hmmm... Nie wiem jak to prosto i szybko wytłumaczyć.... paker wypluwa spakowane informacje bitami, więc nawet niespakowane sekwencje nie leżą w granicy bajtów, przec co w normalnych warunkach depacker aby odczytać niespakowane kilka bajtów musi użyć procedury GetBit np. n*8 (gdzie n jest liczbą bajtów do pobrania).

Cała tajemnica fast depackera polegała na tym przeorganizowywał on plik w ten sposób że informacje czysto bitowe przechowywał bez zmian, (do popbrania wymagane urzycie procki GetBit), natomiast dane "bajtowe" np. niespakowane sekwencje, przechowywał tak aby je wyrównac do granicy bajtu więc depacker do pobrania bajtu nie musiał wykorzystać GetBit*8 tylko wykonywał zwykłe np. LDA ($80),Y co znacznie przyspieszało procedurę depakującą.

Do takiego spakowanego ręcznie pliku należało dodać później nagłowki (ręcznie) i depacker któremu podwało się dane skąd, gdzie i ile rozpakować. Wszystko ręcznie. Nigdy nie został napisany gotowy program w stylu DJ-Packer'a czy Flash-Packa... dlatego nie został nigdy opublkowany poniweważ większość ludzi i tak by sobie z nim nie poradziła... prog miał toporny interface... taki w stylu np. FileCopy 1.45 ;)

Do tego nie pakował lepiej niż Code3 Cruncher więc SoTe tego nigdy nie dociągnoł do postaci którą by mógł używać normalny użytkownik (normalny -> "nie koder" ;) )

Pierwszym programem który działał tak jak powinno było być to zrobione (w przypadku Code3 Crunchera i Fast Depackera) był packer Jiri Bernasek'a o nazwie SuperPacker. To był dla mnie przykład bardzo dobrze przemyślanego programu pakującego dla plików binarnych (nagłówek $ff,$ff,xx,xx,yy,yy). Nawet przez chwilę miałem zamiar dopisać taki interface dla procedur SoTe jednak jak zwyke w moim przypadku lenistwo zwyciężyło ;-( Potem zobaczyłem DJ-Packera.... i jeszcze później FlashPacka napisanego przez Fox'a ;)

Tak to prawda że wykorzystywaliśmy procedury SoTe do spakowania Overminda ;-) A że to coś nie miało nazwy... postanowiliśmy nazwać to Code3 Cruncher/ Fast Depacker ;)

Miker zresztą powinien pamiętać jak wyglądało składanie Overminda ;)

pozdrawiam
Seban/SLIGHT

2,930

(35 odpowiedzi, napisanych Bałagan)

Hmmm... pytasz Tatqoo co u mnie. Nie było wesoło. Zieniałem robotę i jak urat w tym czasie jak odszedłem z jednej roboty i zanim zdążyłem pójść do drugiej... rozłożyłem się nieco i wylądowałem w szpitalu ;( Teraz nadrabiam zaległości finansowe i na razie nie mam czasu na nic poza pracą ;-(

Stryker już pewnie jakieś Voo-Doo odstawia wkurzony iż Slight SID jeszcze nie gotowy... kupe fajnych rzeczy jest do zrobienia... gdyby jeszcze pracować nie trzeba było ;) Może do końa roku uda mi się stanąć na nogi i jakoś to będzie.... tak sobie obiecuje od dłuższego czasu że skończę wszystko rozpoczęte projekty... ale miesiące mi przez palce przeciekają.... tygodnie mijają jak dni... czas zapiernicza w takim tempie że nie wiem kiedy to się wszystko dzieje... Czy to jakaś starość? czy czy co? ;)

ps) Muzak zajefajny... bardzo go lubiłem w coverze SoTe, ale Twój jest stereo i też mi się bardzo podoba ;-)

pozdrawiam serdecznie
Seban/SLIGHT

2,931

(35 odpowiedzi, napisanych Bałagan)

"Soused " a.k.a. Soused Teat/SLIGHT -> SoTe -> Adam Bienias czyli np. autor MusicPro Trackera ;)

pytasz skąd... hmmm... z Warszawy ;-)
Wcześniej Soused Teat wraz z Sebanem ;-) tworzyli Code3 ;)
A obecnie SoTe jest masta-hacka-programistą (Lead Programmer) w http://www.city-interactive.com ;)

pozdrawiam
Seban/SLIGHT

2,932

(14 odpowiedzi, napisanych Software, Gry - 8bit)

hi!

Prawda, mozna pakowac Amigowskim Power Packerem ;-) Tak kiedys robilem ;-) Procedury do dekompresji gdzies jeszcze mam ;-) Tak sie pakowalo pare lat temu file pod koniec dzialalnosci Clever People ;-)

Mam chyba gdzies jeszcze zrodla moich procedurek depakujacaych do PP20 wlasnie z Amigi, zreszta pomysl stary jak swiat, swego czasu "rilejzy" Bloody Coders byly pakowane wlasnie Amigowskim Power Packerem ;-) (np. Cavernia z logo Bloody Coders, ta w bazie plikow wlasnie jest spakowana PP20).

Potem jak mialem dostep do ST napisalem depacker do PACK-ICE z ST ;-) i kolejne "fajlowki" wlasnie nim pakowalem ;-) Musze poszukac zrodelek ;-) mam nadzieje ze sie dyskietki przeczytaja ;-)

pozdr
Seban/SLIGHT

2,933

(14 odpowiedzi, napisanych Software, Gry - 8bit)

Hej!

Tu moze sie zdarzyc jeszcze jeden problem. Kod gry moze caly czas przelaczac banki carta aby dostac sie do odpowiednich danych, tak wiec przepiswyanie danych z obszaru $4000-$7FFF w obszar $8000-$BFFF moze byc po prostu klopotliwe i moze uniemozliwic dzialanie gry ;(

Pamietam jak kiedys, Miker sie uparl aby zrobic mu z cart'a gry GATO wersje file ;-) Gra wlasnie caly czas przelaczala banki aby wykorzystac jakies dane. Nie wnikajac w kod gry (bo komu by sie chcialo kod relokowac), rozwiazalem to wlasnie w ten sposob ze wszystklie dane z bankow ktore znajdowaly sie w obszarach $8000-$bfff zostaly umieszczone w dodatkowych bankach i potem procedury przelaczajace banki w carcie zostaly podmienione na procedurke przepisujaca dane z bankow w obszar $a000-$bfff lub $8000-$9fff. Gra dzialala strasznie wolno poniewaz co klatke przelaczala sobie banki ;-) ale poniewaz i tak oryginal rysoawl i tak pare klatek na sekunde to dodanie jeszcze wiekszego spowolnienie nie spowodowalo makabrycznego spowolnienia ;-)

Trzeba by bylo zobaczyc jak czesto commando przelacza owe banki i mozna sie zastanowic czy da sie zrobic file ;-) Jezeli jednak robi to co np.  ramke to mozna zapomniec o wersji file ;-)

co do objetosci pliku, to wydaje mi sie ze dane z commado sie bardzo dobrze spakuja ;-) Plik pewnie nie byl by duzy, po spakowaniu jednak gra wymagala by pewnie troche rozszezonej pamieci ;)

Jezeli gra nie przelacza bankow co chwile to mozna by sie pokusic o dekompresje i przemieszczenie danych w odpowiedni obszar w chwili przelaczenia banku przez kod gry ;-)

pozdrawiam
Seban/SLIGHT

2,934

(19 odpowiedzi, napisanych Software, Gry - 8bit)

Witka!

wrzucilem na szybko na ftp.atari.art.pl:

ftp://ftp.atari.art.pl/upload/lasermania/

pozdrawiam
Seban/SLIGHT

2,935

(19 odpowiedzi, napisanych Software, Gry - 8bit)

Witajcie!

nie wiem czy to pierwsza wersja ale kawalek gral zespol New Order, a nazywal sie on: "Touched by the hand of God"

pozdrawiam serdecznie
Seban/SLIGHT

ps) a prawie dam sobie glowe uciac ze kawalek z "mission shark" tez jest coverem ;) sproboje poszukac. gdzies go chyba kiedys mialem, nie wiem czy to nie byl jakis .MOD ;-)

2,936

(149 odpowiedzi, napisanych Miejsca w sieci)

ja tez sie dorzucam oczywiscie ;-)

pozdr
Seban/SLIGHT

2,937

(149 odpowiedzi, napisanych Miejsca w sieci)

Witam!

To co robimy zrzutke? Kto bedzie trzymal kase? No i po ile sie dorzucamy?

pozdrawiam
Seban/SLIGHT

2,938

(18 odpowiedzi, napisanych Bałagan)

TL się odnalazł ... w Hiszpanii chyba ? Przecie trackera udostępnił

Witka!

No to wywiad z nim! wywiad prosze! Jak to sie wszystko zaczelo, dlaczego ATARI? skad pomysly na tak rewolucyjne jak na swoje czasy rozwiazanie? (chodzi mi o dwa kanaly sampli, jeden ze stala czestotliwoscia, drugi ze zmienna ;-)

Widzisz po trakerze nam niewiele ;( Fajnie ze moglismy zobaczyc jak to wyglada... jednak barak osoby ktora by cokolwiek w nim napisala ;-) Ja mam silne wrazenie ze tracker powstal pod sam koniec dzialalnosci TL'a, wczesniej muzyczki pisal chyba recznie ;) ale moge sie mylic ;-) dlatego chetnie bym zapytal go o pare szczegolow ;-) Ale talentu do robienia wywiadow nie mam wcale... wiec sie za to nie zabiore ;-(

edited: Tatqoo, a moze ty napiszesz jak sie to wszystko zaczelo? Dlaczego zaczoles pisac msx na Atari? przeciez tez jestes chodzaca legenda atarowskiej sceny! :) (i do tego nadal tworzaca z zapalem ;-)

Lublin i okolice to swego rodzaju "wylegarnia" milosnikow ATARI i FreeBSD ;-) nie pytajcie dlaczego, po prostu wydaje mi sie ze tak jest ;-)

pozdrawiam serdecznie
Seban/SLIGHT

2,939

(18 odpowiedzi, napisanych Bałagan)

Dobra, ale promujmy naszych muzyków, a nie komodorowskich!

Witaj!

No nie badzmy samolubni ;-)
Przeciez Rob Hubbard czy David Whittaker tez pisali na ATARI i to "zajefanje" kawalki. Moim zdaniem to ze dany muzyk tworzyl tez na C64 nie skresla go z listy muzykow Atarowskich. Poza tym trudno znalezc informacje o Atarowskich muzykach... ktos zrobil strone podobna do w/w??? Ktos odnalazl naszych rodzimych muzykow z tamtych czasow? (np. Jakub Husak czy Tomasz Liebich)? Ktos zrobil z nimi wywiady? Jezeli tak to wrzucie tu linki bardzo chetnie o tym poczytam ;-) Ci ludzie mnie fascynowali i nadal fascynuja, podziwiam ich tworczosc do dzis ;-) Jak na tamte czasy i robili "mega-zaje-fajne" kawalki ;-)

Do tego Pani ktora pisze prace moze porozmawiac z ludzmi takimi jak wlasnie np. Greg, Xray, BeWu, oraz wielu innych. Oni tworza do dzis i to na bardzo wysokim poziomie. Wywodza sie wlasnie ze sceny ATARI ;-)

Moze Dely lub Dracon,  ktorzy slyna z przeprowadzania spektakularnych wywiadow poniwien takze z nimi porozmwaiac ;-) Moze ktos sie pokusi o stworzenie kacika legend muzycznuch ATARI ;-)

Mysle ze skoro na w/w stronie sa materialy z ktorych mozna skorzystac (wywiady, wideo, itp.) To to iz strone zrobili ludzie bardziej zwiazani z C64 nie skresla jej jako zrodla informacji ;) Dzieki info z tej strony jezeli ta Pani bedzie chciala i miala checi bedzie mogla odnalezc tych ludzi i moze bedzie miala okazje z nimi porozmawiac osobiscie ;)

eee.... chyba za bardzo truje, dobra koncze ;-)

pozdrawiam serdecznie
Seban/SLIGHT

2,940

(18 odpowiedzi, napisanych Bałagan)

Hej!

Greg! Mysle ze ta Pani tuaj znajdzie ludzi ktorych szuka:

http://c64audio.valuehost.co.uk/edge/

pozdrawiam serdecznie
Seban/SLIGHT

2,941

(66 odpowiedzi, napisanych Scena - 8bit)

Czesc!

U mnie demko dziala w 100% poprawnie na emulatorze ;)
I pierwsza strona Ok, druga strona OK. Takze nie wiem o co wam chodzi ;-)

Co do dema.... autorom nalezy sie frasunek za design. Duuuuuuzoooo pracy wlozyli aby to wygladalo tak jak wyglada. Co tu duzo gadac, wyrazy uznania za chec zrobienia czegos wiecej od standardowego dema typu efekt za efektem :D Jest jeszcze jedna rzecz ktora wyroznia to demo... Kolory :-D Od czasow Visdooma (a.k.a. JAC!) nie pamietam rownie kolorowego dema ;-)

pozdrawiam
Seban/SLIGHT

2,942

(8 odpowiedzi, napisanych Software, Gry - 8bit)

Hej!

Swietny pomysl, teraz ludzie ktorym sie nie chce analizowac asmowego kodu moga zobaczyc, iz niektore efekty ktore pokazales w swiom demie sa o wiele bardziej skomplikowane obliczeniowo od np. wypelnianych czy teksturowanych wektorow ;-) Idealnym wrecz przykladem sa twoje przyslaniajace sie druciane wektorki ;-) Dla wypelnianych nic trudnego, proponuje jednak aby ktos sprobowal napisac sobie takie druciane sam ;-) Zobaczy wtedy iz algorytm nie jest taki oczywisty ;-)

pozdrawiam serdecznie
Seban/SLIGHT

2,943

(29 odpowiedzi, napisanych Zloty)

witajcie!

Mega-Giga WIIIEEEELLLLKIII Frasun dla Van Ejka!

Wspomnienia z przed 9 lat powrocily ;-)
Zajebis%^& impreza!
Zajebi#*( ludzie!
Zajebi^&& KLIMATY!

pozdrawiam wszystkich!
Seban/SLIGHT

2,944

(8 odpowiedzi, napisanych Software, Gry - 8bit)

Hej!

Jaskier! Mega-GIGA-Frasunek!

Cliping 2D, 3D ... ze Tobie sie to chcialo zaimplementowac ;-)
i do tego zajbis$%@#^%@ grafika BeWu ;-)

OldSchool Rulez!!!

pozdrawiam serdecznie
Seban/SLIGHT

ps) ahhh... stare dobre czasy! ;-) Czekam na Back2Life3 ;-)

2,945

(13 odpowiedzi, napisanych Sprzęt - 8bit)

Seban: co powiesz nt. odporności na zakłócenia ST7 (72F264) ? Używam ten scalak jako sterownik klawiatury w falownikach (takie maleństwa o mocach od 1 do 250kW) właśnie ze względu na hipotetyczną odporność na zakłócenia co nie jest dobrą stroną atmela. Być może masz własne spostrzeżenia ?

Czesc!

Powiem tak, seria ST6 ma wprost legendarna odpornosc na wszelkiego rodzaju zaklocenia ;-) Seria ST7 ktora stosuje w urzadzeniach klasy "Automotive" jest moim zdaniem rownie odporna ;-) I moim zdaniem zastosowanie serii S7 w tak "zasyfialym" srodowisku jakim jest praca w otoczeniu falownika to bardzo trafny wybor! ;-)

A tak z ciekawosci zapytam, co steruje praca falownika (znaczy jaki MCU)? Nie zajmiuje sie co prawda sterowaniem falownikami ale zdarzylo mi sie grzebac w UPS'ach firmy PowerWare serii 9, ktore to maja pelne przetwarzanie, tzn. w wielkim uproszczeniu prostuja sobie napiecie sieci, a potem falownik od nowa wytwarza czysta sinusoide na wyjsciu ;-) W starszczej generacji tychze UPSow widzialem jakas duza Motorole 68HCxx, natomiast w nowych siedza juz mikrokontrolery Hitachi serii H8 (obecnie chyba Renesas).

W moich projektach "samochodowych" gdzie az roi sie od roznego rodzaju zaklocen (maksymalnie zasyfiale zasilanie, silne pola elektromagmetyczne, sterowanie obwodami zawierajace duze indukcyjnosci i wszytkie inne mozliwe obciazenia), powiem ze seria ST7 sprawuje sie rewelacyjnie ;-) chociaz na PIC'ki od Microchipa tez nie moge narzekac ;-)

Podsumowujac, tak naprawde to kazdy MCU moze sie okazac zawodny jezeli niewlasciwie zaprojektujemy urzadzenie, odpowiednio zaprojektowane PCB, dobre zabezpieczenie lini wchodzacych i wychodzacych z MCU to daje nam juz 90% sukcesu. Ale w rzeczywistosci nie jest tak latwo ;( jezeli mam minimalizowac koszty urzadzenia i nie moge wlozyc parudziesieciu elementow aby bardziej uodpornic dany projekt na wszelkiego rodzaju zaklocenia, to musze powiedziec ze przy minimalnej ilosci elementow zewnetrzych wlasnie seria ST7 i PIC'e radza sobie najlepiej ;-)

uffff.... tyle apropos moich wnioskow na temat odpornosci MCU na zaklocenia ;-) teraz pare slow o architekturze 8051.

Tez myslalem ze architektura 8051 to przezytek i tylko stare dziadki sie tym zajmuja, postanowilem ta czesc segmentu olac i nie zajmowac sie rozwiazaniami historycznymi ;-)

Niestety teraz sie to na mnie msci, to czego unikalem jest prawie wszedzie !!!  Lata obecnosci tej architektury na rynku sprawily ze cale stada ludzi zna wylacznie ta architekture i projektanci/programisci dalej wybieraja architekture 8051. Prosty przyklad... zagladamy np. do urzadzen firm Posnet lub Optimus-IC (mowimy o kasach i drukarkach fiskalnych). Otoz co tam widzimy.... o zgrozo seria 8051. Dwoch niezaleznych producentow stosuje ta sama architekture... niestety :(

Ja rozumiem ze mozna projektowac nowe urzadzenia na nowych MCU i nie wykorzystywac takich archaicznych rozwiazac jakim jest seria 8051, ale tu mozemy zauwazyc jeszcze jedno zjawisko. Wszystkie wieksze firmy uparcie ciagna ta architekture rozwijajac ja niesamowicie. Przykladem takiego dziwnego dla mnie posuniecia sa MCU kompatybilne z 8051 o wydajnosci 100MIPS, o np tu:

http://www.silabs.com/products/microcontroller/

Nie jestem bron boze zwolennikiem architektury 8051, ale sam juz nie wiem co o tym myslec ;( wszyscy narzekaja ze to starocie, ze sa inne rozwiazania ale wszyscy je nadal wykorzystuja. Mysle ze jest to podyktowane bardzo duza iloscia ludzi ktorzy "wyrosli" niejako na tej architekturze i wlasnie ten fakt wykorzystuja firmy sprzedajace MCU zgodne z ta architektura ;)

Co do assemblerow hmmm....  powiem tak ja nie mam innego wyjscia ;( kompilartor C moge wykorzystac jak mam do dyzpozycji chociaz ze 4KB pamieci w MCU, jednak obecne projekty ktore wykonuje maja byc tanie, bardzo tanie.... wiec MCU ktore moge wykorzytac maja od 1 lub 2 KB pamieci, no w ekstremalnych wypadkach dostaje MCU ktore ma 4KB na kod programu, i nie wiem co bym nie robil to kompilator C mi nie pomoze, bo nie dam rady przy jego pomocy upchnac calego kodu w pamieci MCU ;(

jednak gdy mam do dyspozycji wieksza ilosc pamieci to nie mysle nawet o assemblerze tylko pisze wlasnie w C, jednak pewne fragmenty zawsze bedzie sie oplacalo napisac w ASM. Zreszta kompilator, kompilatorowi nie rowny ;) kazdy dziala inaczej i ma inne wymagania ;)

Tu jednak natrafiamy na druga strone medalu, sa procesory dla ktorych moim skromnym zdaniem pisanie w ASM zeczywiscie mija sie z celem, bo kompilator na pewno wykona robote lepiej od nas. Mysle ze dobrym przykladem moze byc tu procesory oparte o rdzen ARM. Tu pisanie w ASM to czysta herezja ;)

Zawsze chcialem opanowac programowanie DSP (np. Texas Instruments) jednak nigdy nie mialem wystarczajacej ilosci czasu aby sie za to zabrac, no i odstraszala mnie cena zestawow startowych i programatorow ;(

ufffff.... ale truje ;) pora konczyc.

Reasumujac, teraz nadchodzi era programowalnych ukladow logicznych, za chwila kazdy bedzie mogl sobie wlozyc dowolnego MCU do wiekszej Altery, Xilix'a czy Cypress'a. Jezeli nawet nie bedzie w stanie sam "zrobic" sobie wlasnego MCU w VHDL'u to zawsze moze skozystac z gotowego "jadra" dowolnego CPU, sa nawet projekty ktore udostepniaja cale "klocki" za darmo: http://www.opencores.org/

Motorola 68HC05, czy 8051, AVR czy cokolwiek innego na 300MHz nie ma problemu ;-) bierzemy gotowy projekt z opencores i wpakowujemy go do naszej programowalnej struktury logicznej ;-)

Na razie koszty jeszcze wysokie, ale juz za chwile stanie sie to popularne, wiec i tanie ;-) no coz przyslosc pokaze ;-)

na tym koncze moj wywod ;-)

pozdrawiam serdecznie
Seban/SLIGHT

2,946

(13 odpowiedzi, napisanych Sprzęt - 8bit)

Czesc!

Z moich szybkich poszukiwan wynika co nastepuje:

http://www.atmel.com/products/8051/ - atmelowskie zgodne z 8051 MCU

albo dokladniej, czyli gotowa lista:

http://www.atmel.com/dyn/products/devic … ily_id=604

pewnie zainteresuja cie sekcje:

#1)  Flash ISP (In-System Programmable)
#2)  Flash (Reprogrammable)

na poczatek mozesz probowac z malenstwami typu AT89C2051:

http://www.atmel.com/dyn/products/produ … rt_id=1938

na w/w stronach jest takze kupa dokumentacji ;-)
przyklady programow, gotowych urzadzen.
Atmel daje wiele aby przekonac do swoich mikrokontroerow ;-)

zreszta podobnie jest z Microchipem ;-)

Jezeli masz problemy z zakupieniem atmeli proponuje np:

http://www.seguro.pl/cgibin/shop?show=P … d=70382876

jak widac AT89C2051 kosztuje 5.36 juz z VAT ;-)

w/w sklep internetowy handluje glownie Atmelami wiec oprocz seri zgodnej z 8051 mozesz kupic takze AVR'y i ARM'y ;-)

http://www.seguro.pl/cgibin/shop?show=K … d=70382876

edited:
Przypomnialo mi sie ze jeszcze infineon produkuje sersie zgodna z 8051:

http://www.infineon.com/cgi/ecrm.dll/ec … ?oid=-8136

nie wiem jak z programatorami do tej serii, ale moze warto sprawdzic. Pojecia jednak nie mam gdzie to kupic ;-(

i jeszcze z tego co wiem Philips od wiekow promuje architekture 8051:

http://www.semiconductors.com/catalog/2 … html#45992

interesuje Cie sekcja "80c51 architecture", ale problem ten sam co wyzej. nie wiem gdzie kupic i nie wiem jak z narzedziami i srodowiskiem (IDE).



pozdrawiam serdecznie
Seban/SLIGHT

ps) troche to trwa zanim odpisze ale mam bardzo malo wolnego czasu ostatnio ;(

2,947

(13 odpowiedzi, napisanych Sprzęt - 8bit)

Jezeli nigdy nie miales doczynienia z mikrokontrolermai to proponuje nastepujaca lekture:

http://www.btc.pl/index.php?id=zmuk

potem musisz sie zdecydowac jakie mikrokontrolery chcesz programowac, i ile chcesz przeznaczyc pieniedzy na narzedzia. Z tego co wiem to bardzo popularne w polsce u poczatkujacych w tej dziedzinie sa mikrokontrolery firmy ATMEL. Programator mozesz dla nich zlozyc sobie sam, dostepne sa darmowe srodowiska programistyczne i darmowy AVR-GCC. Ja nie korzystam z produktow firmy ATMEL, wiec wiecej Ci powiedziec o nich nie moge.

Do wyboru masz jeszcze kontrolery takich firm jak: ST (seria ST6,ST7 jest bardzo podobna do budowa do 650x, arch. CISC), Motorola (seria 68HC podobna do 650x, arch. CISC), Microchip (latwe do opanowania RISC'owe mikrokontrolery, tylko 36 instrukcji, szybkie, ale bardzo drogie programatory/ICD), ZILOG (seria Z8, ale to chyba tylko dla milosnikow architektury Z80 ;-). I wiele, wiele innych.

Na poczatek chyba proponowal bym Ci rozpoczecie zabawy od MCU (mikrokontrolerow) ATMEL, mysle ze sa one na tyle popularne w polsce ze duzo ludzi bedzie moglo Ci pomoc w rozwiazaniu pierwszych problemow z programowaniem tychze ;-) Gdy wybierzesz ATMELa mozesz wybrac rozne drogi i rozne rozwiazania. Mozesz rozpoczacz przygode od Atmeli zgodnych z architektura MCS8051 lub probowac swoich sil z riscowymi mikrokontrolermai serii AVR. Mozesz pisac w czystym ASM'ie, mozesz uzyc kompilatora C, mozesz nawet zaczac od czegos co sie nazywa BASCOM. Nie wiem na jakim poziomie jestes i jak szybko beddziesz "lapal wiedze", ale sadze ze BASCOM moze byc dobrym rozwiazamiem jako pierwszy kontakt z MCU. Jedni mowia ze BASCOM wyrabia zle nawyki, inni twierdza ze wrecz przeciwnie. Ja nie mam jednak opnii bo go nigdy nie uzywalem ;) . Jezeli poczytasz sobie wiecej o BASCOM i stwierdzisz ze moze Cie to zainteresowac to ostatnio w pismie ktore sie nawywa Elektronika Plus (dodatek dla elektroniki dla wszystkich) byl BASCOM + plytka prototypowa na ktorej siedzial jakis ATMEL 90Sxxxx zgodny z 8051. 

http://www.sklep.avt.com.pl/go/_info/?id=8213

tam jest chyba pelny kurs BASCOMA i kompilator dla serii zgodnej z '51 i AVR.

Jezeli zdecydujesz sie na serie AVR to mozesz sobie kupic ksiazke:

http://www.btc.pl/index.php?id=avr

Osobiscie nie korzystam z MCU od ATMEL'a. Ja zajmuje sie MCU od ST,MICROCHIPA i toszeczke MCU od Motoroli. Koszt programatorow/debuggerow wspolpracujacych z IDE (mam na mysli srodowisko programistyczne) poszczegolnych firm jest nastepujacy:

MICROCHIP - MPLAB ICD2 -> 1100zl+VAT
ST  - InDart STX/D -> 1000zl+VAT
MOTROLA - nie wiem, bo dostalem za free ;-)
Zilog - $100

Z tego co wiem w przypadku ATMELA, mozna sobie samemu zmontowac programator/debugger za naprawde niewielkie pieniadze. Ale tu musza sie wypowiedziec inni, bo ja Atmelem sie nie zajmuje ;-)

Oczywiscie do MCU microchipa czy ST tez sa schematy prostych programatorow w sieci, jednak zaden nie zapewnie pelnej funkcjonalnosci z IDE dostarczonym przez producenta.

A jeszcze jedno, MCU ATMEL sa dostepne praktycznie wszedzie po przystepnych cenach i mozna bez problemu kupic pojedyncze sztuki. Z dostepnoscia innych MCU dla szarego zwyklego uzytkownika jest mniejszy lub wiekszy problem, jezeli juz ktos zechce sprzedac nam jakies MCU w niewielkiej ilosci to tak wywinduje cene ze nam sie odechce. Dystrybutorzy zupelnie inaczej podchodza do firm a zupelnie inaczej do osob prywatnych. Mysle ze jednym z powodow popularnosci ATMELA jest to ze jest on "wszedzie" ;-)

ufff... to chyba wszystko co chcialem napisac!

powodzenia zycze!

pozdrawiam serdecznie
Seban/SLIGHT

ps) w polsce panuje niestety dziwna opinia na temat MCU od ATMEL'a. Duzo ludzi twierdzi iz ATMELe sa bardzo nie odporne na "silne zaklocenia". Probowalem wypytywac kiedys, co znaczy ze sa nie odporne, jednak nikt nie udzielil mi konkretnej odpowiedzi ;-) Wiem ze to nie doczyty tematu jednak, moze ktos z was ma jakies opinie na temat odpornosci na zaklocenia MCU od ATMELa?

2,948

(16 odpowiedzi, napisanych Sprzęt - 8bit)

Do MacGyver'a:

Ufff.... Doszedlem do podobnych wnioskow... Ciesze sie ze ktos mysli tak jak ja :-) Potrzebowalem poparcia moich chorych teori przez osobe trzecia :-) Dzieki! 

I Seban: jakie przesunięcie 15% po ostatnim bicie??? Dlaczego ty te procenty dodajesz? Głodnemu chleb na myśli?"

ale o dodawaniu procentow pisal chyba MacGyver :-) A pozatym to bym sie chyba z nim zgodzil, ale przy zalozeniu poprawek Electrona :-) (co do bledu 15% wartosci bitu dla calej ramki  :-)

Czemu w tym wzorze jest +7 a nie +1. To bez sensu. Liczniki audf przecież zliczają w dół do zera i generują IRQ po jego przekroczeniu (bcc?). Więc przerwanie jest generowane po AUDF+1 cyklach. Błąd w druku? (7 jest podobne do 1, a w starych maszynach do pisania cyfry 1 nawet nie było i używało się np. T).

Pozwolisz ze zacytuje pare fragmentow dokumentacji, to chyba najwazniejszy fragment:

The frequencies given above are approximate. The Exact Frequency (Fin) that clocks the divide by N counters is given below (NTSC only, PAL different).

    FIN Approximate     FIN Exact
    1.79 MHz     1.78979 MHz           ? Use modified formula for Fout
    64 kHz     63.9210 kHz           ? Use normal formula for Fout
    15 kHz     15.6999 kHz            

The Normal Formula for output frequency is:

    Fout = Fin / 2N

Where N The binary number in the frequency register (AUDF), plus 1 (N=AUDF+1). The MODIFIED FORMULA should be used when Fin = 1.79 MHZ and a more exact result is desired:

    Fout = Fin / 2(AUDF + M)

Where:     M = 4 if 8 bit counter (AUDCTL bit 3 or 4 = 0)
      M = 7 if 16 bit counter (AUDCTL bit 3 or 4 = 1)

Tez nie mam pojecia skad sie biora wartosci 4 i 7, nie mam czasu na tak dokladne wnikanie w malo-czytelna dokumentacje POKEY'a :-( Dlatego prosilem was o wyjasnienie tego faktu.

Co ciekawe dopiero po zastosowaniu tego wzoru udaje sie osiagnac odpowiednie wyniki :-?

Czy te 19200 to ilość bitów danych przesłanych w ciągu sekundy razem z bitem stopu czy bez?

wydaje mi sie ze jest predkosc transmisji wszystkiego co pojawia sie na szynie, a wiec bity start i stop, niejeko naleza do calosci transmisji. Przytocze fragment Atari Hardware Manual (AHM):

The serial output data always changes when the serial output clock goes true. The clock then returns to zero in the centre of the output data bit time.
...
...
The baud (bit) rate of the data and clock is determined by audio channel 4 audio channel 2, or by the input clock, depending on the serial mode selected by bits 4, 5, and 6 of SKCTL. (See chart at end of this section.)

A jak wiadomo zegar (CLOCK) jest generowany przez polaczone kanaly 3 i 4.  Tak wiec wszystko co jest wystawiane na szyne danych jest synchronizowane przez sygnal zegarowy generowany poprzez polaczone kanaly 3 i 4, tak wiec  mysle ze bity start i stop takze nalezy liczyc :-)

Nie jestem pewien, ale POKEY przy wysyłaniu (SKCTLS = $23) wyrzuca na linię zegarową szybkość transmisji - może wystarczyłoby zmierzyć tutaj częstotliwość ?

Na poczatek parametry szyny:

# 1 start bit
# 1 stop bit
# 8 data bits
# no parity control
# 19200 bits per second

A i owszem, wyrzuca, ale tylko podczas transmisji bajtu danych,  a wyglada to tak:

                          One byte of SIO data
     
     
                    +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
                    | | | | | | | | | | | | | | | |        clock
       -------------+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +------
     
     
       ---------+       +---+   +-------+       +--------
                |     0 | 1 | 0 | 1   1 | 0   0 | 1        data
                +-------+   +---+       +-------+
     
                  |                                    |
     
              start bit                            stop bit

Czestotliwosciomierzem tego nie zmierze :-(, ATARI do pracy nie zaniose :-( A oscyloskopu cyfrowego z pamiecia w domu nie posiadam. Zmierze to wszytko jak tylko sobie POKEY'a do jakiegos mikro-kontrolera podlacze :-) i zaniose to do pracy gdzie mam odpowiedni sprzet :-)

Seban: W domu sprawdzę dokumentację... może z tym Twoim wzorem coś nie tak ?

to nie jest moj wzor, wziolem go z dokumentacji :-) Sam nie rozumiem tej magicznej liczby 7 ... hmmm... mam co prawda podejrzenie, ale musialbym miec bardziej czytelne dokumentacje POKEY'a... te maja za malo DPI :(

Zwroccie uwage prosze na opis rejestru $D208 (AUDCTL):

AUDCTL (Audio Control)(D208)

This address writes data into the Audio Mode Control Register. (Also see SKCTL two-tone bit 3 and notes).

D0 Change Normal 64 KHZ frequency, into 15 KHZ.
D1 Insert Hi Pass Pilter in Channel 2, clocked by Channel 4.
D2 Insert Hi Pass Filter in Channel 1, clocked by Channel 3. (See section II.)
D3 Clock Channel 4 with Channel 3, instead of 64 KHz (16 BIT).
D4 Clock Channel 2 with Channel 1, instead of 64 KHz (16 BIT).
D5 Clock Channel 3 with 1.79 MHz, instead of 64 KHz.
D6 Clock Channel 1 with 1.79 MHz, instead of 64 KHz.
D7 Change 17 bit poly into a 9 bit below poly.

Zwrocie prosze uwage na opis bitow D3,D4. W kazdej dostepnej literaturze bylo napisane ze dwa osmiobitowe liczniki sa laczone w jeden 16-bitowy. Jednak tu sugeruja iz na poczatku nastepuje podzial Fin przez kanal np. 3, a dopiero ta podzielona czestotliwosc jest dalej dzielona poprzez kanal 4. Z tego wynika ze nie jest to tak naprawde pelny 16-bitowy dzielnik, ale jakas dziwna hybryda.... albo ja juz nic nie rozumiem, albo oni tu cos sciemniaja :-) Moze to z tego wynikaja te magiczne liczby 4 i 7 we wzorach na Fout?

Dzieki Wszystkim za poswiecony czas! Ide walczyc... jezeli ktos bedzie mial jeszcze jakies pomysly lub nowe idee... prosze piszcze :-) Moze uda sie to wyjasnic :-)

A jeszcze jedno zdanie z dokumencacji dotyczace predkosci transmisji:

Input and output clocks are equal to the baud (bit) rate, not 16 times baud rate. Transmitted data changes when the output clock goes true. Received data is sampled when the input clock goes to zero.

Nie wiem dlaczego podkleslaja "not 16 times baud rate". hmmm. Ciekawostka.

pozdrawiam serdecznie
Seban/SLIGHT

2,949

(16 odpowiedzi, napisanych Sprzęt - 8bit)

Witam!

Panowie, potrzebuje waszej pomocy poniewaz moje obliczenia nie bardzo zgadzaja sie z rzeczywistoscia :-(  Chodzi i o wzor na dokladne okreslenie predkosci transmisji (bps) na podstawie wartosci wpisanej do rejestrow AUDF. Wedlug "tajnego" wzoru opublikowanego w ATARI HARDWARE MANUAL mozemy policzyc to tak:

Fout=1773447Hz/(2*(AUDUF+7))

Zakladajac iz transmisja kazdego bitu jest realizowana przy kazdej narastajacej krawiedzi zbocza zegarowego (a zegar jest generowany przez polaczone w tym momecie kanalu 3 i 4) mozemy przyjac ze predkosc transmisji jest rowna czestotliwosci wpisanej do rejestrow AUDF3,AUDF4. Jak wiadomo dla standardowej predkosci transmisji system operacyjny ATARI laczy kanaly 3,4 w celu uzyskania 16 bitowej precyzji, oraz wpisuje do rejestrow AUDF3,AUDF4 wartosc $0028.

Po podstawieniu tejze wartosci do wzoru mamy:

Fout=1773447/(2*(40+7))=18866.45745

...wiec obliczona predkosc transmisji oscyluje na poziomie 18866bps. Jednak zakladajac poprawnosc wzoru wydaje mi sie iz wartosc 39 byla by na tym miejscu bardziej odpowiednia, poniewaz wtedy predkosc transmisji wynosilaby:  19276 bitow/sek. (co jest juz blizsze wartosci 19200 :-)

Tu sie rodza moje watpliwosci... czy podany przez dokumentacje wzor jest nie poprawny, czy ja sie gdzies mijam z prawda w moim toku myslenia :-) Jezeli ktos wie jak to policzyc lub jest w stanie udzielic jakichs wskazowek prosze o informacje.

Zastanawia mnie jeszcze jedna rzecz... co sie dzieje w przypadku NTSC. Z tego co pamietam systemowe procedury transmisji szerwgowej nie sprawdzaja czy maja doczynienia z systemem PAL czy NTSC. Wiec w przypadku NTSC predkosc transmisji wynosila by:

Fout=1789772/(2*40+7))=19040

W tym wypadku jest to wartosc najbardziej zblizona do wartosci 19200 jaka da sie uzyskac przy taktowaniu POKEY'a zegarem 1.789722MHz. Wiec po prostu wyadje mi sie iz tworcy systemu operacyjnego nie brali pod uwage/nie przejmowali sie roznica zegarow dla systemow PAL i NTSC.

A moze jest ktos w stanie wytlumaczyc mi skad sie bierza magiczna liczba 7 we wzorze na Fout. Prawde mowiac nie mialem zbyt duzo czasu aby przyjrzec sie dokladnie dokumentacji POKEY'a. Moze ktos jest mi to w stanie wyjasnic i zaoszczedzi mi troche cennego czasu :-)

serdecznie pozdrawiam
Seban/SLIGHT

2,950

(5 odpowiedzi, napisanych Scena - 8bit)

Witam!

Panowie moze ktos bedzie w stanie pomoc wiec pisze tutaj :-)

Xsowi padl samochod  podczas powrotu z forevera :-(
Wraz z pasazerami utkneli w Dabrowie Gorniczej :-(
Juz udalo im sie dotrzec do sosnowca i wsiedli w pociag do czestochowy.
Wlasnie nim jada. Poniewaz pociag do warszawy bedzie dopiero okolo 3 w nocy (bez przesiadek). Moze ktos w czestochowie lub okolicach bedzie w stanie im w jakikolwiek sposob pomoc. Jezeli znajdzie sie ktos taki, podaje telefon komorkowy pod ktorym mozecie sie skontaktowac z nimi:

501-340-880

pozdrawiam wszystkich
Seban/SLIGHT