Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Projekt RE-FALCON 030 od Suavka Suavek, pracuje nad repliką płyty głównej Atari Falcon 030.
Fujisan 1.0.4 Wydano nową wersję Fujisan z krytycznymi poprawkami dla kompilacji i pakowania na Linuxie.
Test7800 0.5.1 Eksperymentalny emulator Atari 7800 Test7800, w wersji 0.5.1, wprowadza ważne usprawnienia w emulacji mapperów kartridży.
Generator okładek do kaset Nowy generator okładek na kasety magnetofonowe dla ośmiobitowych komputerów Atari od lexxa.
Nowa wersja emulatora Test7800 - 0.4.3 Eksperymentalny emulator konsoli Atari 7800 w nowej wersji 0.4.3 przynosi kluczowe poprawki w synchronizacji i wydajności.
atari.area forum » Posty przez tOri
Żadna wiedza tajemna nie jest potrzebna ponieważ należy prześledzić ścieżki od styków złącza carta do pamięci i porównać chociażby z opisem pamięci 27C256 - od razu się okaże co i jak. Poza tym na PCB jednak jest opis XE Supercart co sugeruje standardowy cartridge XEGS według tego linka:
http://www.atarimax.com/jindroush.atari … _docs1.jpg
pozdrawiam
To ciekawe - może to być związane z potencjometrem koloru? Poszukaj na płycie Atari w lewym dolnym rogu potencjometr R38 i delikatnie nim pokręć...
witaj,
self test jest w porządku czy tez nic nie widać?
pozdr
Witam,
Oj wieczór być może ale moje będzie mojsze ;-)
Tak seban - właśnie czuję, że powinienem już iść spać a siedzę i piszę na forum, hhehe...Taaa...
a poza tym MAM BARDZO WAŻNE PYTANIE ogólne - najpierw krótki opis:
Po rozmowie z mono wyszło, że najlepiej by było gdyby StereoSIDari wpasował się w obszar SOUND IO pod adresy $D240...$D27F. Z wielu względów byłoby to odpowiednie, chociażby dlatego aby mógł grać ze SlightSIDem na 4 SIDy. Co więcej - mam zamiar umożliwić przełączanie wajchą SIDari pod adresy $D500...$D51F czyli tam gdzie SligtSID aby zachować zgodność. Żadnych rejestrów ustawianych z Atari! Niestety poleci zgodność z Evie, jednak nie uważam, że to wielki problem zwłaszcza, że Evie też może się przełączyć w obszar $D5xx no i ktoś może chciałby "odpalić" np. SIDari, AY z Evie i SLightSIDa??? Taaaaa...
Pytanie brzmi:
czy ktokolwiek ma coś przeciwko zajęciu przez SIDari obszaru $D240..$D27F?
Zadaję to pytanie ponieważ chciałbym uniknąć kolizji z czymkolwiek. Nie chcę robić czegoś poważnego "na pałę". W Atariki widać, że pod tymi adresami NIC nie ma. Zbudowałbym pełny dekoder aby uniknąć problemów z zajmowaniem zbędnych obszarów.
pozdrawiam
EDIT: skoro się nikt nie odezwał w sprawie zajętości - rezerwuję obszar $D240..$D27F dla StereoSIDari, które będzie miało także możliwość przełączenia w obszar $D500..$D53F aby zachować zgodność ze SlightSID i Evie a także aby była możliwość gry na QuadraSIDari ;-)
A CPU się nie nada? Na pokeyu siedzi z reguły drugi pokey. Na Anticu - VBXE. Ja wiem ze na CPU moze siedziedz jakis rapidus.
Wiesz...w sumie może być :) OK - no to ostatecznie bedę może "sadzał" SIDari na CPU (choc to miejsce wolę zostawić na rozszerzenie RAM 1 MB) ewentualnie zrobię wersje CPU i ANTIC. Zdaję sobie sprawę z problemów mechaniczno-użytkowych ale jak wszyscy wiemy Atari JUŻ jest zapchane prawie "pod korek" więc niezbyt różowo widzę dalsze rozszerzanie w oryginalnej obudowie. Jak pisałem - ja już podjąłem decyzję o przekładce bo muszę mieć łatwy dostęp do hardware no i rosną mi różne piramidki na płycie ;) Nie każdy chce lub może ale nie da się zrobić tak aby wszyscy byli zadowoleni...
@toriman1: dobrze że projekt będzie się rozwijał smile ale napiszę też trochę żartobliwie smile No to chłopie wpadłeś jak przysłowiowa śliwka w kompot smile SID wciąga jak chodzenie po bagnach smile jak ulepszysz jedno będziesz chciał ulepszać następne ;] ale to dobrze, bo fajnie mieć taki projekt który cały czas się rozwija smile
Musi sie rozwinąć i dokończyć :) Wiem co mam zrobić i pozostało tylko wcielić projekt w rzeczywistość. Myślę, że zaniedługo dam radę :) a i co ważne - opublikuję raczej już całkowity schemat. Przetestowany i wbudowany do komputera.
W ogóle każde projektowanie wciąga - czasami tak, że o 3 nad ranem trzeba pomyśleć o tym, że i do roboty też trzeba będzie rano pójść - no i wtedy bywa nielekko.
A poza tym - będzie dobrze.
Pozdrawiam
Tak się zastanawiam z tym ANTIC'iem. Razem z VBXE to będzie już niezła kanapka i komp się nie zamknie na bank :) A jakie są alternatywy? Dużo jest tych sygnałów?
Cześć,
no - trochę jest :/
A0 - A7, D0 - d7, R/W, Phi2, +5V, GND - no to razem 20 do podciągnięcia. W sumie zamontować można gdziekolwiek łącząc po prostu przewodami. Ja - ze względu na brak ograniczeń (nie zamykam kompa pod klawiaturą) wrzucam tam gdzie mi jest wygodniej a na ANTIcu mam już TurboFreezera (tu mi się SIDari zmieści) i w zasadzie do "kanapkowania" pozostały mi już tylko GTIA, PIA oraz POKEy co się z pewnością zmieni po dołożeniu drugiego POKEYa i AKI. Planuje też dołożenie dodatkowego dekodera adresowego w obszar $D2XX - 16 x 16 adresów aby jak najlepiej wykorzystać przestrzeń IO.
Wiem, że to nie jest najlepsze ale Atari nie ma zbyt wiele miejsca pod klawiaturą, jednak w miarę dokładania kolejnych rozszerzeń nie będzie innej możliwości niż przełożenie całości do obudowy w formacie, np. MIDI - 43cm szerokości
(jak średnia wieża audio) - kiedyś być może pokażę moją przekładkę ale aby to nastąpiło muszę pokończyć wiele projektów :)
pozdrawiam
Witam,
Ciąg dalszy...
Siadam do SID stereo, identyfikatora #$33, nowej przetwornicy +5V -> +9V oraz mapowania adresów. Trochę czasu mi to zajmie bo muszę całość prawie od nowa projektować. Proszę o cierpliwość :) Gdy skończę - dam znać i opublikuję materiały na stronie. Problem odczytu rejestrów OSC3/ENV także zostanie rozwiązany - najprawdopodobniej poprzez ciągłe sprzętowe odpytywanie SID. Układ zrobi się spory objętościowo ale będzie widziany z zewnątrz prawie prawie tak jak prawdziwy SID.
Z pewnością nie planuję klonowania SLightSIDa - moje rozwiązanie docelowo ma być montowane wewnątrz komputera.
Ze względu na konieczność podłączenia kilku ważnych sygnałów płytka wyląduje jako nakładka na ANTIC - w 800XL.
Nad 65XE/130XE za bardzo się nie zastanawiam. Ewentualne adaptacje pozostawiam innym konstruktorom :)
Przynajmniej tak to na razie wygląda w planach.
Jeżeli ktoś sobie tego zażyczy - będę mógł podesłać wcześniej zaprojektowane, testowane na symulatorze lecz NIE w rzeczywistości - układy.
pozdrawiam
toriman1 napisał/a:Ano mamy podobne scalaki ponieważ to dobra praktyka aby w układach synchronicznych łapać zbocza a nie poziomy, hehe...
Ale to faktycznie ciekawe ponieważ widać podobne podejście do zagadnienia. Osobiście ciekaw jestem jak wygląda schemat pierwszego SlightSIDa :)Mam to jeszcze gdzieś na kartkach rysowane jeszcze "od ręki" ;-) jak znajdę w sowim bajzlu to zeskanuję i wrzucę. Popatrzyłem na Twój sch. Poszliśmy bardzo podobną ścieżka, czemu się nie dziwie bo inaczej się nie dało. tylko ja inaczej trochę generuje sygnały zatrzaskujące dla '574. Oraz to co nazwałeś na SCH "run-end" zrealizowane mam bardzo podobnie, tzn. wykorzystuje oczywiście asynch. kasowanie '74 do zasygnalizowania tej mini "state machine" że cykl zapisu do SID-a zakończył się właśnie :), no i nie mam 3-wejściowych NOR-ów.
Jeśli jeszcze gdzieś to masz no to wrzucaj - przynajmniej potomność też będzie miała szansę to zobaczyć ;)
Ja najpierw użyłem 74LS374 a potem zmieniłem na 574 bo te mają lepszą topografię do płytek testowych.
Reszta to szczegóły - jakieś różnice muszą być. Przyznam, że najpierw zacząłem swoje rozrysowywać a dopiero
sporo czasu po tym ujrzałem zdjęcia prototypu SlightSIDa.
Tak jak u Ciebie zatrzaskuję ADR na narastającym zboczu Fi2 (7402), dane na opadających (7400). Ty przedłużenie CS-a zrobiłeś na 3x INV ja zrobiłem 2xINV plus RC pomiędzy nimi (wiem że takich akcji się nie praktykuje w normalnym cyfrowym świecie, ale tak zrobiłem :] )
Logika - niezależnie od użytych elementów jest nieubłagana, hehe. Ten sam cel osiągamy w trochę różny sposób ale to dobrze bo widać różne podejście konstukcyjne. Ja najpierw użyłem także RC w pętli kasowania - dlatego są wogóle w układzie schmitty - bo przecież mogą być zwykłe 7404, ale pomyślałem, że takie coś słabo wchodzi do CPLD więc stanęło na łańcuchu inwerterów gdyby ktoś chciał to zapakować do Xilinxa lub Lattice. A w sumie to powinno dawać z 80 ns zapasu na /CS SIDA - aż nadto ale chciałem być tego pewien. Szkoda, że przerzutniki w GAL nie mają CLEAR bo sterowanie (oprócz 574) by się zmieściło - porzuciłem to i pojechałem po bramkach.
Będę dalej kombinował z SIDari - już otrzymałem kilka sugestii więc jest punkt zaczepienia.
pozdrawiam
A czy wyjście i wejście dźwięku wyprowadzone jest na zewnątrz czy zintegrowane na sztywno z dźwiękiem Atari?
Częstotliwość DOTCLOCK jest niezależna od zegara taktującego Atari czy jest to podzielony zegar Atari? Chodzi o to, czy w maszynach NTSC będzie to działało nadal z 985 kHz?
Pisałeś tam o 1773447 Hz a to częstotliwość Atari w PAL.Edit: Aaaa 17.73447 MHz :)
Układ 8701 trochę skomplikowanie wytwarza zegary. Ciekawe jest, że gdyby zrobić generator z kwarcem PAL Commodore i podzielić częstotliwość przez 10 - otrzymamy zegar PAL Atari :) tak na marginesie...
Taktowanie SIDa jest niezależne od taktowania Atari. Zapewne kawałki NTSC będą grały niżej choć już raczej nie wolniej bo to zależy bardziej od softu IMHO.
Wejście i wyjście można zrobić w sposób dowolny - osobiście "pożenię" audio wewnątrz komputera czyli dwa POKEYe i dwa SIDy z możliwością puszczenia dźwięku POKEY przez wejście SID.
Ano mamy podobne scalaki ponieważ to dobra praktyka aby w układach synchronicznych łapać zbocza a nie poziomy, hehe...
Ale to faktycznie ciekawe ponieważ widać podobne podejście do zagadnienia. Osobiście ciekaw jestem jak wygląda schemat pierwszego SlightSIDa :)
No i faktycznie jest to Open Hardware - działający pomysł jest na wierzchu... Niech ludzie zaszaleją :)
Ciekawostką dla mnie jest to, że powstało tak niewiele układów sprzegających SID z Atari (a olbrzymia większość w Polsce, hehe) Podstawowy układ nie jest wcale skomplikowany a jednak nie było wielu chętnych.
Dzięki Seban za sobre słowo - przyda sie na przyszłość.
pozdrawiam
P.S. Wrzuciłem materiały na stronę pod link SIDari - zapraszam do poczytania
toriman1 napisał/a:a Evie i SlightSID odczytują te rejestry bo nie kojarzę???
Zarówno Evie, jak i SlightSID pozwalają na odczyt dowolnego rejestru SID-a. Ale każde z nich nieco inaczej :D:
- Evie: odczyt bezpośrednio przez adresowanie rejestru np.:lda $D2C0+$1C- SlightSID: za pośrednictwem rejestru adresującego np.:
lda #$1C sta $D540 nop nop nop lda $D540analogicznie dla drugiego SID-a indeks $3C (drugi SID leży w $D520..$D53F, indeksy rejestrów zaczynają się od $20).
Jasne... jak napisałem wcześniej - rozważam dodanie odczytu dwóch rejestrów OSC3 ENV3 bo są najważniejsze. W zasadzie polling byłby tu najlepszy ponieważ odczyt załatwiałoby sie jedna instrukcją jak w oryginale.
:) dzięki za podpowiedzi.
No tak, bo teraz to miniaturka :D Dasz rade z tym zamknac obudowe? ;)
Miniaturka hehe
No i trzeba będzie CPLD użyć uf...
Tak to jest rozwiązane w SlightSID-zie. Z SID-a warte czytania są dosłownie 2 rejestry:
- 27(dec) OSC3/RANDOM
- 28(dec) ENV3
bo POTX i POTY się nam chyba nie przydadzą.
Namawiałem zarówno Sebana, jak i Pasia do ich implementacji, więc również namawiam i teraz przy okazji SIDari. Taki dokument mówi, że mogą być używane do uzyskania specyficznych softwareowych efektów. No i są używane do rozpoznania rodzaju SID-a.
Na TTLach będzie kłopotliwie. Nie to, że się nie da ale duże będzie :)
pozdrawiam
P.S. Mono - a Evie i SlightSID odczytują te rejestry bo nie kojarzę???
toriman1 napisał/a:Przy zastosowaniu mikroprocesora jest to możliwe - jednakże mikroprocesor musiałby wykonywać ciągły polling rejestrów SID aby nie zostać zaskoczonym przez "niespodziwany odczyt" hehe).
A nie można wykorzystać patentu z YM/AY, że mamy specjalny rejestr, do którego program zapisuje nr rejestru I/O, który chce odczytać, a drugim rozkazem odczytuje z niego daną? To eliminuje problem "ciągłego pollingu", ale czy to przydatne, musiałby się np. mono wypowiedzieć.
Raczej nie bardzo da się to wykorzystać jak w YM/AY ale wygląda to zastanawiająco podobnie.
Proces odczytu rejestru powinien wyglądać mniej więcej tak:
Krok 1 - wysłanie cyklu odczytu spod adresu np. LDA $D51B - OSC3/Random - powoduje zapamiętanie adresu rejestru do odczytu ($1B) i uruchomienie logiki odczytu z SIDa, czyli na liniach adresowych SID już jest adres rejestru, generowany jest lokalny CHIP SELECT, R/~W jest równy 1 i na tylnym zboczu PHI2 SID logika sprzęgu wpisuje dane do rejestru do odczytu, np. 74HCT574. W tym kroku już wysyłam więc adres rejestru.
Krok 2 - mając już zapamiętane w lokalnym rejestrze dane wysyłamy drugi raz cykl odczytu spod adresu, LDA $D51B i wtedy odczytujemy dane blokując jednocześnie kolejny cykl odczytu z samego SIDA.
Nie da rady zrobić tego w jednym kroku. Rozwiązaniem jest mikroprocesor albo takie zbudowanie logiki aby wykonywała sprzętowy polling tych czterech rejestrów READ ONLY - $19, $1A, $1B, $1C w czasie wolnym. Gdyby jednak trafił się zapis lub odczyt - odpytywanie musiałoby zostać wstrzymane.
Jak widać - da się ale dosyć komplikuje i rozbudowuje układ no i czas dostępu do danych odczytanych staje się dosyć długi (ale to by za bardzo nie przeszkadzało mimo wszystko). Dalej uważam, że skórka jest niewarta wyprawki...Gdyby większa ilość muzyki używała OSC3/ENV3 no to trzeba by było zbudować takie rozwiązanie.
pozdrawiam
Jakie fajne! Jak na teteelach, to i koszt znikomy. Jak będziesz robił płytkę, to od razu rób smd :)
A, niezła wieżyczka w komputerze. A mógłbyś jeszcze klawiaturę pokazać? Strasznie ciekawi mnie co jest po drugiej stronie tęczowego multikabelka.
Po drugiej stronie tęczowego kabelka jest klawiatura 800XL w pustej obudowie :) Nic ekstrawaganckiego ale musiałem tak zrobić aby mieć jakiś kontakt z Atari. Planuję AKI i obudowę taką od MIDI wieży (43cm szerokości). Wieżyczka niezła i będzie jeszcze nieźlejsza, hehe. Właduję tam jeszcze kilka rzeczy. Mam około 7 centymetrów do wykorzystania w 3D...
Odczyt dowolnego rejestru SID-a ($d500..$d51f) zwraca wartość $33 niezależnie od ilości sidów. Inny SID jest przecież w inym obszarze adresowym więc tam zwraca swoje $33.
Jedna jeszcze rzecz. Jeśli to nie jest jakiś strasznie kosmiczny problem zachęcałbym do wyprowadzenia wejścia EXTIN na zewnątrz, bo to pozwoli na filtrowanie przez SID-a dowolnego sygnału - np. dźwięku z POKEY-a.
Tak zgadza się - nie zrozumiałem do końca :) uważałem, że sam odczyt z $D500 powinien dać od razu liczbę SIDów w obszarze ale to szczegół - ok wystarczy odpytać znane obszary i tyle.
EXTIN jest przewidziany do użycia tak jak w standardowej aplikacji SIDa
pozdrawiam
Trzeba by zapytac Sebana, ale mi sie wydawało, ze kazdy SID zwraca $#33 na swoich portach.
No - nie każdy ponieważ dla SIDari odczyt z obszaru $D5xx idzie "do lasu" i najpewniej powinno dać $#FF tak jakby nic tam nie było :) - no bo i z punktu widzenia logiki - nic nie ma do odczytu więc Atari zobaczy szynę danych podciągniętą do +VCC.
sprawdzales czy SIDari dziala z SlightSID Playerem 3.x http://xxl.atari.pl/?page_id=708
?
Nie sprawdzałem ale skoro SlightSID działa to i SIDari też musi działać. Będę miał chwilę do ogarnięcia się to i powinienem sprawdzić.
Pozdrawiam
Dzięki. Co do odczytów z rejestrów - SlightSID (możliwe, że Evie też) przy próbie odczytu z rejestrów SIDa zwraca wartość $33 - dałoby się to zrealizować? Łatwiej byłoby rozpoznawać czy SlightSID/SIDari jest na pokładzie i w jakiej ilości (2, 3, n układów).
OK - w dalszej części projektu siądę nad tym - to jest proste do realizacji ale jeden scalak więcej dojdzie
Rozumiem, że pojedyńczy SID spod adresu $D500 ma dać odczyt $#33 a, np. dwa SIDy już $#34 (#$32 + 2) a takie coś najlepiej ustalić zworkami - coś w tym stylu :)
Co do portow, to mozna by zamapowac oba zakresy, tak jak to robi Evie. Autoamatycznie uzyskałbys kompatybilnosc ze slightSID i Evie, wiec całe tony softu, ktore juz niedługo powstana ( ;) ) beda to obsługiwac.
To jest do przemyślenia - to w zasadzie tylko pytanie jak rozwiązać dekodowanie obszarów IO.
Osobiście planuję zrobienie sobie wewnętrznego dekodera 16x 16 adresów w obszarze $D2XX i stąd będę brał CHIP SELECT zarówno dla POKEYów jak i SIDów a także dla innych modułów dźwiękowych o ile będą. Evie też wpisuje się w ten schemat. Gorzej z mapowaniem pod $D5XX - to trochę wrażliwe miejsce jak na umieszczanie takich rozszerzeń.
Zobaczymy :)
Pięknie!
1. Można prosić o jakąś specyfikację?
2. Jak to się zachowuje na szynie (czy rejestry są tylko W, czy są też R a jeśli nie to jak się zachowują)?
3. Czy można to jakoś wykryć?
4. Czy jest 8580R5 czy przewidziane są inne układy (ja wiem, że napięcia i takie tam)?
5. Czy przewidziana jest wersja z 2 (3?) SIDami?
6. Jaką częstotliwością jest taktowany SID?
Wbudowałbym support do mojego playerka...Edit: Pytania.
Teraz tak na szybkiego odpowiem a dokładne opisy pojawią się dosyć szybko na mojej www, po kolei:
1. Specyfikacja :) to SID standard więc wszystko co dla komody jest i tutaj
2. Rejestry są wyłącznie do zapisu co jest związane z tym, że niesłychanie trudno wykonać logice skok "w przyszłość" a dlaczego tak jest? Gdy układ nie jest połączony z systemem bezpośrednio wtedy zapis da się wykonać bez problemu ponieważ najpierw Atari wpisuje dane do rejestrów bufora wejściowego (z perspektywy SID) a w drugim kroku sprzęg wpisuje dane do SIDa i to działa (będzie to widać na schemacie) Gdy jednak chcemy odczytać dane - jeden cykl odczytu nie wystarczy ponieważ to dopiero wpisze dane do rejestrów bufora wyjściowego - DOPIERO PO WYKONANIU DRUGIEGO CYKLU uda się odczytać dane z bufora dla Atari - to poważnie komplikuje zarówno układ jak i software i ze względu na nikłe korzyści z tym związane odczyt rejestrów SIDa nie jest możliwy. Przy zastosowaniu mikroprocesora jest to możliwe - jednakże mikroprocesor musiałby wykonywać ciągły polling rejestrów SID aby nie zostać zaskoczonym przez "niespodziwany odczyt" hehe). Podsumowując - WRITE tak, READ nie.
3. W obecnej postaci nie. Można oczywiście dodać pod wybranym adresem jeden rejestr do odczytu z konkretną wartością identyfikującą układ. Nie planowałem tego ale to żaden problem. Kwestia adresu i danej, która ma tam być (jako dana typu ROM)
4. Są pewne różnice odnośnie 6581 i 8580 - jedna to napięcie zasilania analog - 6581 - 12V, 8580 - 9V - co oczywiście zależy jak się zbuduje zasilacz, przetwornicę - to można zrobić stosunkowo łatwo, czyli zworką. Druga różnica to kondensatory filtrów - 6581 ma 2x 470 pF a 8580 ma 2x 22nF - myślę, że też ewentualnie mogłoby to być na zworkach ale się zastanawiam czy jest sens. Najlepiej zrobić pod konkretny układ. Wyboru zbyt dużego nie ma :)
5. Nie ma żadnego problemu z większą ilością SIDów poza miejscem w IO komputera. Układ wystarczy powielać w zależności od potrzeb - logika sprzęgu w sporej części nie może być wspólna niestety. Będzie schemat wszystko się wyjaśni.
6. Taktowanie SID jest identyczne jak w C64 PAL ponieważ zastosowałem oryginalny kwarc 17.73447 MHZ oraz układ 8701 i po podzieleniu DOT CLOCK 7.88 MHz przez 8 jest 985 Khz z możliwością delikatnej regulacji trymerem.
Chciałem zbudować układ przy pomocy takich scalaków jakie były stosowane w dawnych czasach :) Lubię oldskul...
Oczywiście można i da się wrzucić logikę w jakiś ukłąd CPLD tak jak w SLightSID. Zostawię to jakiemuś ochotnikowi - ja zajmę się być może kolejnym atarynkowym projektem. Chociaż nie przesądzam - chcę poćwiczyć CPLD - mam garść ispLSI LATTICE i może tam wrzucę interfejs?
Od strony Atari ten sprzęg będzie widoczny dokładnie tak jak SightSID więc wszystko co będzie dla SlightSIDa zadziała i tutaj.
To było na razie tyle
pozdrawiam
Aj tam - śpiący jestem ;) a moderatora poproszę w takim razie o przeniesienie wątku.
Witam!
Miło mi poinformować, że na ukończeniu jest projekt analogiczny do SlightSIDa. Niezbyt skomplikowany i oczywiście jak wszystko u mnie - Do It Yourself :). Po wprowadzeniu kilku modyfikacji schemat i opisy pojawią się na mojej stronie.
W obecnej chwili bezbłędnie odtwarza muzę z SID Playera Świętego (dzięki za soft!) i w zasadzie pozostała kosmetyka.
Całość została zbudowana na oldskulowych TTLach więc szału nie ma. Mimo, że obecnie przebywa na stronie $D5xx - docelowo mam zamiar zrobić wersje wewnętrzną i umieszczoną nad POKEYami w obszarze IO.
Załączam zdjęcie układu prototypowego.
Pozdrawiam
To może być MMU - uszkodzony układ często stwarza wrażenie jakby ROM był padnięty i jednocześnie z RAM potrafi paść FREDDIE. Miałem dwukrotnie taką awarię. Czyli: RAM, MMU i FREDDIE.
pozdr
Przebiegi wziąłem z układu "powielacza" zmontowanego dokładnie według schematu z Twojej strony. Najprostszą metodą "naprawy" wydaje mi się dołożenie małego potencjometru wieloobrotowego i podstrojenie częstotliwości (przy odłączonym Phi2) na minimalnie (0,5-1%) mniejszą od 4xPhi2. Ale nie wydaje mi się, żeby to mogło działać w 100% niezawodnie z każdym zasilaczem i przy różnych temperaturach. To już chyba lepiej by było zrobić prymitywny mnożnik asynchroniczny na bramkach EXOR, jak na załączonym rysunku. Ja bym tu jednakowoż sięgnął po PLL => pewność i zaufanie. :)
Schemat z freezera - a - oki :) no w sumie wystarczy wziąć przecież ten kawałek - do obejrzenia co się dzieje wystarczy.
Co do pewności - ja bym także był za PLL. W końcu tu chodzi o zaufanie ;) Gdy bedę miał chwile wolną - zmontuję coś aby ruszyło. Spróbuję dać na początek trymer do kondera 180pF, ewentualnie zmienię na mniejszy i też z trymerem "zaszaleję". Popatrzę sobie jak regulacja wpływa na przebiegi i działanie freezera. Zmontuję tylko kolejną sztukę na złącze krawędziowe bo na wewnętrznym trudno eksperymenty robić. Dam znać czy uda mi się naprawić ten problem.
pozdr
atari.area forum » Posty przez tOri
Wygenerowano w 0.218 sekund, wykonano 13 zapytań
