Przejdź do treści forum
atari.area forum
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
Opcje wyszukiwania (Strona 42 z 49)
Zrobiłem sobie remanent w scalakach i wyszło, że mam kilka sztuk w zasadzie zbędnych już WD1770 i WD1772, za to brakuje mi (przynajmniej) dwóch POKEY-ów i (przynajmniej) jednego FREDDIE-go. Ewentualnie przy zamianie mogę dorzucić jeden POKEY ze zwalonym portem szeregowym. Jakby ktoś chciał poświęcić sprawnego POKEY-a na stereo, niech lepiej odda go w dobre (znaczy się - moje) ręce. :)
Na 100% jest to cecha sprawnego GTIA. Niestety, nie znika w zmodyfikowanym układzie. Wzorcowe przebiegi poniżej - pokazują niezbędne do wyrównania szerokości pikseli wypełnienie sygnału OSC (przebieg fioletowy) i granice dopuszczalnego przesunięcia fazy sygnału zegarowego 74HCT175 (przebieg żółty).
Dzięki za gratulacje. Sprawdziłem, że prążki pionowe między 4 a 5 i między 8 a 9 pasem szarości to nie wina CD4050. Występują tak samo w innym kompie z 74HC4050. Wszystko wskazuje, na to, że to jednak cecha GTIA.
Grzać się trochę grzeje, ale nie tak bardzo, jak CPU. Pasków o najmniejszej luminancji nie widać, bo aparat nie dał rady złapać pełnej skali jasności. ZTCP w sprawnych GTIA był cienki pionowy prążek, ale między 8 i 9 paskiem.
W komputerze, z którego pochodzi zdjęcie, siedzi właśnie 74HC4050. I nie tylko, bo dodatkowo tranzystor wyjściowy jest wymieniony na BFR183 - daje kilka razy szybsze zbocza.
Wszystko razem do kupy:
Układ dopasowania wypełnienia z dwoma inwerterami i diodą, GTIA z datą produkcji 9119.
Wygląda na to, że na grafikę HIRES nie ma wpływu współczynnik wypełnienia sygnału FO0. Regulacja w granicach 10...72% nie powodowała zmian w proporcji szerokości pikseli. Powyżej 72% zaczyna się zrywanie synchronizacji poziomej. Natomiast współczynnik wypełnienia OSC ma bezpośredni wpływ na tę proporcję. Niestety, nie jest to tylko wina kiepskiego kształtu samego OSC, więc proste przepuszczenie go przez bramkę Schmitta nic nie daje. Wewnątrz GTIA musi być znacząca różnica między czasem propagacji zboczy opadających i narastających. Sygnał OSC na wejściu GTIA powinien mieć wypełnienie ok. 42% - wówczas dopiero piksele są równe. Synchronicznie, korzystając z dostępnych sygnałów, takiego wypełnienia uzyskać się nie da. Poniżej trzy przykłady, jak można to zrobić:
Wartości elementów RC rzeczywiste, sprawdzone w układzie. Przykład z bramkami HCT132 sprawdzony tylko wirtualnie - na symulatorze. Czas propagacji przez bramki można określić tylko w przybliżeniu, więc może dobrze chodzić, ale nie musi.
Pozostaje sprawdzenie obu modyfikacji razem, a w kolejce czeka już FGTIA. Może uda się odtworzyć brakujący bit luminancji?
Specjalne podziękowania dla KMK za przygotowanie na cito testu GTIA do uruchomienia z kartridża.
Różnica w szerokościach linii na ekranie jest znacznie większa niżby wynikało to z wypełnienia FO0, więc poprawa powinna być znaczna. Choć oczywiście lepiej byłoby tak:
Fazę trzeba by dobrać przy uruchamianiu.
Bardzo ładnie. Wobec tego zostaje tylko ten nieszczęsny hires. Ze 100% pewnością można by to zrobić na sposób Bewesoft, czyli tak:
Jednak trzeba do tego dwóch dodatkowych scalaków, układ się komplikuje, a ubocznym efektem jest dodatkowe przesunięcie luminancji względem koloru (na szczęście najwyżej o pół cyklu).
Jak masz czas i chęci, to sprawdź też AN2, bo jak pisałem nie jestem pewny wyniku mojego sprawdzenia.
Pavros:
W wolnej chwili zamierzam poeksperymentować zarówno z przesunięciem fazowym, jak i zmianą współczynnika wypełnienia sygnałów zegarowych OSC i FO0. Dwa uniwibratory w LS123 pozwolą regulować płynnie oba parametry. Zatrzaskiwania także AN2 próbowałem, ale bez pozytywnych rezultatów, z tym, że zbiegło się to z uszkodzeniem GTIA, więc jest jeszcze do sprawdzenia. Sprawę bramki wtrąconej w D0xx znam, ale to raczej fałszywy trop. W późniejszych rewizjach to połączenie jest już na płycie. Chyba, żeby właśnie pogarszało sytuację. Sprawdzić to akurat nietrudno.
Ale tu faktycznie przydałoby się parę dodatkowych, wadliwych GTIA, zwłaszcza z serii 91xx, do eksperymentów. Gdyby komuś nie było żal pozbyć się jakiejś posiadanej sztuki, lub choćby zaryzykować wypożyczenie, niech da znać.
Pajero: raczej 74LS175.
Oko Cię nie zawodzi. Sprawdziłem, że pojedyncze jasne piksele w SysInfo potrafią mieć 75ns i 155ns. Może być tak, że wadliwe GTIA mają wyższy próg przełączania. Można by to spróbować poprawić, zmieniając w odpowiedni sposób wypełnienie OSC. W chwili wolnej sprawdzę, czy w ten sposób coś się da zrobić.
FO0 mierzone na poziomie TTL (1,6V) w pełnosprawnym egzemplarzu to 131ns w fazie niskiej i 151ns w fazie wysokiej. OSC jest znacznie gorszy, bo odpowiednio: 120ns i 162ns.
Od hires nie ma co wymagać równych linii pionowych. Wynika to z samej natury GTIA. Szerokość piksela wynosi pół cyklu koloru, co oznacza, że kolejne piksele są wystawiane na przemian - narastającym i opadającym zboczem sygnału zegarowego. Z tego powodu obraz jest wrażliwy na współczynnik wypełnienia tego sygnału, czyli stosunek czasu trwania fazy wysokiej do długości całego cyklu. Niestety, nie jest on równy 0.5 i dlatego piksele parzyste mają inną szerokość niż nieparzyste.
Z tego powodu musiałem zrobić nawet poprawkę w scandoublerze, bo odtworzony, precyzyjny sygnał zegarowy z PLL spóźniał się na piksel i gubił go.
Całkiem nieźle. Mam wrażenie, że jakby jeszcze zrobić parę prób typu: opóźnić o 10ns OSC, albo na odwrót - FO0, byłoby całkiem dobrze.
Mam jeszcze dużo dobrych pomysłów, tylko kury się skończyły. ;)
Może lepiej nie, bo jak ktoś się dowie, że się nie da, to nie zrobi, a jak się nie dowie, to kto wie...? :)
Ja na razie kończę, bo właśnie przy podłączaniu odczepionej końcówki analizatora przeskoczyła iskierka i drugi układ z 91r. poszedł się kochać, więc już nie mam na czym ćwiczyć. Zasilacze, !@#$%, impulsowe.
Electron: w zasadzie masz rację, choć tak do końca nie wiadomo, jak byłoby lepiej. Zmieniłem oznaczenie na rysunku, bo tak naprawdę użyłem HCT574. 74 akurat nie miałem pod ręką.
Fakt. Błąd w bibliotece elementów. Już poprawiłem.
Moje GTIA mają daty: 9038, 9038, 9118, 9119. Dwa pierwsze sprawdzone w drugim układzie, trzeci przy próbach (poszedł był na pierwszy ogień) udało mi się uwalić. Czwarty, niestety, nie łapie dla odmiany grafiki hires. Trzeba jeszcze coś poprawić.
Zarówno temperatura, jak i wielkość napięcia zasilającego mają istotny wpływ na propagację sygnałów, nic więc dziwnego, że wadliwe układy, pracujące na granicy tolerancji, mają z tym problem.
Znalazłem sposób, który załatwia oba problemy za jednym zamachem, niestety, jest nieco bardziej skomplikowany, ale bez przesady. Oczywiście, także wymaga odpowiedniego przetestowania, zwłaszcza, że bazuje nie na sygnale FO0, tylko OSC, którego przesunięcie względem FO0 może zależeć od egzemplarza.
Układ jest taki:
Przypomniałem sobie, że mam gdzieś SysInfo 2.20. Odnalazłem i zapuściłem. Okazuje się, że przy zmianie trybu w środku linii poprawa jest, ale, niestety, nie do końca. Zamiast kompletnej sieczki i latających pikseli są stabilne pasy, ale nie 16 od czerni do bieli, jak Pan Bóg przykazał, a 4 razy po 4. Tak poziomo, jak i pionowo. Rzecz wymaga więc jeszcze trochę dopracowania.
Chwilowo nie mam sprzęgu z pecetem, więc nie dam rady ściągnąć żadnych testów.
Oto schemat modyfikacji komputera z wadliwym układem GTIA na pokładzie. Sprawa dotyczy typowej usterki, występującej w układach produkowanych od 38 tygodnia 1990 roku, powodujących złą pracę w tzw. trybach GTIA. Wszyscy chyba wiedzą, o co chodzi. Modyfikację testowałem z pozytywnym rezultatem na kilku będących w moim posiadaniu wadliwych GTIA, ale tylko na paru gierkach i prostych BASIC-owych programach generujących pasy w grafice 9,10 i 11. Ponieważ jednak usterka występuje w różnych formach i różnym natężeniu w zależności od egzemplarza, prosiłbym o sprawdzenie na czym kto ma i podzielenie się rezultatami.
A może już wcześniej ktoś wpadł na to nieprawdopodobnie proste rozwiązanie?
W mojej XFD602, z napędami Chinon, jeden napęd sobie radzi, a drugi nie. Może wymagać oczyszczenia.
W części (chyba nawet większej części) XFD601/602 były montowane napędy Chinon, ale czy sobie radzą z dyskietkami HD tego nigdy nie sprawdzałem.
Z AL251 jest jeszcze taki problem, że jest przeznaczony do konwersji obrazu z przeplotem, czyli takiego, w którym istnieje względne przesunięcie czasowe między półobrazami parzystymi a nieparzystymi, a Atari generuje obraz bez przeplotu. Jak zachowa się w takim wypadku układ - trudno zgadnąć.
A o podstawkach pod TQFP48 w ogóle, a w szczególności o takich, które byłyby montowane na oryginalnym footprincie, zapomnij. TQFP to nie PLCC.
Znalezione posty [ 1,026 do 1,050 z 1,202 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.042 sekund, wykonano 36 zapytań
