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
Nowy firmware 1.5 dla SDrive-MAX Ulepszony tryb szybki i poprawki kaset w nowej wersji firmware
Ice-T 2.8.2 Nowa wersja Ice-T dla 8-bitowego Atari już dostępna - poprawki i nowe funkcje
Galactic Panic - nowa przygodówka na ST Darmowa gra point and click na Atari ST - ponad 100 ekranów przygody.
Nowa wersja ARIFE Tool od PVBest73 Uaktualniono uniwersalne narzędzie do analizy obrazów ROM i dysków Atari
Echa Sommarhack 2025 Podczas szwedzkiego party Sommarhack zaprezentowano kilkadziesiąt produkcji,
Opcje wyszukiwania (Strona 43 z 49)
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.
Jak to, o którym? O tym, o którym pisałem w temacie "konwerter vga". O takim, który zrobiłby konwersję bezpośrednio na czystym sygnale cyfrowym, a nie zasyfionym przetwarzaniem D -> A -> D.
Jaka by była szansa na zrobienie na nowych płytkach dodatkowego złącza z sygnałami sprzed VDAC + paroma dodatkowymi potrzebnymi do scandoublera? Oczywiście zakładając, że znalazłoby się trochę zainteresowanych. Moim skromnym zdaniem rzecz jest warta zachodu. Przy okazji - scandoubler ma własny PLL, więc mógłby dostarczać sygnał zegarowy dla VBXE bez dodatkowego kwarcu.
Wait states nie są potrzebne POKEY-owi, tylko CPU. Taktowanie POKEY-a wygląda tak, że dostaje 2 cykle zegara 21MHz/8, po czym następuje przerwa o długości 1 cyklu. W ten sposób średnia częstotliwość taktowania POKEY-a pozostaje bez zmian, więc transmisja szeregowa będzie przebiegać bez zakłóceń. Problem tylko w tym, że gdyby CPU potrzebował dostępu do POKEY-a podczas "ukradzionego" cyklu, to go nie uzyska. Po to właśnie wait state. Dźwięki miałyby tę samą wysokość, mógłby się tylko pojawić słyszalny jitter przy większych częstotliwościach. Programy, oczywiście, działałyby o połowę szybciej.
Nie ze scandoublerem, tylko z monitorem.
Najlepiej by było 21,28137MHz, czyli 1,5x oryginał. Można by taktować POKEY z kradnięciem 1 cyklu na 3 i generacją wait states dla procesora w cyklach dostępu do POKEY-a. Wtedy SIO by nie ucierpiało. Dźwięk tylko mógłby być miejscami kulawy.
Liczenie jest proste, jak konstrukcja cepa. Częstotliwość linii = częstotliwość kwarcu/(4*228). Częstotliwość ramki = częstotliwość linii/312. Wynika stąd, że dla kwarcu 18,432MHz częstotliwości wynoszą H=20,21kHz i V=64,78Hz. Po podwojeniu linii - H=40,42kHz.
Aha, w tej sytuacji cyfrowy scandoubler do VBXE jest sprawą otwartą. I proszę się nie obawiać - to nie jest prima aprilis.
Dla tych, którzy walczą z handlowym scandoublerem, podaję typy monitorów, które powinny być odpowiednie:
JVC - DT-V17G1
HP - LP2465
HP - LP2480
Viewsonic - N2230
Viewsonic - N3250
Acer - X243W
Acer - AL1715
Eizo - MX210
Eizo - CG211
Eizo - L985EX
Sony - LCD21
Sony - LMD181MD
Sony - LMD151MD
Dzisiejsza data to tylko niefortunny zbieg okoliczności. Zapewniam, że wiadomość jest prawdziwa, a atarynka z kwarcem 18,4MHz działa stabilnie. Nic w tym zresztą dziwnego nie ma. Kłopotów spodziewałbym się w serii XL z linią opóźniającą, ale FREDDIE generuje timingi synchronicznie, więc co za problem?
Nie wiem, jaki generuje dźwięk, bo monitory nie mają głośników. Na pewno nie ma prawa współpracować poprawnie z urządzeniami zewnętrznymi po SIO. Zresztą to tylko eksperyment. Znalazłem już kilka typów monitorów LCD z odświeżaniem od 47-49Hz, w tym, ku swemu zaskoczeniu, ten, przed którym właśnie siedzę, więc nie będzie potrzeby podnoszenia taktowania. Postaram się na jutro o kilka lepszych zdjęć w wysokiej rozdzielczości.
Znalezione posty [ 1,051 do 1,075 z 1,216 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.036 sekund, wykonano 28 zapytań
