@Simius:
Na końcu zapewne masz jakąś tablicę wartości i pewnie DAC.
Nie wystarczy dać inne wartości żeby zamiast RGB wychodziło YPbPr ?
Tak byłoby najprościej, ale nie ma odpowiednich zasobów na tablicę. Kolory są generowane przy użyciu logiki.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
bm800xl 0.5.9 Emulator bm800xl dla Raspberry Pi zyskał szybszy start, scanlines i pełne stany pamięci.
xasm 3.3.0 i wtyczka do VSCode Po czteroletniej przerwie powraca asembler skrośny xasm.
CAS2Audio 1.1.0 Odtwarzaj obrazy taśm CAS na telefonie z Androidem.
Gearlynx 1.2.37 Nowa wersja emulatora Atari Lynx Gearlynx 1.2.37 przynosi poprawki i optymalizacje.
Wyniki ABBUC Software Contest 2026 Poznaliśmy oficjalne wyniki tegorocznej edycji ABBUC Software Contest.
atari.area forum » Posty przez Simius
@Simius:
Na końcu zapewne masz jakąś tablicę wartości i pewnie DAC.
Nie wystarczy dać inne wartości żeby zamiast RGB wychodziło YPbPr ?
Tak byłoby najprościej, ale nie ma odpowiednich zasobów na tablicę. Kolory są generowane przy użyciu logiki.
Teoretycznie obie ramki powinny mieć 50Hz. Biorąc pod uwagę nominalną częstotliwość linii, kwarc powinien mieć 14,25MHz (15625Hz*228*4). Skąd wzięło się 14.252 pozostaje zagadką.
Dataszit FGTIA podaje, że częstotliwość sygnału OSC (2x częstotliwość systemowa) wynosi "typical 3.5625MHz", co oznacza, że kwarc miałby 14.25MHz. Mogę zmierzyć, jak jest w rzeczywistości, ale różnica między 14.25 a 14.252 mieści się w granicach tolerancji dla przeciętnej jakości kwarców (140ppm), więc pomiar nie musi dać jednoznacznej odpowiedzi na pytanie, jaka jest wartość nominalna.
Jak już tam jest VBXE, to właściwie po co? Byłby z tym tylko problem mechaniczny, bo płytka zasłania ANTIC, ale innych przeszkód nie ma. Płytka w wykonaniu seryjnym mogłaby być inna i nie przeszkadzać w montażu VBXE, jeśli to miałoby jakiś sens, tzn. znalazłoby się wiele osób, chcących mieć oba urządzenia w jednym komputerze.
Wszystkie kolory są stabilne i powtarzalne, bo generowane cyfrowo. Są jednakowoż możliwe korekty, jeśli w testach okaże się to konieczne. Niewykluczone też, że wynikowym sygnałem zamiast RGB będzie komponent (YPbPr).
@simius: Skoro to wyjście RGB to:
0. Działa z NTSC?
1. Nie ma artefaktów NTSC?
2. Nie ma PAL blendingu?
Czy mógłbyś poza tym powiedzieć coś więcej o kolorze F - czy to dokładnie średnia między 1 i E w RGB?
0. Działa
1-2. Nie ma dekodowania PAL ani NTSC, więc nie ma efektów ubocznych dekodowania.
Kolor F nie jest dokładnie średnią pomiędzy 1 a E. Mieści się pomiędzy i to wszystko
Tryb interlaced, jeśli będzie potrzeba, to się zrobi. Nie ma przeszkód. Z wyjściem VGA jest większy problem, bo w obecnym układzie nie ma już dostatecznie dużo zasobów, a i trochę szybkiej pamięci SRAM potrzeba, więc pewnie trzeba by użyć MAX10.
@Montezuma
Takie rozwiązania mają sens tylko o tyle, o ile ktoś nie ma w swoim LCD wejścia SCART z RGB, a tylko i wyłącznie HDMI. W przeciwnym przypadku co za różnica, czy przetwarzanie sygnału analogowego w obraz cyfrowy zostanie przeprowadzone w LCD czy w urządzeniu zewnętrznym? Sens HDMI jest w wyrzuceniu toru analogowego w ogóle.
Mało się orientuję w systemach video, więc chciałem się dopytać, czy to rozszerzenie pozwoli podłączyć atari do tv przez scart z osobno wyprowadzonymi składowymi obrazu, jak w amstradzie
Dokładnie tak.
@Montezuma
Myślę o HDMI, ale są problemy, bo np. co z tego, że kupię gdzieś układy, skoro dokumentacja jest niejawna i dostępna dopiero po podpisaniu NDA? Tak, jakby to były czipy do kart bankowych.
Kolory są zrobione tak, żeby zachować jakie takie podobieństwo do oryginalnych, ze zmienionym kolorem F, który jest pośredni pomiędzy E i 1, więc czerwień też jest trochę kulawa. Można zrobić soczystą, ale wtedy: "czy to będzie jeszcze Atari"? ;)
@mpolak
Antonia i GTIARGB nie wpływają na siebie nawzajem.
Nie spodziewałem się znaczącego zainteresowania, więc nad ceną specjalnie się nie zastanawiałem. W sumie nie ma wielkiego pola manewru bo z jednej strony koszty (zwłaszcza małoseryjne), a z drugiej - cena VBXE, od której trzeba zachować wyraźny dystans. Przy setce chętnych może dałoby się zmieścić w 200zł.
Powiedziałbym nawet, że nie tylko można, ale trzeba, bo innego nie ma.
Po VBXE to już i chwalić się nie bardzo jest czym, ale niedosyt po połowicznym sukcesie cyfrowego dekodowania PAL trochę mnie męczył i w wolnej chwili wymodelowałem sobie GTIA w CPLD. A co. Projekt jest w zasadzie gotowy, na moje oko działa prawidłowo, choć nie będę zaskoczony, jeśli jeszcze jakieś niedoróbki się w nim z czasem odkryje. Projekt ma już swoje imię, ale na ujawnienie jeszcze za wcześnie, bo urodzi się dopiero pod koniec listopada. ;) Tymczasem nosi nazwę roboczą GTIARGB.
Nie jest to 100% model, bo machnąłem ręką na wykrywanie kolizji i pozostawiłem to oryginalnemu układowi, którego nie było potrzeby całkiem się pozbywać. Poza doskonałą jakością, generowany obraz różni się od oryginału paroma szczegółami:
- 4 bity luminancji (czyli 16 odcieni każdego koloru) dostępne są w każdym z trybów graficznych, a nie tylko w trybach GTIA.
- grafika hi-res ma 2 kolory, a nie tylko 2 jasności.
- kolorów (pomijając jasności) jest 16 a nie 15.
I to by było na tyle.
Sygnał HALT nie działa tak, jak myślisz. CPU nie odpina się od magistral w tym cyklu, kiedy HALT przychodzi, tylko w następnym. Stan linii HALT jest sprawdzany na końcu cyklu (na opadającym zboczu PHI2). Jeśli HALT jest 0, CPU się zatrzymuje i odłącza od magistral. Ot i cała tajemnica.
Nie frajera, tylko najmniej stu frajerów, bo pojedynczy frajer nie załatwi Ci rozrzutu, a tylko jedną próbkę. :)
Statyczność prążków na obrazie wskazuje, że nie mogą być wynikiem zakłóceń zewnętrznych (np. z zasilacza), tylko zakłóceń powodowanych przez procesy występujące synchronicznie z obrazem. A jakie procesy w systemie są synchroniczne z obrazem? Odp.: 1. odświeżanie pamięci dynamicznych (9 cykli w każdej linii obrazu) - odpowiada za stałe i niezmienne prążki na lewej połowie ekranu, w odstępie dwóch znaków w trybie 0 (8 "cykli koloru" czyli 16 pikseli Hi-Res) 2: pobieranie danych obrazu przez ANTIC - reszta prążków, zależnych od trybu graficznego a pewnie w jakimś stopniu także od treści obrazu.
Wygląda na to, że sprawa współpracy z SIDE2 jest już załatwiona.
Przełączanie rodzaju rozszerzenia pamięci RAM nie musi koniecznie wiązać się z zimnym startem systemu. Pamięć podstawowa jest zawsze w tym samym miejscu, więc jeśli program przełączający nie znajduje się akurat w pamięci bankowanej, przełączanie odbywa się gładko. Na wypadek, gdyby trzeba było zlokalizować dane po przełączeniu, dostępna jest szczegółowa mapa przydziału pamięci fizycznej.
Na oko zła współpraca z monitorem. Spróbuj podłączyć do innego.
Na AtariAge też był sygnalizowany taki problem z SIDE2. SIDE1 podobno działa. Nie mam SIDE w żadnej wersji, nie mam jak sprawdzić.
Simius, testowałeś najnowsze IDE z tym
Edit:
Nie testowałem.
O ile pamiętam, Pin miał usunięty scalak.
@Pajero
Przeróbka pokazana na zdjęciu nie wygląda pięknie. Jeśli nie działa, spróbuj jednak metody z usunięciem HCT245.
IDE+ rev.C w wersji oryginalnej, bez żadnych przeróbek.
Ja bym radził jednak przede wszystkim zmienić dysk, bo tak całkiem sprawny to on nie jest. Test, co prawda, udało mu się przejść, ale czas inicjalizacji i towarzyszące temu odgłosy były bardzo podejrzane.
atari.area forum » Posty przez Simius
Forum oparte o: PunBB