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ę.

Można jeszcze włączyć przyzwoitej jakości oscyloskop i porównać burst w sygnale video z Atari, CPC, PSX i z dekodera TV ze standardem.

Może jakieś wnioski z tego wypłyną. W Atari 130XE, które mam akurat pod ręką, burst ma amplitudę 500mVpp i szerokość 15 cykli, czyli ok. 3,4us i zaczyna się natychmiast za impulsem synchronizacji. Nie jest to dokładnie tak, jak trzeba, ale znowu nie wiadomo dokładnie, jakie faktyczne wymagania ma mikser.

Według schematów Jera są takie same.

Problemy z synchronizacją mogłyby być uzasadnione, bo sygnał video z Atari ma parametry mocno odbiegające od normy. Ale opisywane efekty nie bardzo do tego pasują. Oczywiście, łatwo to sprawdzić, doprowadzając sygnał do kultury przez zmianę kilku elementów na płycie Atari, ale prawdopodobieństwo, że to pomoże, szacuję może na 10%. Bardziej prawdopodobne jest to, że mikser spodziewa się obrazu z przeplotem, a Atari generuje bez przeplotu (nie wiem, jak CPC). Temu bym przypisywał przesuwanie się obrazu w górę i w dół o pół piksela.

Pragnę przypomnieć tym, ktorym wszystko się kojarzy, że Oświęcim to wcale niemałe miasto, liczące 40 tys. mieszkańców, w którym istnieje nie tylko największy w Europie pomnik niemieckiej, wyższej cywilizacji, ale także inne obiekty - zamek, kościoły, biblioteki, domy kultury etc. Jakby otworzyć jeszcze ośrodek wypoczynkowy, nic by w tym nie było złego, ani nawet politycznie niepoprawnego.
A jeśli koniecznie chcecie się oburzać, to może lepiej tym, że Niemcy zakwaterowali grupę uchodźców literalnie na terenie byłego KL Buchenwald.