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.

Tego akurat nie sprawdzałem, ale nie spodziewam się czegoś innego.

Atari nie generuje impulsów wyrównawczych, które normalnie występują bezpośrednio przed i po impulsie synchronizacji pionowej i mają dwa razy mniejszą szerokość i dwa razy krótszy okres niż impulsy synchronizacji poziomej. W zasadzie w dość prosty sposób można by je wytworzyć, budując 16-bitowy licznik taktowany sygnałem zegarowym PHI2 i zerowany z początkiem impulsu synchronizacji pionowej. Wyjście licznika sterowałoby adresem odpowiednio zaprogramowanego EPROMu, a z wyjścia danych pobierałoby się (prawie) gotowy ciąg impulsów CSYNC. Jest tylko jeden problem - potrzeba kilku impulsów wyrównawczych PRZED synchronizacją pionową. Jeśli mamy do czynienia z normalnym obrazem, składającym się z 312 linii, to z góry wiadomo, przy jakim stanie licznika powinny się pojawić. Jeśli jednak w wyniku jakichś trików liczba linii w rastrze uległaby zmianie, układ by się posypał. I to jest pytanie do ekspertów od programowania ANTIC-a - czy znane są sztuczki zmieniające liczbę linii w rastrze? Ja na to odpowiedzieć nie potrafię.