Wyniki pomiarów częstotliwości podnośnej PAL i zakresu zaskoku pętli fazowej wyglądają następująco (niepewność nie większa niż 3*10^-7):
TV: 4.433622MHz +/-985Hz
Mikser: 4.433658MHz +/-287Hz
Prawie 3,5 raza węższy zakres zaskoku stawia znacznie ostrzejsze wymagania oscylatorom w Atari. Przykrą okolicznością jest też to, że dekoder w mikserze nie ma żadnej detekcji zaskoku, co pozwalałoby wyłączyć kolor przy braku synchronizacji lub choćby braku podnośnej. Efektem, prócz płynących. kolorowych pasów przy niedostrojeniu, jest także tęczowa mora w miejscach, gdzie Atari generuje kolor $0x.
Pin proszony sprawdzić w swoich komputerach źródło częstotliwości bazowej. Jeśli siedzą tam zwykłe kwarce, można próbować podstroić. Jeśli generatory kwarcowe, trzeba będzie wymienić.

Wstępne obserwacje prowadzą do wniosku (niekoniecznie prawdziwego), że mikser Pinokia ma dwa zupełnie odrębne problemy. Po pierwsze - dekoder PAL nie jest w stanie zsynchronizować podnośnej z Atarką. Stąd się biorą te kolorowe pasy. Zakres zaskoku pętli fazowej jest ewidentnie znacznie węższy niż w typowym dekoderze w TV, ale w miarę precyzyjnie, (~1E-7), będę mógł to zmierzyć dopiero po weekendzie. Po drugie - wadliwa synchronizacja pionowa, czyli skakanie obrazu. To prawdopodobnie faktycznie jest winą uproszczonego impulsu VSYNC z Atarki, ponieważ po podłączeniu sygnału synchronizacji z TIMG obraz, pomijając kolorowe pasy, wygląda na stabilny.

Ale to dolne zdjęcie jest zrobione właśnie ze wspomaganiem sprzętowym.

Tutaj zdjęcie ekranu z ustawionymi fontami w matrycy 8x16 pikseli.

Zaawansowane są o tyle, że kończę już projekt prototypowej płytki i pewnie za 2-3 tygodnie będę miał jakieś gotowce. Gdybyś chciał wiedzieć wcześniej, czy mikser Ci to kupi, musiałbyś go do mnie wysłać.
Z fixerem jest taki problem, że trzeba, niestety, nowej płytki. Niezależnie od większego (zasobami, nie wymiarami) CPLD, układ fizycznie ledwo mieści się między nóżkami podstawki DIP40. Do fixera trzeba jednakowoż umieścić dodatkowe dwa rzędy pinów z drugiej strony płytki, przesunięte o parę milimetrów względem podstawki. Wtedy układ się już nie mieści i trzeba robić płytkę albo dłuższą, albo szerszą, żeby zrobić miejsce na scalak poza podstawką. Nie wiem, czy to ma sens, biorąc pod uwagę, że płytka TIMG będzie tak zrobiona, żeby można było ją wlutować w płytę i zajmowała tyle samo miejsca, co zwykła podstawka. W to można sobie już wetknąć istniejącą płytkę fixera i z głowy.

Soft-GTIA, co prawda w FPGA a nie w CPLD, już przecież jest, jako core do VBXE.

Tryb Rybagsa nie zmienia nic w "konstrukcji" impulsu synchronizacji pionowej. To, co robi, to tylko skrócenie czasu jednej linii. Przeplot wychodzi przy tym nieco kulawy, bo różnica między dwiema kolejnymi ramkami nie jest równa połowie czasu trwania jednej linii (~32us) ale wynosi ok. 44us (zmierzone w grafice "ifalcon1.xex"). Dlatego też w tytule wątku napisałem "true interlaced".

Po namyśle zdecydowałem umieścić wszystko w jednym rejestrze - PMCTL, uzupełniając go jednocześnie o sprzętowy rejestr-cień, dzięki czemu bity 0,1 i 2, dotychczas służace tylko do zapisu, będzie można też odczytać. Bit 3 będzie służył przy zapisie do włączania przeplotu (1 - włączony), a przy odczycie do sprawdzania parzystości półobrazu.

GTIA fixer chyba jako opcjonalny ficzer, na specjalne życzenie, bo się już nie mieści i  potrzebuje większego CPLD.
Włączanie i wyłączanie przeplotu zewnętrznym przełącznikiem, niezależnie od programowego, powinno dać się zrobić.

Żebyśmy się dobrze zrozumieli - włączenie przeplotu (ustawienie bitu w rejestrze) to jedna sprawa, a przełączanie obrazu co przerwanie - druga. Pierwsze wystarcza, żeby normalny obraz był generowany z przeplotem, a drugiego potrzeba do zwiększenia rozdzielczości pionowej. Teoretycznie w ogóle można byłoby zrezygnować z pierwszego (tzn. ustawić przeplot na stałe), bo wspólczesne monitory i telewizory LCD nie migoczą i tak czy owak uzupełniają brakujące linie, więc nie powinno być widać różnicy. W praktyce niewielkie pogorszenie jakości w kiepskich monitorach może się zdarzyć, więc możliwość wyłączenia przeplotu jest przydatna.

PMCTL nie ma cienia, ale może mieć. Program, który miałby wykorzystywać sprajty i grafikę w trybie interlaced, musiałby taki cień sam sobie zrobić. HITCLR służy do kasowania kolizji, ale poprzez zapis do rejestru. Odczyt jest wolny. Wykorzystywanie adresów powyżej $D01F jest niby wykonalne, ale niechętnie.
Co z GTIA Fixerem - jeszcze nie rozważałem.

Rejestr PAL może być używany przez różne programy i wcale niekoniecznie nieużywane bity muszą być maskowane. Rejestr do odczytu pod adresem $D01E jest w ogóle nieużywany, więc powinien być zupełnie bezpieczny. Chyba, że o czymś nie wiem.

Fizyczna przystawka. Planowane rejestry:
1. Aktualna parzystość/nieparzystość pólobrazu - bit0 $D01E (tylko odczyt)
2. Tryb interlaced - prawdopodobnie bit7 CONSOL albo PMCTL (tylko zapis) - do ustalenia.