3 bajtem najstarszym,¢ a1 - najm odszym)¢ zawieraj⇧ca cz❎③⇨ u amkow⇧ c1 wpisywa-¢ n⇧ do CxIND. Czyli innymi s owy uk ad¢ dodaje fizycznie liczb❎ dwubajtow⇧ do¢ czterobajtowej, ale najm odszy bajt¢ adresu to cz❎③⇨ u amkowa, bo w a③ciwy¢ adres znajduje si❎ w starszych 3 baj-¢ tach, zawieraj⇧cych cz❎③⇨ ca kowit⇧¢ Tak wi❎c dla uproszczenia budowy uk a-¢ du CxIND powinien znajdowa⇨ si❎ tuə¢ przed CxADR, stanowi⇧c z nim jedn⇧¢ ca o③⇨ 32-bitowego adresu.¢¢ Bardziej opatologicznie juə nie¢ potrafi❎. Jeəeli masz problemy z tymi¢ u amkami, to zajrzyj do Seriousa o ile¢ dobrze pami❎tam numer #10, gdzie¢ Krger w artku pt. "Siedemnastobitowa¢ arytmetyka" bardzo rzeczowo opisa ten¢ temat.¢¢ Przyk adowo odtwarzanie sampla tak,¢ jak jest zapisany w pami❎ci, czyli¢ bajt po bajcie, musi rozpocz⇧⇨ si❎¢ wpisaniem 0 do CxIND, adresu pocz⇧tku¢ sampla do CxADR, adresu koca sampla¢ do CxEND, adresu pocz⇧tku p❎tli do¢ CxREP, i w kocu $0100 do CxFRQ.¢¢¢ Dlaczego aqrat tyle? Bo wtedy u amkowa¢ cz❎③⇨ adresu nie jest w ogle ruszana¢ (dodawanie zera), w kaədym cyklu¢ POVOXa do ca kowitej cz❎③ci adresu do-¢ dawane jest 1 (starszy bajt CxFRQ),¢ wi❎c prbki s⇧ puszczane po kolei.¢¢¢ Odtwarzanie sampla oktaw❎ niəej¢ realizuje si❎ przez wpisanie $0080 do¢ CxFRQ, a oktaw❎ wyəej - CxFRQ=$0200.¢¢ Jasne?¢¢ I wszystko by oby pi❎knie, gdyby nie..¢ moja dzika fanaberia ze zmian⇧ g o③-¢ no③ci. Domy③lam si❎, əe o ile dodawa-¢ nie moəna zrealizowa⇨ w do③⇨ prosty,¢ dzia aj⇧cy szybko sposb, o tyle uk a-¢ d wykonuj⇧cy odpowiednie dzielenia w¢ wystarczaj⇧co krtkim czasie by by¢ chyba zbyt skomplikowany, a nawet je③-¢ li nie, to pewnie zbyt drogi.¢ A w ogle - po co robi⇨ uk ad o moəli-¢ wo③ciach arytmetycznych przewyəszaj⇧-¢ cych CPU, tylko do puszczania sampli?¢ No? Dlatego maj⇧c typowo koderski na-¢ wyk tablicowania wszystkiego, co si❎¢ da, proponuj❎ do oəenie EPROMki zawie-¢ raj⇧cej tablice g o③no③ci.¢ Jeəeli ustali⇨ 32 poziomy g o③no③ci¢ oraz poziom "0" - cisz❎ (jak w Neo),¢ to tablice zajmowa yby rwno 8kB, przy¢ czym w tablicach pomijamy ow⇧ cisz❎,¢ bo uk ad moəe atwo wykry⇨, əe jest¢ wpisana g o③no③⇨ 0 i po prostu bez¢ əadnej zabawy wpisa⇨ 128 do w a③ciwego¢ rejestru COVOXa, ewentualnie rozpozna⇨¢ maksymaln⇧ g o③no③⇨ i po prostu prze-¢ pisa⇨ sampla, z pomini❎ciem tablicy.¢¢¢ No i fajnie by by o, gdyby te tablice¢ by y numerowane tak jak w Neo- i Pro-¢ Trackerze, czyli parzystymi numerkami¢ z zakresu 0-64.¢¢ My③l❎, əe jest to jasne. No a je③li¢ nie... to wiesz, co masz robi⇨! ;>¢¢ To tyle opisu szczeg owego, a teraz¢ rozpiska algorytmu, ktry mia by¢ realizowa⇨ opisywany interface¢ w kaədym swoim cyklu. Jest taki j❎zyk,¢ ktry nazywa si❎ BASIC. Moim zdaniem¢ jego najlepszym zastosowaniem jest¢ przedstawianie algorytmw w formie¢ krtkiej, zwi❎z ej i zrozumia ej.¢ Wi❎c... jak nie znasz BASICa, to...¢ nie wracaj si❎ do podstawwki, tylko¢ czytaj Zientar❎! hehe... ;>¢ Jest ma e ale... Otə tym razem¢ zastosuj❎ nieco zmodyfikowany TBXL, bo¢ mamy co③ takiego jak s owa 3-bajtowe¢¢¢ (24 bity), wi❎c odpowiednie dla nich¢ POKE i PEEK to TPOKE i TPEEK, analo-¢ gicznie jak dla 2-bajtowych s⇧ DPOKE¢ i DPEEK. A əe s⇧ teə s owa 4-bajtowe¢ (PEEK(CxIND)+TPEEK(CxADR)*256), to dla¢ uproszczenia zastosujemy do nich inst-¢ rukcj❎ QPOKE i funkcj❎ QPEEK. Jak¢ przebiega adresacja, to juə wiemy.¢¢ . pobranie danych z pami❎ci¢ 10 CPUHALT=1¢ 15 A=PEEK(TPEEK(C°ADR))¢ 20 CPUHALT=0¢¢ . wpisanie do COVOXa¢ 25 IF PEEK(C°VOL)=$40¢ 30 POKE COVOX°,A¢ 35 ELSE¢ 40 POKE COVOX°,VTAB(PEEK(C°VOL) DIV¢ 2,A)¢ ewentualnie:¢ 40 POKE COVOX°,EPEEK(PEEK(C°VOL) DIV¢ 2*128+A)¢ 45 ENDIF¢¢ . aktualizacja adresw¢ 50 QPOKE C°IND,QPEEK(C°IND)+DPEEK(C°FR¢ Q)¢ 55 IF TPEEK(C°ADR)>=TPEEK(C°END) THEN¢ TPOKE C°ADR,TPEEK(C°REP)¢¢ Takie "co③" kopiujemy cztery razy,¢ za "°" podstawiaj⇧c kolejno 1,2,3 i 4.¢ No i par❎ s w komentarza:¢ Do pierwszej cz❎③ci - umwmy si❎, əe¢ stan zmiennej CPUHALT odzwierciedla¢ stan blokady kompa. 1 oznacza, əe¢ praca 6502 jest wstrzymana. Oczywi③cie¢ ANTICa teə. O ile mi wiadomo, 6502 ma¢ moəliwo③⇨ zablokowania przez podanie¢ odpowiedniego sygna u na pin HALT (ty-¢ lko w ATARI), ale z ANTICiem b❎dziecie¢ si❎ chyba musieli troch❎ pom❎czy⇨.¢ Do cz❎③ci drugiej - sprawdzamy, czy¢ g o③no③⇨ jest maksymalna, w praktyce¢ wystarczy sprawdzi⇨ stan bitu 6 (li-¢ cz⇧c od 0) - jeəeli jest ustawiony,¢ to g o③no③⇨ jest maksymalna, wi❎c¢ przepisujemy prbk❎ prosto do COVOXa.¢¢¢ W przeciwnym razie pobieramy warto③⇨¢ z tablicy w EPROMce, gdzie m odszy¢ bajt adresu w EPROM to bajt pobrany¢ z pami❎ci, a starszy sk ada si❎¢ z bitw 5-1 CxVOL. Funkcja EPEEK odpo-¢ wiada w a③nie za pobranie bajtu¢ z tablicy w EPROM.¢¢ Cz❎③⇨ trzecia jest chyba zrozumia a.¢ "Dodawaczk❎" (element ALU) na upartego¢ moəna z oəy⇨ nawet z "paru" ;) bramek¢ logicznych.¢¢ Aha. No i jeszcze rejestr CVCTL.¢ Pierwsze, co przychodzi logicznie¢ my③l⇧cemu cz owiekowi do g owy, je③li¢ chodzi o kontrol❎ uk adu, to (co jest¢ chyba jasne) jego w ⇧czanie i wy ⇧cza-¢ nie. Do tego wystarczy jeden dowolny¢ bit tego rejestru. Jeəeli ma w asny¢ zegar, o cz❎stotliwo③ci powiedzmy¢ 31kHz, bo taka jest potrzebna, je③li¢¢¢ odtwarzamy co p linii (dla zaokr⇧-¢ glenia moəna przyj⇧⇨ 32kHz), to kaədy¢ impuls takiego zegara powoduje¢ wykonanie algorytmu, nad ktrego¢ opisaniem tyle si❎ juə napoci em, əe¢ mam juə do③⇨... Ale kto③ moəe zechcie⇨¢ wrci⇨ do 15.5 kHz, czyli co 1 lini❎,¢ i przyda aby si❎ moəliwo③⇨ ustawienia¢ takiego trybu, əe odtwarzania prbki¢ powodowa by tylko co drugi impuls.¢ Fanatycy, ktrzy zrealizuj⇧ ultra-¢ szybki uk ad mog⇧ wsadzi⇨ zegar 62kHz,¢ a wtedy to nawet grzybiarzom ga y¢ wyjd⇧ na wierzch, byleby by a moəli-¢ wo③⇨ redukcji do 31 i 15.5 kHz, ewen-¢ tualnie 20.67kHz (62/3). I to by by¢ jedyny przypadek, gdzie przyda by si❎¢ prosty dzielnik cz❎stotliwo③ci.¢¢ Natomiast jeəeli nie masz ochoty na¢ zabaw❎ z zegarkami i dzielnikami¢ cz❎stotliwo③ci, to mam ciekaw⇧¢ alternatyw❎: jakikolwiek wpis do¢ CVCTL powoduje wykonanie "procedurki".¢¢ I to juə w a③ciwie wszystko.¢¢ Hmm... domy③lam si❎, əe praktyczna¢ realizacja powyəszych postulatw moəe¢ by⇨ trudna, a ca y ten "POVOX" moəe¢ mie⇨ rozmiary i cen❎ wi❎ksz⇧ od samego¢ kompa... Ale... To wszystko tylko¢ wymys y mojej wybuja ej wyobra♪ni,¢ sprowokowanej przez przygody przy¢ pisaniu procedury odtwarzaj⇧cej sample¢ na COVOXie. W wi❎kszo③ci komputerw¢ uk ady odpowiedzialne za generowanie¢ grafiki czy d♪wi❎ku odci⇧əaj⇧ w duəym¢ stopniu procesor w tych dzia aniach,¢ wi❎c dlaczego Atarka mia aby pozosta⇨¢ w tyle?¢¢ Tak w ogle, to zastanawiam si❎, czy¢ moəe to mie⇨ jaki③ sens, skoro Pasiu¢ ci⇧gle udoskonala swoj⇧ "S odk⇧¢ szesnastk❎" i moəe zamiast pisa⇨ wer-¢ sje dla "POVOXa", zrobi bym te same¢ dla 65c816 z zegarem powiedzmy 16MHz,¢ oczywi③cie w trybie natywnym... Co...?¢¢¢ Tylko czy Turbo-816 b❎dzie na tyle¢ dost❎pne? Tak czy inaczej nie zapomn❎¢ nigdy o posiadaczach "starego" COVOXa¢ (jak to adnie brzmi...) i ci⇧gle b❎d⇧¢ mieli nowe moəliwo③ci NeoTracker-a,¢ ale przy cz❎stotliwo③ci 11.7 kHz... :(¢¢ Powodzenia i... mi ej zabawy :) przy¢ pracy ;> nad "POVOXem" əyczy¢ epi/Allegresse¢¢ pe|es: wiem, əe juə chc❎ o wiele za¢ duəo, ale nie bijcie, dobra? ...¢ Moəe by tak jeszcze POVOX dzia a ¢ w drug⇧ stron❎, to znaczy zamiast¢ przepisywa⇨ dane z pami❎ci na wyj③-¢ cie audio, przepisywa by je z wej③-¢ cia (przez przetworniki A/D) do¢ pami❎ci? To by by o cudo. :)¢ ...¢ A ! Au! AAAAAAAA! Prosi em, əeby nie¢ bi⇨! Aaauuuu!!! Dooobra... spadam!¢
